Выбор дистрибутива или насколько хороша последняя Ubuntu?

Самый стабильный дистрибутив это NixOS.

в третьем варианте ошибка, собран он так-же как и в первом, но при установке из репозитория не доступен в рабочем виде, потому что пм не может в зависимости

пс% половинка-на серединку лучше ;)

Менюшка

Точно нет. С какого стартеркита тогда начинать?

До недавнего времени кто-то из пользователей даже на xfce сидел, та что на gtk2.

Xfce очень просто собирается, последняя версия на gtk2 это Xfce 4.12, я тоже на ней сидел еще в прошлом месяце, но недавно решил перейти на самую новую версию.

В ее сборке главное порядок соблюсти, я собираю на основе этого скрипта slackware-14.2/source/xfce/xfce-build-all.sh

xfce4-dev-tools libxfce4util xfconf libxfce4ui exo garcon tumbler thunar xfce4-panel xfce4-settings xfce4-session xfdesktop xfwm4 xfce4-appfinder xfce4-terminal orage thunar-volman xfce4-power-manager xfce4-pulseaudio-plugin xfce4-notifyd xfce4-clipman-plugin xfce4-screenshooter xfce4-systemload-plugin xfce4-taskmanager xfce4-weather-plugin xfce4-whiskermenu-plugin xfce4-panel-profiles Greybird elementary-xfce xfce4-xkb-plugin 

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

Я все же думаю, что его преимущества могут быть полезны не только разработчикам. Банально проще собрать новый GIMP чем в Debian, а если он собран нативно, а не через Flatpak то запускается быстрее, уже приятно. Или же наоборот, хочется старый Xfce 4.12, и старые приложения на Gtk2, под них много тем, они могут казаться для некоторых очень красивыми, они быстрее, а некоторые старые приложения содержали больше возможностей. Придется много разбираться, но становиться разработчиком не обязательно.

Хочется Sway 1.9 и нативную Wayland сессию.

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

в третьем варианте ошибка, собран он так-же как и в первом

Ошибки нет никакой. Откуда мы знаем, как он собран?

Вариант просто не обновлять арч (или обновлять по графику) не рассматривается? Убунта ничем не будет отличаться в этом плане: ядра там тоже обновляются, а livepatch это не изкоробочная фича.

И оказалось, что всё в контейнерах, snapd даже интегрирован в kernel и firmware. Удаление чревато поломкой системы.

Опять же просто не трогаешь это все и живешь спокойно на околодефолте.

На всякий случай крайне НЕ рекомендую федору (на случай если ее кто-то порекомендовал в треде). Их довольно часто штормит из за обновлений ядра и экспериментов. Из последнего - selinux, убивающий приложения на базе хрома/электрона. Эпопея уже вторую неделю длится

Просто так пакеты в Slackware не надо ставить. Slackware ставится сразу вся, со всеми пакетами, и тогда все гарантированно работает. Можно ставить кусками, но могут быть проблемы. Но отсюда и преимущества, я выше описал что у меня две версии icu стоят и друг другу не мешают, и xfce 4.12 я собираю очень простым образом. Подобная система дает больше гибкости.

Пакеты разделены на группы, в установщике можно снять галку с установки группы, их можно посмотреть тут http://mirror.yandex.ru/slackware/slackware-15.0/slackware/

Поэтому ставить KDE и XFCE не обязательно, можно снять галочку с KDE. Я снимаю с E, KDE, Y, T, XFCE, и с некоторых пакетов по одиночке, потому что знаю что компилятор cobol мне точно никогда не понадобится. Если ты снял галочку с группы XFCE, то можешь быть спокоен, KDE у тебя точно заработает.

Slackware не включает в себя все пакеты, иначе бы размер установщика был гигантским. В ней нет пакета mpv, но он есть на SlackBuilds.org, там зависимости прописаны, а ПМ для SlackBuilds.org - sbopkg их понимает. Но можно им не следовать, я редко пользуюсь этой возможностью.

