X.Org Server 21.1.0

Т.е нативных AAA игр нет, зато есть трансляция вызовов враждебной «неправильной» «следящей» ОСи.

Вы не поверите. Даже когда у разработчиков игры есть рабочая нативная версия под Linux, им лень нажать на кнопочку Build в их любимой IDE. Рыночек порешал.

Ну давай.

• Можно глобально захватывать ввод управляемым способом.

• Есть стандартный API для устройств и методов ввода в пространстве пользователя.

• Можно группировать окна в вкладки.

• Есть протокол удалённого рабочего стола с векторной графикой и HTML 5 клиентом.

• Есть тонкая настройка поведения окна. Например можно сделать чтобы окно не становилось активным при нажатии внутри него или вообще никогда не было в фокусе.

• Есть серверные декорации и настройка их внешнего вида.

• Работает без композитора а значит потребляет намного меньше ресурсов и быстрее работает программная отрисовка. Wayland в принципе не может работать без композитора, у него нет векторных команд.

• Поддержка многопоточности в GUI. Каждое окно работает в отдельном потоке.

• Есть протокол взаимодействия с контролами в других процессах. Например можно прочитать/вставить текст в поле ввода другого окна, программно нажать кнопку, выбрать элемент из списка и т.д..

• Можно свободно управлять позицией окон.

• Модальные окна позволяют таскать окна внизу.

• Зависшие окна можно таскать и управлять ими.

Не знаю что такое «двач».

Ну вот и погугли. Там ты найдёшь товарищей по стилю общения и толстоте троллинга.

Покажи как Gnome/KDE работают без нативных KMS драйверов и MESA. Потом поговорим.

мне извращаться ради непонятно чего леностно, бэкенд есть и работает. У меня была плата с процессором imx6 там кастомная реализация opengl через EGL fbdev, там и KMS толком нет, всё вообще через расширения протокола fbdev работет и отдельный 2D blitter через него работает.

Есть же программный рендеринг в композиторах.

Он намного медленнее, чем без композитора.

Для начала: где взять GTK1/Qt2, интересно?

В репозиториях современной Fedora доступен GTK 1 и Qt 3.

Qt 1 и Qt 2 легко компилируются современными средствами.

Даже когда у разработчиков игры есть рабочая нативная версия под Linux, им лень нажать на кнопочку Build в их любимой IDE. Рыночек порешал.

Я в курсе про Google Stadia.

Факт того, что разрабы готовы поддерживать headless полупроприетарную Linux платформу с точно заданным набором ПО, ещё раз подтверждает тезисы о том, что ISV требуют стабильность API, простоту и ясность сборки - вы им предлагаете собирать под 100500 дистров? В Линуксе хотя бы есть универсальный менеджер пакетов? Что, ничего вообще?

Опять будут вопли про «собирайте в Ubuntu 16.04 (будем надеяться, что оно везде будет работать) и дайте нам tar.gz»? И как пользователи дистров будут устанавливать tar.gz? В Windows/MacOS - двойной щелчок и вы можете работать.

Линукс на deskop как платформы нет и не было. Жирная точка. Есть вагон дистров с плавающими версиями ПО и библ, полным отсутствием universal package manager и почти полным отсутствием long-term совместимости, не считая POSIX API, про который тут орут и который бесполезен чуть больше, чем полностью, не считая консольных приложений. Web server на нём можно написать - да. Поздравляю.

Qt 1 и Qt 2 легко компилируются современными средствами.

Они вообще открыты? Qt поначалу вроде закрытый был.

В Windows/MacOS - двойной щелчок и вы можете работать

там одни вирусы

Qt 1 и Qt 2 легко компилируются современными средствами.

Легко?!! Когда же ты врать прекратишь, <мат опущен>?

GCC 11 не соберёт ни GTK1, ни Qt2, а чтобы собрать их и довести до рабочего состояния утрахаться надо. И как насчёт всех остальных библ, которые нужны для GKT1 и Qt2, и которых нет или, о чёрт, поменяли API/ABI за последние 20 лет? Тоже собрать? А как поставить, чтобы ничего сломать? Ты в своём уме? И даже если соберёшь, он слинкуется с твоим … glibc, и твоё приложение на RedHat 7.1 не запустится.

Явно никогда ничего старого не собирал - а вот я за +20 лет намаялся с этим до сблёва.

Речь про GTK1 и Qt2 была изначально - другой товарищ даже copy paste осилить не может.

Qt2, пожалуйста:

https://download.qt.io/archive/qt/2/qt-2.0.2.tar.gz.mirrorlist

Явно никогда ничего старого не собирал - а вот я за +20 лет намаялся с этим до сблёва.

Собираем Perl прямиком из 1987 года

Да, секс ещё тот, но с Qt2/GTK1 будет примерно в 150 раз больше, ибо Perl сугубо для консоли (биндинги не считаем).

а вот я за +20 лет намаялся с этим до сблёва

а собирал то зачем ?

А на фига вмешиваться в обсуждение, если вы не следите за нитью дискуссии?

Незачем. Всё прекрасно. Забудьте про мои инсинуации. Линукс божественен, Wayland просто ангельский, Windows sucks. OK?

Можно глобально захватывать ввод управляемым способом.

В смысле читать события ввода с разрешения пользователя?

Есть стандартный API для устройств и методов ввода в пространстве пользователя.

Если речь о драйверах устройств, то почему они в одном ряду с IME? Прошу поподробнее объяснить.

Можно группировать окна в вкладки.

В KDE раньше тоже такая фича была (в иксах). Надеюсь, обратно запилят.

Есть протокол удалённого рабочего стола с векторной графикой и HTML 5 клиентом.

Я так понимаю, в гайке есть свой стандартный тулкит, и возможность отправлять команды отрисовки по сети, как в RDP, это следствие его наличия. Правильно? Насколько этот тулкит функционален, может ли там работать какой-нибудь Qt?

Есть серверные декорации и настройка их внешнего вида.

Зависшие окна можно таскать и управлять ими.

Так это и в Wayland можно.

Работает без композитора а значит потребляет намного меньше ресурсов и быстрее работает программная отрисовка. Wayland в принципе не может работать без композитора, у него нет векторных команд.

Тут могу лишь сказать, что это принципиально важно разве что на платформе, под которую нет графических драйверов (:

Поддержка многопоточности в GUI. Каждое окно работает в отдельном потоке.

Сам в этой теме не разбирался, но Мартин вроде говорил, что от многопоточности в отрисовке графического стола толку мало.

Есть протокол взаимодействия с контролами в других процессах. Например можно прочитать/вставить текст в поле ввода другого окна, программно нажать кнопку, выбрать элемент из списка и т.д..

Можно свободно управлять позицией окон.

По умолчанию и без разрешения пользователя?

Модальные окна позволяют таскать окна внизу.

Это как и зачем это нужно?

Только всё равно, конечно, сомневаюсь, что графическая система в гайке от этого более юзабельна, чем Wayland сейчас.

Haiku же Unix-like? А туда можно привычное Unix-окружение портировать, чтобы если сильно не приглядываться, то от GNU/Linux нельзя было отличить (как *BSD)?

Линукс божественен, Wayland просто ангельский, Windows sucks.

windows конечно говно, она нигде не работает кроме x86. Linux не идеален но близок к этому, не зря сейчас это майнстримное ядро. Wayland тоже майнстрим в коммерческих устроствах, для x11 несколько лет назад производители встраиваемых графических процессоров перестали драйверы выпускать. Ты кроме десктопов ничего не видел, поэтому такой нервный :)

Легко?!! Когда же ты врать прекратишь, <мат опущен>?