Xfce очень просто собирается

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

спасибо

Вариант просто не обновлять арч (или обновлять по графику) не рассматривается?

В таком случае он может развалится, скачки в обновлении не поддерживаются.

Из последнего - selinux, убивающий приложения на базе хрома/электрона.

Он одной строчкой выключается.

В таком случае он может развалится, скачки в обновлении не поддерживаются.

Не поддерживаются частичные обновления. Если ты обновляешь раз в месяц-два, но все сразу, из одного цельного состояния в другое цельное состояние, то что там технически может сломаться? Ну объявления на главной странице надо читать, чтобы на реальные breaking changes не влететь.

Он одной строчкой выключается.

Это не оправдание.

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

Пакет у всех пользователей проходит стадии 1->2->3, где на каждой стадии отрабатывает какой нибудь скрипт для миграции, а ты делаешь сразу 1->3, проблемы непредсказуемы в таком случае.

Это не оправдание.

Чему? Проблема есть, а они везде есть. Я еще не видел идеального дистрибутива, везде что то надо собирать, настраивать. Эта решается очень просто.

Да вообще просто как два пальца иди компелируй

Пакет у всех пользователей проходит стадии 1->2->3, где на каждой стадии отрабатывает какой нибудь скрипт для миграции, а ты делаешь сразу 1->3, проблемы непредсказуемы в таком случае.

Пакет обновляется несколько раз в месяц и каждый раз какая-то миграция, да такая что состояние 3 после 1-2-3 не вызывает проблем, а состояние 3 после 1-3 вызывает? Ну честно, выглядит как надуманная проблема. Либо очень серьезный косяк мейнтейнера, несовместимый с жизнью. Были ли реальные прецеденты?

Я не видел у них в вики конкретных рекомендаций по частоте обновления и ничего в целом не указывает на то, что обновляться надо именно раз в день или раз в час, чтобы что-то не пропустить.

Частичные обновления - да, могут быть нестыковки по версиям.

Чему? Проблема есть, а они везде есть. Я еще не видел идеального дистрибутива, везде что то надо собирать, настраивать.

Идеального нет, но ядерные поломки в дистрибутиве, который бешено роллит эти самые ядра, набивают оскомину. А selinux это вообще атас

В wayland нет wm.

спросить конкретно о последней UBUNTU

У меня правило: не хочешь проблем - ставь UBUNTU LTS HWE предыдущей версии. И поддерживается, и никаких неожиданностей.

Жуть.

Жуть это дистрибутивы с ПМ, вот красивый пример Удаление deb-пакетов с некорректными pre- и post-скриптами

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

Windows, Mac, z/OS, ... нигде такой системы с ПМ нету.

Даже в Linux, намучились с ПМ, теперь пытаются от него сбежать в Snap, Flatpak, AppImage. Выбрали вариант Slackware, но кривой. В Snap берется стабильная базовая система, а на нее накатывается слой программы. В Slackware так всегда было, есть базовая система, сверху можешь ставить пакеты из alienbob, tar.xz, slackbuilds.org.

рацпредложение отсюда

я юзал void, и glibc, и недоделанный musl. под void мне очень не хватало чего-то nix-подобного, или скорее – guix подобного.

поэтому я тупо взял janet, hermes и пересобирал некоторый нужный мне софт под них.

janet: janetlang диалект лиспа вроде scsh по смыслу, но простой и вполне функциональный с батарейками.

hermes: см. репозиторий gh.com/andrewchambers/hermes

интро в бложике.

quickstart.md

ебилды в этом репозитории: gh.com/andrewchambers/hpkgs

если как-то обобщить, подытожить и сделать выводы.

gentoo: ебилды на питоне у которого регулярно ломают EAPI. киллер-фича – прокидывание USE-флагс чтобы долбаться с разными несовместимыми конфликтами в конфигурации USE=-feature => ./configure.sh --disable-feature=feature и т.п.