У таких как ты, которые засоряют эфир всяким жопным шумом, конечно не легко. А у меня вот, вполне себе легко. Сколько я тебе там ответ писал? 10 минут? За это время я собрал Qt 1, Qt 2 и программу использующую GTK+1 (собирать GTK+1 не нужно, так как он сразу есть в репах), ещё наделал скриншоты, сейчас залью.

Сказать-то что хотел, чудик?

Забирай рецепты, если нужны:

# Qt 1
git clone https://github.com/heliocastro/qt1
cd qt1
cmake .
make -j32
ldd ./examples/tetrix/tetrix 
	linux-vdso.so.1 (0x00007ffe5b0f7000)
	libqt1.so.1 => /home/exl/Downloads/qt1/src/libqt1.so.1 (0x00007f9cbae24000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f9cbac10000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f9cbaaca000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9cbaaaf000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f9cba8e4000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f9cba79d000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f9cba786000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9cbb079000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f9cba75c000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f9cba755000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f9cba750000)
$ ./examples/tetrix/tetrix


# Qt 2
git clone https://github.com/heliocastro/qt2
cd qt2
cmake .
make -j32
ldd ./examples/tetrix/tetrix
	linux-vdso.so.1 (0x00007ffe553ee000)
	libqt2.so.2 => /home/exl/Downloads/qt2/src/libqt2.so.2 (0x00007fc3f265e000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc3f2610000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc3f2428000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc3f22e2000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc3f22c7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc3f20fc000)
	libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007fc3f20af000)
	libSM.so.6 => /lib64/libSM.so.6 (0x00007fc3f20a4000)
	libICE.so.6 => /lib64/libICE.so.6 (0x00007fc3f2087000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007fc3f1f40000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007fc3f1f2b000)
	libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007fc3f1eb7000)
	libXft.so.2 => /lib64/libXft.so.2 (0x00007fc3f1e9c000)
	libmng.so.2 => /lib64/libmng.so.2 (0x00007fc3f1e29000)
	libGL.so.1 => /lib64/libGL.so.1 (0x00007fc3f1da2000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fc3f1d69000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc3f1d4f000)
	libXmu.so.6 => /lib64/libXmu.so.6 (0x00007fc3f1d33000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc3f2d4a000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fc3f1c6e000)
	libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fc3f1ae3000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc3f1ada000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fc3f1ab0000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc3f1aa9000)
	libXrender.so.1 => /lib64/libXrender.so.1 (0x00007fc3f1a9c000)
	liblcms2.so.2 => /lib64/liblcms2.so.2 (0x00007fc3f1a35000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fc3f1a03000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fc3f194b000)
	libXt.so.6 => /lib64/libXt.so.6 (0x00007fc3f18e0000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc3f18cd000)
	libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007fc3f18bf000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc3f1891000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007fc3f188c000)
	libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007fc3f1869000)
./examples/tetrix/tetrix

# My GTK+1 Application
sudo dnf -y install gtk1-devel xorg-x11-fonts-ISO8859-1-100dpi

git clone https://github.com/EXL/2048
cd 2048/2048-Gtk1/
cmake .
make -j32
ldd ./2048-Gtk1
	linux-vdso.so.1 (0x00007fff2b06e000)
	libgtk-1.2.so.0 => /lib64/libgtk-1.2.so.0 (0x00007f439e3a2000)
	libgdk-1.2.so.0 => /lib64/libgdk-1.2.so.0 (0x00007f439e35e000)
	libXi.so.6 => /lib64/libXi.so.6 (0x00007f439e34c000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f439e337000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f439e1f0000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f439e0aa000)
	libglib-1.2.so.0 => /lib64/libglib-1.2.so.0 (0x00007f439e077000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f439deac000)
	libgmodule-1.2.so.0 => /lib64/libgmodule-1.2.so.0 (0x00007f439dea7000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f439de7d000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f439de76000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f439e559000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f439de6f000)
./2048-Gtk1