ценность что можно запилить свои оверлеи, и писать свои ебилды. например, для кросс разработки (как-то делал для себя оверлей под mingw кросс из-под генты)

arch, crux: ебилды на bash. arch: AUR с оверлеями

void: xpbs-src и прочие. качаем всю пакетную базу в одно место, как в funtoo. и делаем свой форк и добавляем свои ебилды в форк.

void: musl, glibc в одном дистре. USE-флагов нет. в остальном довольно приятный минимализм, хотя с запуском dbus и прочего нужно руками прописывать. runit опять же, нет этого поганого systemd.

nixos: elco dostra и прочие про reproducible build. почему обычно не воспроизводимые сборки – поставь lfs по книжке и задумайся, зачем там gcc как в генто по три раза пересобирают. или как протечка в environment влияет на use-флаги и прочие фичи итоговых бинарей.

nixos: nix пакетный менеджер на диалекте хаскеля и функциональная чистота «ебилдов». по сути получается примерно как в арче или в crux когда функциональщина запускает тот же баш. guid-контент адресуемая память чтобы хранить артефакты сборки. nixpkg работает как демон. умеет nix довольно много, например, можно осилить гидру как ферму типа билдбота или дженкинса.

nixos: с функциональной чистотой конфигураций и перегенерерацией конфигов из configuration.nix и home-manager и прочих flakes — где-то переборщили. например, базу данных было бы удобнее не пересоздавать из конфига а ставить руками.

то есть, nixpkg вполне неплох и им даже можно собрать себе lfs-подобное. но нужно изучать свой недохаскель для ебилдов и возиться с функциональной чистотой и воспроизводимостью файлов и конфигураций, что иногда не очень нравится.

guix: nixpkg переписали на scheme guile, например g-monads и прочее.

пользоваться в смысле написать ебилд проще чем в nixpkg. в каком-то смысле они повёрнуты на gnu/guix, то есть некоторые вещи как в дебиан не совсем работают из коробки (например, те же virtualbox-extensions и прочая проприертарь).

в основном, довольно неплох.

hermes: упрощённый nixpkg/guix который только для сборки.

есть контент-адресуемая память для сборки артефактов, нету всех фич полноценного пакетного менеджера.

по сути мы можем только собрать наподобие nix flakes.

в основном, этого и достаточно.

ебилды (hpkgs) написаны на janetlang,как макросы и DSL поверх лиспа.

например, см. hpkgs…autoconf.hpkg:

тут тебе и defsrc и sh/$ и модульные import/use.

то есть, я бы сказал что janetlang+hermes = сборка musl совместимого дистрибутива линукса типа lfs.

в void/musl или void/glibc можно посравнивать возможности ебилдов на xpbs-src и hermes.

эдакий минималистичный guix.

в общем, по твоему рацпредложению – нужно брать почти любой нормальный дистрибутив типа void или crux/arch и писать ебилды под hermes/janet – получится минималистичная сборка в целевой musl дистрибутив, минималистичный как lfs или тот же void.

так что «адаптировать всё под musl» проще бы и удобнее получалось под тот же hermes/janet, раскрученный поверх почти любого разумного bsd-подобного lfs дистрибутива, например void/glibc для тестирования, void/musl для минимализма, или crux или arch или даже debian из практических соображений полноты пакетной базы «из коробки».

самое заморочное, конечно — нудное тестирование чего там именно в musl не реализовано из того что работает из коробки в glibc, и что на этот раз отвалится в статической сборке.

то есть, можно тот же sta.li поковырять в смысле минимализма.

Даже в Linux, намучились с ПМ, теперь пытаются от него сбежать

Вы немного не в ту сторону возмущаетесь. Проблема не в ПМ.

А в чем?

Если обобщить - то легаси.

Разделяемые быблиотеки, которые рулили полвека назад, до сих пор не отправлены на свалку. Вместо этого городят флатпаки и прочее непотребство.

ПМ лишь пытается разрулить весь этот Адъ, с переменным успехом.