https://baat.z-lab.me/~exl_lab/screens/qt1.png
https://baat.z-lab.me/~exl_lab/screens/qt2.png
https://baat.z-lab.me/~exl_lab/screens/gtk1.png

под гномом, фу! Ловите наркогномосека!

Они вообще открыты?

Да, открыты и актуализированы под современные системы, см:

https://github.com/heliocastro/qt1
https://github.com/heliocastro/qt2

Qt поначалу вроде закрытый был.

Да, был. Но с версии Qt 0.90 под Linux/X11 были открыты исходники под какой-то там специфической лицензией. А с версии Qt 4.0 его открыли и под Windows и перешли на GPL. Хотя может быть Linux/X11 сборки перешли на GPL раньше, уже не помню. Но точно помню, что либы для Windows нужно было качать с их сайта и код их был закрыт.

Как ваш чудный бинарник запустить под RedHat 7.0, не ломая его?

Всё, слился?

Как ваш чудный бинарник запустить под RedHat 7.0, не ломая его?

собрать статически ?

В смысле читать события ввода с разрешения пользователя?

Есть API для запроса получения всех сообщений ввода. Есть возможность сигнализировать об отказе доступа. Разрешение пользователя пока не реализовано, но при желании можно сделать не ломая существующие программы.

Если речь о драйверах устройств, то почему они в одном ряду с IME? Прошу поподробнее объяснить.

Потому что это всё динамические библиотеки, которые генерируют сообщения ввода. Принцип действия у них одинаковый. Никакого ядерного libinput нет.

Я так понимаю, в гайке есть свой стандартный тулкит, и возможность отправлять команды отрисовки по сети, как в RDP, это следствие его наличия. Правильно?

Да, посылаются векторные команды рисования по типу RDP. Только команды более современные со сглаживанием и градиентами.

Сам в этой теме не разбирался, но Мартин вроде говорил, что от многопоточности в отрисовке графического стола толку мало.

В случае программной отрисовки окна рисуются параллельно задействуя все ядра процессора. Если одно окно программы зависло, то остальные могут продолжать работать. Повышается отзывчивость.

По умолчанию и без разрешения пользователя?

Да. При желании программы могут закрыть доступ извне. По умолчанию доступ закрыт для полей ввода пароля.

Это как и зачем это нужно?

Например если открыт диалог открытия файла, то можно таскать основное окно программы.

А туда можно привычное Unix-окружение портировать, чтобы если сильно не приглядываться, то от GNU/Linux нельзя было отличить (как *BSD)?

По идее можно, но никто пока не делал. X.Org уже запускали. С Wayland проблемы в виду отсутствия epoll. Тут вопрос зачем, вспоминается анекдот про буханку хлеба и тролейбус.

windows конечно говно, она нигде не работает кроме x86.

Фанаты свободы мат часть никогда не знали, и продолжают этим хвастаться.

Windows работает на i686, x86-64, ARM64 и были порты под ARM, Itanium, Dec Alpha, PowerPC и MIPS.

Каким местом это относится к тому, что во всём другом, кроме поддержки ненужных архитектур и наличию свободного кода (GPL ни черта не свободная лицензия - похуже, чем EULA у многих проприетарных программ), линукс отстой - я не знаю.

Под RedHat 7.0 ты подразумеваешь RHEL 7? Просто проделать инструкции из моего поста на CentOS 7 или на самом RHEL 7. Бинарь собранный в CentOS 7 будет работать и в современной Fedora и даже в Ubunutu.

Если же речь идёт про древний RedHat 7.0 которым никто не пользуется с 2004 года, то просто собрать всё статически с нужной битностью архитектуры.

Я мог бы тебе это даже продемонстрировать, с месяц назад мне нужен был именно RedHat 7.0 для компиляции кое-какого софта, жаль снёс виртуалку с ним как только сделал нужные дела.

Windows работает на i686, x86-64, ARM64 и были порты под ARM, Itanium, Dec Alpha, PowerPC и MIPS

нет дружок, этой рекламой сыт не будешь - драйверов для SoC никто не пищет под винду а это шоустопер.

И, о чудо, вы снова не знаете мат часть.

Glibc современный имеет ограничения касаемо поддерживаемой версии ядра. Щас нужно ядро минимум версии 3.2. Ваш статический бинарь упадёт в кору.

https://sourceware.org/glibc/wiki/Glibc%20Timeline

О, чудные фанаты свободы и их чудные порывы.

Что тут у вас происходит, пока я там очередную фичу на JS пилил. Окошки какие-то древние под гномом показываете. Интересное.

Whataboutism блистает!

Давайте поговорим что ещё «поддерживает» Линукс и как это «важно» среднему PC пользователю.

Начали с того, что совместимости в Линуксе по сути нет (кроме, крайне условно, POSIX и только на уровне исходного кода), а пришли: «Но ведь линукс работает на Raspberry Pi!»

Тьфу ты.

Glibc современный имеет ограничения

а кто сказал что надо glibc использовать ?

https://www.musl-libc.org/

У этого я подозреваю будет ещё больше проблем с древними ядрами.

а кто сказал что надо glibc использовать ?

Как это относится к обратной совместимости? Whataboutism продолжается.

Как это относится к безболезненной сборке ПО на Fedora 35, которое будет работать на дистрах, выпущенных за последние хотя бы 10 лет?

Куда вас несёт? LOOOOOOOOL.

вы им предлагаете собирать под 100500 дистров? В Линуксе хотя бы есть универсальный менеджер пакетов? Что, ничего вообще?

Как будто в винде есть реально используемый универсальный менеджер пакетов, а в линуксе их аш несколько, да ещё с поддержкой зависимостей!: flatpak и snap (ок, последний оказался говно на практике, но все же). Есть ещё appimage. Все вышеперечисленное тащит зависимости в комплекте гарантируя совместимость на любом дистре прям как в вашей любимой винде. Можно сделать тупо deb и rpm, если хочется юзать дистрозависимые системы пакетирования. Этого вполне достаточно чтобы покрыть всю ЦА.

В Windows/MacOS - двойной щелчок и вы можете работать.

Это миф. Виндософт очень глюченный, просто виндузятники уже привылки и об этом умалчивают. Иногда trax такой что чувствуешь себя лютым гентушником. Софт из исходников легче собирать, дожили (censored). После линукса винда кажется ненужным поделием для зарабатывания денег из воздуха. Про мак не знаю, никогда его не юзал.

Линукс на deskop как платформы нет и не было. Жирная точка.

Есть. Он живет, но его не ставят по дефолту, поэтому для масс его не существует. Потребности в определенном софте, привычки это уже стопитцотый вопрос.

Есть вагон дистров с плавающими версиями ПО и библ, полным отсутствием universal

Большая часть дистров это вариации болженоса с нескучными обоями. А по сути популярных десктопных дистрибутивов всего 2-3.

почти полным отсутствием long-term совместимости

А что если я скажу, что линуксу почти не нужна совместимость? Потому что большая часть софта пересобирается под новые самые свежие версии дистрибутивов.

Ладно, на практике с совместимостью все ОК, а на винде приходится XP ставить или вайн юзать, потому что на десяточке многие старые приложения не работают даже в режиме совместимости.

Да вы еретик это на современном Гноме запускать.

Но ведь линукс работает на Raspberry Pi!

это не коммерческая платформа, ты её даже не купишь мелким оптом. Linux сейчас все производители процессоров используют в качестве основной ОС

У этого я подозреваю будет ещё больше проблем с древними ядрами.

не пользуюсь продуктами редхата - какое там ядро ? мне как-то нужно было унивесальный бинарь сделать, я делал правда с uclibc на убунте с 3.х ядром работало

Да. При желании программы могут закрыть доступ извне. По умолчанию доступ закрыт для полей ввода пароля.