Ты не сможешь все статически слинковать, у тебя простейшая программа будет весить гигабайты. Хотя бы mesa, gtk, libc у тебя должны быть системными. Библиотеки это не только код, но и ресурсы, конфигурационные файлы, настройки.

до кучи (раз уж в том топике от анонов огородили):

Если бы вам выдался шанс переписать Linux с нуля

это было бы что-то похожее на QNX6 или L4.

никакого wayland и systemd. пускай тренируются на кошечках – не на моём компьютере.

в качестве GUI – Photon вместо XWindows, MGR, Plan9 rio, да тот же самый X11.

hermes/janet в качестве пакетного менеджера.

по возможности, не использовать C++ вообще. или хотя бы – там где можно без него обойтись. иначе капец минимализму.

вообще, всякий толстый раздутый софт на С++ – по возможности не тащить.

C реализацию раскручивать из tcc64, mes или DuskOS C на форте (<10k строк).

остальное – часть поверх базовой системы, часть самосбор каноничного «на самом себе».

базовая система как в FreeBSD или Plan9 – стабильная.

«надстройка» как модульный оверлей на hermes/janet.

микроядро чтобы позалипать, но в целом можно и монолит типа LFS или busybox/toybox.

этакий минималистичный BSD/LFS.

подозреваю, что меня бы и Plan9/Inferno или вот 9ferno/purgatorio (Dis64 и limbo 64-Битное, форк под AMD64) вполне устроил.

но это опять же, см. пунктик выше. «не использовать glibc, C++ – там где без него не обойтись» – но эти метастазы по ходу по всей системе, так что уж не сильно принципиально.

ещё можно TempleOS попробовать, ZealotOS там, например.

только правильную святосишечку HolyC заменить на что-то похожее на plan9 си или там 9ferno limbo64.

а так под ось храма слишком дофига переписывать. хотя оно ещё более минималистичное чем любой линакс.

ещё можно под каноничные BSD под SIMH эмулятор или там bkunix под архитектуру PDP-11 (БК-001?[m?]) позалипать, весьма увлекательный миниюникс – БЗД каноническое.

или там демос, инмос и прочее советское BSD.

Не будет она весить гигабайты, это мифы Древней Греции.

Когда-то экономили килобайты. А если вас тревожат гигабайты, то это к фреймворкам и рантаймам. Они жрут место независимо от линковки.

Не будет она весить гигабайты, это мифы Древней Греции.

Будет, что ты статически выкинешь из mesa, gtk? Там почти все друг с другом связано, ну даже выкинешь ты 60%, все равно гигабайт выйдет минимум. Где оно настройки будет держать, они разных версий, разных форматов, у каждого приложения все свое? Драйверы тоже приложение за собой будет таскать как под DOS? Все то вы хотите испортить простую идею, и сделать все как можно хуже.

Все то вы хотите испортить простую идею, и сделать все как можно хуже

Простое - не значит лучшее. Вы как-то не очень стремитесь размахивать каменным топором, хотя в вашей системе координат - он идеален.

Если бы современные инструменты проектировались в расчете на совместимость с каменными орудиями, то я сейчас это бы не писал.

И я как раз хочу, чтобы было лучше.

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

Если бы вам выдался шанс переписать Linux с нуля

в реконструкторском смысле специальной олимпиады:

1. берём мультикс изначальный, и запускаем под эмулятором

2. берём у Сергея Вакуленко (который bkunix, LiteBSD см. также 4.4BSD-Lite2 ) реализацию диалекта PL/1 под названием XPL:

2.1. исходники на XPL : sergev/vak-opensource/….languages/xpl
2.2. сам XPL конпелятор транспилятор

3. под эмулятором пытаемся собрать мультикс под XPL, попутно выясняя различия между PL/1 из мультикса и диалекта XPL

3.3. чего не хватает на XPL – пишем на встроенном си (XPL транслируется в Си, так что по сути 2.2 – это кроссплатформная реализация PL/1 транспилируемая через сишечку)

4. дописываем HAL слой для такого мультикса

5. делаем из этого мультикса юникс, например BSD-подобное минималистичное, или девятый план.

по сути получаем диалект юникса с системным PL/1 (XPL) вместо си.

потом можно UEFI SDK прикрутить и конпелировать PL/1 софты под UEFI под голое железо.

при необходимости вообще от изначального мультиксового ядра отказаться.

переписывая избранные места.

Разделяемые быблиотеки, которые рулили полвека назад, до сих пор не отправлены на свалку. Вместо этого городят флатпаки и прочее непотребство.

Так придумали же NixOS/Guix, только оно что-то не особо взлетело. Собрал программу с нужными зависимостя и вуаля, она всегда работает, в Guix даже можно паковать софт со всеми зависимостями в тарбол и запускать на другой машине, на другом дистрбутиве. guix pack

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

Это все понятно, что людЯм надо галочки ставить, никсосу то сколько годков уже, могли бы что-то и придумать, пользователь тыкнул галку – программа в файл функцию записала, тыкнул в кнопку «окай» – ос пересобралась, не получилось – откатился, сказка) Но ведь разаботчкам дистрибутива же удобно, софт не ломается, другое дело что на каждый чих надо весь граф зависимостей пересобирать… И да, воспроизводимость не уперлась, а разве она там во главе угла стоит? Главная фишка наверно в возможности собирать софт с какими угодно библиотеками, а не с единственной libfoo.so на всю систему, где от смены версии может просто все развалиться

С любого :-)

snapd даже интегрирован в kernel и firmware. Удаление чревато поломкой системы.

Вот пример, когда мне надо было сначала почитать ЛОР. Сейчас накатывал убунту в qemu, и думаю, давай этот мерзкий снап снесу. Сделал ему apt purge. Операция завершилась с ошибкой, но снап вроде изчез из системы вместе с фаерфоксом. Перезагружаюсь - после ввода юзверя и пароля в gdm, черный экран. Вот так.

В 24.04 не пробовал, но из 22.04 у меня получалось его удалять без последствий, правда не из Desktop, а из иных версий.

Но да, поломка при тупых действиях в лоб гарантирована, нужно с приседаниями вроде удаление всех поставленных в него пакетов, отключения демона и сокетов, потом уже удаления его самого.

Но Ubuntu пока что может без него работать, чему порукой Linux Min t.

Если видеокарта невидии, то кеды или гном-гномыч, пока не выйдет 560 версия драйвера или сидеть на 550.78 и sway 1.8.1.

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

а разве она там во главе угла стоит?

Вообще-то да. Именно этим и бравируют.

И да, воспроизводимость не уперлась

а ты тупой, да?

Из консольного установщика арча можно свина поставить

кому интересно, попробовал Debian testing, сразу поймал баг https://gitlab.freedesktop.org/drm/amd/-/issues/2862

Что-то совсем сложно стало…

Мыши плакали, кололись...

что ты как не родной. Помог бы лучше: ubuntu 24.04 и сеть

ИИ предлагает

А если тебе ИИ предложит убиться о стену - убьёшься?

Не, я могу только подсказать как в Генту настроить. Но в целом, я бы оставил все как есть,: раз выбрал себе Ubuntu Server, то и со Snap на машине ты согласен, если проблема в этом. Настраивается как обычно, через nmtui.

ну конечно! https://cs15.pikabu.ru/post_img/2024/06/15/9/1718466622174992947.jpg

Я тоже могу в Gentoo настроить. Толку.

И оказалось, что всё в контейнерах, snapd даже интегрирован в kernel и firmware. Удаление чревато поломкой системы.

Убунта выпустила экспериментальный отдельный дистрибутив где все со снапом, но тебя никто не заставляет его ставить. Но и в обычном снап есть и убунта будет расширять его присутствие. Если тебя это так волнует, то есть всякие минты, попос, тухедо и ТД, которые собирают дистрибутивы на убунте без снапа.