А нельзя сделать, чтобы наоборот было: по умолчанию доступ закрыт, а по разрешению пользователя даётся?

Да

Насколько этот тулкит функционален, может ли там работать какой-нибудь Qt?

Например если открыт диалог открытия файла, то можно таскать основное окно программы.

Так и в Wayland можно. Только зачем. Я вот недавно GNOME тыкал, и там идеально реализована работа с диалоговыми окнами: диалоговое окно «приклеивается» к родительскому и декорации у него при этом не рисуются, потому что нет вообще никакого смысла в работе с основным окном, пока его функциональность блокируется диалоговым. А в Plasma топорно и по-дебильному.

Тут вопрос зачем, вспоминается анекдот про буханку хлеба и тролейбус.

Чтобы работал уже написанный софт, очевидно же.

Если в Haiku решены какие-то архитектурные проблемы других ОС, то если там можно будет пользоваться полезным популярным софтом, то она даже нишу свою найдёт, как *BSD.

Как это относится к безболезненной сборке ПО на Fedora 35, которое будет работать на дистрах, выпущенных за последние хотя бы 10 лет?

у тебя есть на чём проверить ? попробуй отсюда бинарь будет ли работать на старом ядре

https://github.com/NXPmicro/mfgtools/releases/tag/uuu_1.4.165

подозреваю они учитывают актуальные версии коммерческих дистров редхата

А нельзя сделать, чтобы наоборот было: по умолчанию доступ закрыт, а по разрешению пользователя даётся?

Сейчас нет, но доработать можно.

Насколько этот тулкит функционален, может ли там работать какой-нибудь Qt?

А он и работает включая шестую версию. Портировано множество программ под него включая Телеграм клиент, Krita с поддержкой стилусов с силой нажатия и много чего ещё.

С GTK пока проблемы. Думаю его через Wayland запустить. Примитивность Wayland может пойти на пользу при его реализации и прозрачной интеграции.

и там идеально реализована работа с диалоговыми окнами: диалоговое окно «приклеивается» к родительскому и декорации у него при этом не рисуются

Это ужас а не идеально. Что если я хочу посмотреть содержимое главного окна для принятия решения что делать в модальном диалоге? В Haiku их именно независимо можно двигать. Эффект от модальности в том, что окно всегда на переднем плане по отношению к главному и ввод клиентской области главного окна блокируется.

Чтобы работал уже написанный софт, очевидно же.

Написанный софт можно запускать в существующей GUI системе, зачем тащить целые DE из Линукса? Совместимости они никак не прибавят. Для совместимости можно например реализовать протокол Wayland исключительно для портированных программ. Взятие DE из Линукса в плане драйверов тоже никак не поможет.

Если в Haiku решены какие-то архитектурные проблемы других ОС

Они решены в первую очередь в графической системе, при переносе графики из Линукса они будут помножены на ноль.

Что если я хочу посмотреть содержимое главного окна для принятия решения что делать в модальном диалоге?

Тогда сдвинь сам диалог. Но обычно такое не должно быть нужно.

А он и работает включая шестую версию. Портировано множество программ под него включая Телеграм клиент, Krita с поддержкой стилусов с силой нажатия и много чего ещё.

Прикольно.

Написанный софт можно запускать в существующей GUI системе, зачем тащить целые DE из Линукса?

Ну, я под Unix-окружением имел в виду не только DE. Я же про Haiku знаю примерно только то, что там микроядро, поэтому не знаю, насколько хорошо там работают те же bash/zsh/fish и т. п. А судя по скриншотам, встроенному DE я бы точно предпочёл Plasma.

Я же написал, что сам не пробовал. Однако быстрый Google-поиск утверждает, что есть.

я его поставил и он до сих пор стоит. По умолчанию там ничего не работает - нужно до устанавливать тонны софта и настраивать. Готового примера минимальной настройки до уровня возможности использования за 30 минут так и не нашёл но нашёл кучу доков которые читать только явно больше часа и забил.

Готового примера минимальной настройки до уровня возможности использования за 30 минут так и не нашёл но нашёл кучу доков которые читать только явно больше часа и забил.

Так это же прямой аналог i3 — с чего бы там было как-то иначе?

Что мешает сделать тоже самое в линуксах (также в общем-то и делается) - для меня загадка века. Ну ест-но это придётся делать руками, ну на то он линукс.

Что тут загадочного? Никто не мешает, но никто и не помогает- вот и не сделали пока. До лтс додумались, а то о чём ты пишешь является развитием этой идеи, так что думаю скоро додумаются и до этого.

поэтому не знаю, насколько хорошо там работают те же bash/zsh/fish

Утилиты командной строки по большей части из Линукса, например Coreutils используется по умолчанию. Некоторые низкоуровневые утилиты свои хотя бы потому что те, что в Линуксе или *BSD прибиты к системным вызовам ядра Линукс/*BSD.

А судя по скриншотам, встроенному DE я бы точно предпочёл Plasma.

Что с встроенным DE не так?

Как будто в винде есть реально используемый универсальный менеджер пакетов

MSI, NullSoft Installer, etc. Вагон. Всё пакуется в exe, который работает во всех релизах Windows за последние 15 лет.

Виндософт очень глюченный

Дальше не читал. Весь enterprise работает на Windows. Падонкофский лексикон сразу говорит, что весь этот параграф - ложь, преувеличение и провокация.

Я знаю компании, где тысячи рабочих станций на Windows 8.1/10 Enterprise, и всё работает как часы. Никаких «глючных» софтин и «глючных» обновлений. Единственный огромный упрёк Microsoft за последние 40 лет - это то, что сломали printer spooler больше 4 месяцев назад, и до сих пор решения нет. Люди сильно кипятятся. Извращаются как могут, включая Internet Printing … в локалке.

Есть. Он живет, но его не ставят по дефолту, поэтому для масс его не существует. Потребности в определенном софте, привычки это уже стопитцотый вопрос.

Среди 2% ИТ специалистов и фанатов, которым не жалко времени, чтобы заниматься с ним сексом. Окромя их, про Линукс никто не знает, что говорит о том, что вы просто врёте.

Большая часть дистров это вариации болженоса с нескучными обоями. А по сути популярных десктопных дистрибутивов всего 2-3.

Снова ложь. У RedHat есть поддерживаемые RHEL 7, 8, Fedora 33, 34, 35.

У Ubuntu есть поддерживаемые 14.04 16.04 18.04 20.04 20.10.

Я только у двух компаний нашёл уже 10 дистров без совместимости. Про форки Ubuntu, Arch и его форки - молчу. На distrowatch зайдите и прослезитесь насчёт 2-3. Снова ложь.

А что если я скажу, что линуксу почти не нужна совместимость?

Супер, спасибо, до свидания.

В истории компьютерной индустрии не было до сих пор ни одной популярной ОС без универсального инсталлятора и твёрдой обратной совместимостью.

Я зашёл в эту тему с того, что Линукс пользовали считают себя «илитой», и их не волнует факт того, что Линукс не является ОС для обычных смертных. Вы только что это подтвердили.

Зачем только три страницы убогих попыток со смой спорить - не знаю.

Они решены в первую очередь в графической системе, при переносе графики из Линукса они будут помножены на ноль.

А как же микроядро?

Из твоего списка в Wayland можно всё реализовать, кроме разве что рендеринга без композитора.

Что с встроенным DE не так?

Ну, для меня примерно всё.

Это уже пятое оскорбление в отсутствие аргументов на двух страницах. ЛОР и фанаты свободы не меняются.

судя по тому как ты ругаешь фанатов свободы - сам ты являешься фанатом рабства.

Единственный огромный упрёк Microsoft за последние 40 лет - это то, что сломали printer spooler

расскажи про твёрдую совместимость реальным пользователям windows

https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=156042