С кем я там срался полгода назад по поводу dpkg vs pacman?

Тут надо спросить что ты обзываешь термином «следовать инструкции»?

Меня не интересует твоя демагогия.

Это вообще к делу отношения не имеет. Особенно когда Граб2 не лушче.

Во-первых, лучше, во-вторых, имеет.

«не поддерживаемый» а не «не работает». К тому же «выберите любой из этих» обычно означает «любой из этих». И крайне тупо придираться когда он таки работает.

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

В дистре сказано: скачайте оттуда, соберите так, установите так, пользуйтесь так.

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

Не звизди! Пруфы в студию!

Весь тред - один сплошной пруф.

главная претензия в том ,что практически всё что liksys заливал про Арч и Пакман - пурга.

А Slackware осилишь? До полнофункционального состояния? :)

Вот тут ты не прав! Установочная лайв-система Арча не в состоянии установить работоспособного граба

Устанавливает человек, а не установочная среда. Она – лишь инструмент. Для того, чтобы установить grub-legacy из AUR, даже не надо ставить GRUB2 или любой другой загрузчик. Даже перезагружаться после установки не надо. После того, как pacstrap отработает, тебе надо было выполнить arch-chroot /mnt, сделать su -l kirill_rrr, git’ом забрать PKGBUILD, установить недостающие зависимости, выполнить makepkg и установить полученный пакет с помощью pacman -U. Но если для тебя это сложно, то Arch Linux не для тебя. Это единственный правильный вариант установки этого загрузчика.

less

Но арчвики об этом говорит явно, вообще-то, тебе уже весь тред это доказывают:

The base package does not include all tools from the live installation, so installing more packages may be necessary for a fully functional base system. To install other packages or package groups, append the names to the pacstrap command above (space separated) or use pacman to install them while chrooted into the new system.

т.к. обновлениям «наживую» не доверяю. И перезагружаюсь обычно раз в день.

Это какой вендузячий подход.

а ошибок граб не выдаёт

«Не выдаёт» или «не выдал»?

Лучше бы я Генту разворачивал - там по крайней мере после десятка понятных команд ты получаешь готовую и работоспособную систему!

https://башорг.рф/quote/394695

т.к. обновлениям «наживую» не доверяю. И перезагружаюсь обычно раз в день.

Это какой вендузячий подход.

Да хоть пердячий, честно говоря мне плевать. Я вообще считаю все десктопные операционные системы плохими. Макось лучше всех, хотя всё ещё плоха. Линуксом я пользуюсь не потому, что считаю, что он хорошо устроен, а потому, что он проще всех остальных систем на сегодня. Там минимум лишнего (хотя там очень много лишнего, но в сравнение с вендой или макосью это ничто).

Моя операционная система мечты это:

1. Отсутствие менеджера пакетов. Это ужасное изобретение, его не должно быть.

2. Система должна поставляться единым базовым минимальным образом. На выбор - или консольный образ для сервера без GUI, или графический образ для десктопа или сервера с GUI. Консольный образ это что-то вроде minimal-образов докера. Только туда ещё добавляется ядро. Его главная цель - предоставить все базовые сервисы и библиотеки. Базовые сервисы это systemd, библиотека это glibc. Может быть ещё что-то, но выбор должен быть крайне скуден. И она вообще не обязана соответствовать замшелому POSIX-у в своём устройстве. Графический образ это примерно то же, плюс графика (базовый набор библиотек и shell). Можно обсуждать, что должно входить в минимальный набор утилит для базового графического образа, но это явно должно быть меньше того, что входит в GNOME, например. shell, settings, file manager. И насчёт file manager я даже не уверен. Причём все существующие DE для линукса ужасны, поэтому надо писать что-то новое. Похожее на GNOME, но с нормальным управлением, как в Windows 95 было, с пуском, панелью задач. Взять хорошие идеи со всех операционных систем, плохие (как это сделал GNOME) не брать.

3. Обновления должны быть встроены в initramfs.

4. Должна использоваться продвинутая ФС со снапшотами. LVM или ZFS или BTRFS или BCACHEFS.

5. При обновлении скачивается полностью образ новой системы. По факту могут использоваться бинарные диффы для минимизации трафика, это уже детали реализации. Важно, что обновляется вся базовая система разом и это происходит при загрузке. При обновлении создаётся новый снапшот с возможностью загрузки предыдущей версии, с интегрированными проверками здоровья (если при загрузке после обновления система не загрузилась нормально, обновление помечается сбойным и ждём следующего обновления).

6. Вся базовая система иммутабельная, все мутабельные данные вроде логов и кешей хранятся в отдельных разделах. Ядро, initramfs подписаны, используется правильная криптография и интеграция с secure boot для гарантии того, что там ничего нельзя поменять без ведома пользователя.

7. Для сервера все приложения ставятся через контейнеры. docker, podman, systemd-nspawn, вариантов много. Важно, что они не имеют отношения к производителю ОС. Ты просто ставишь что хочешь, задача базовой системы - обеспечить работу docker-а.

8. Для десктопа тоже используется контейнеризация, хотя тут задача гораздо сложней. Наверное сегодня flatpak ближе всего к тому, что надо. Думаю, что тут хорошего ответа пока нет, как это всё делать.

9. Вся философия в том, чтобы не давать пользователю никакого выбора. Также нужно выкидывать по максимуму все замшелые линуксовые утилиты и привычки (например поддержка нескольких пользователей - бред же, это никому не нужно) и переписывать всё по максимуму там, где это возможно. Ядро переписать невозможно. systemd - спорно. А вот DE нормальных в линуксе нет, DE переписать обязательно надо, и так, чтобы в нём хорошо работали flatpak версии существующих приложений. Философия в том, что производитель (намеренно не использую слово «дистрибутив», т.к. это не совсем дистрибутив, это именно операционная система в исходном смысле этого слова) предоставляет базовую систему и какие-то более-менее стабильные интерфейсы. А весь софт пишут другие разработчики. И к этому софту производитель ОС не имеет никакого отношения. Он его не собирает, он его не рекламирует, он лишь даёт работающий docker, а пользователь сам пишет docker run nginx или flatpak install gimp.

А если вернуться к исходному вопросу - повторюсь, обновления наживую это дичь. Это возможно, но это очень сложно. Поддержку этого надо программировать в софте. Это надо тестировать. Для типичного десктопа это никто не делает и не будет делать. А раз это невозможно сделать на практике, значит и не надо делать, надо обновляться надёжно и атомарно.

Обновление базовой системы должно сопровождаться перезагрузкой. Пускай даже через kexec или systemd soft-reboot, если это надёжно работает на любом железе (в чём я сомневаюсь). Конечно базовую систему нельзя обновлять просто так. Или новая мажорная версия раз в год, или обновление безопасности, тут уже ничего не поделаешь, надо ставить и ребутаться.

А обновления обычных приложений, при условии, что они на 100% изолированы от базовой системы и других приложений с помощью контейнеров - можно и без перезагрузки выполнять, тут проблем нет. Обновили, вывесили уведомление - мол обновление для гимпа готово, перезапустите гимп, чтобы пользоваться новой версией или отложите обновление, если пока не хочется обновляться.

Моя операционная система мечты это:

Как же хорошо, что ОС в большинстве своём всё-таки адекватные люди разрабатывают.

Отсутствие менеджера пакетов. Это ужасное изобретение, его не должно быть.

Хорошо, а откуда в системе появится прикладной софт?

Думаю, что тут хорошего ответа пока нет

А, ну понятно.

Хорошо, а откуда в системе появится прикладной софт?

Пользователь скачает с сайта производителя и установит.

В каком виде скачает? Appimage какой-нибудь, что ли?

Я написал, что не знаю точно. Из того, что я знаю, flatpak наиболее близок к правильному решению (использование контейнеров для изоляции), но я не знаю, насколько он успешно решает другие проблемы, специфичные для GUI, т.к. сам им пока не пользовался. К примеру docker успешно решает все проблемы, специфичные для серверов, его я смело могу рекомендовать (или podman, как менее коммерциализированную альтернативу).

В конце концов можно и просто папку с exe и всеми нужными библиотеками в zip. Это то, как работают десктопные операционные системы вроде винды или макоси сегодня. Но всё же надо как-то прогрессировать… Полная изоляция приложений это нужно и принципиальных проблем с этим подходом я не вижу.

полная изоляция от чего?

Полная изоляция системы и каждого приложения друг от друга.

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

Чтобы у браузера не было доступа к ~/.ssh. Тут я отмечу, что контейнеры не являются непреодолимой преградой для атакующего, но всё же это дополнительный слой безопасности, простого способа преодолеть который нет.

Чтобы можно было удалять приложение на 100%, а не оставляя мегабайты мусора во всех уголках системы, как это происходит сегодня со всеми десктопными операционными системами.

Чтобы можно было обновлять приложение понятным образом, целиком и атомарно.

# grub-install --target=i386-pc /dev/sda
# grub-mkconfig --output /boot/grub/grub.cfg

Всë! 2 команды. Ну, и перед этим место подготовить, если система с BIOS/GPT.

Чтобы можно было удалять приложение на 100%, а не оставляя мегабайты мусора во всех уголках системы, как это происходит сегодня со всеми десктопными операционными системами.

Flatpak/AppImage приложения всë ещë засирают хомяк кэшами, настройками и прочим, и это всë после удаления приложения сиротеет. Мне кажется, единственный вариант избежать этого – контроль над поведением приложения. Изоляция тут не особо помогает.

При правильной изоляции для них создаётся отдельный «виртуальный» хомяк, в котором они видят только то, что они сами создали. И какие-то папки монтируются с хоста, например ~/Downloads в браузер. Если во flatpak это не так, значит его надо дорабатывать.

AppImage, насколько я знаю, это просто аналог самораспаковывающегося zip-архива и к изоляции отношения не имеет. Он ни для чего не нужен, это на 100% бесполезный проект.

Собственно всё, что я описываю, давно есть в Android/iOS. Не прям в таком виде, но в очень похожем. Т.е. я не выдумываю что-то от себя, я просто изучаю существующие ОС и компилирую правильные решения.

Он ни для чего не нужен

Удобно же, не надо устанавливать зависимости, положил куда-нибудь и запускаешь. У меня два - Audacity и Fontforge

Я скачал idea.tar.gz, распаковал в ~/apps/idea и ровно так же запускаю (IntelliJ Idea). И много другого софта.

У AppImage удобства тут два:

1. Образ, как один файл, который монтируется, а не распаковывается.

2. Смонтированный файл read-only, в этом есть и плюсы и минусы.

Что касается монтирования, давным давно есть формат ISO и некоторые менее известные, которые точно так же монтируются. Причём в любой ОС, а не только в линуксе.

Что касается read-only, тут есть минус в том, что авто-обновление уже не организуешь. Та же Idea у меня обновляется сама и это удобно.

В общем зачем они его придумали, я не понимаю. Ничего плохого в этом формате я не вижу, если производители софта им пользуются, то и ладно. Но просто это всё было ещё 30 лет назад и широко используется везде. zip, tar.gz, ISO. Зачем это надо было переизобретать - не понимаю. Возьми ISO, добавь туда autorun.inf - вот тебе и AppImage.

Возьми ISO, добавь туда autorun.inf - вот тебе и AppImage.

Зачем? Скачал и запустил, и никаких автообновлений не надо, это на раз в год. Сделал, что нужно и можно сразу удалить, или оставить.

Сдается мне, ты хочешь андроид. Даже более продвинутый вариант андроида.

Не совсем. В андроиде не используется контейнеризация. Там каждая программа запускается от своего uid, плюс используется selinux. Это нормально работает, но всё же это устаревшая техника. Когда андроид делали, неймспейсы в линуксе ещё не были доступны, сегодня правильней было бы всё делать именно на неймспейсах.

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

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

Т.е. да, если подумать, то может ты и прав. Взять из AOSP всё, связанное с низким уровнем и переписать всё, связанное со смартфонами на десктопные аналоги. Namespaces это в конце концов не самоцель, а лишь инструмент, можно и без них обойтись. С практической точки зрения это может быть проще, чем придумывать всё заново. Хотя это будет ещё дальше от текущих инкарнаций десктопного линукса, чем то, о чём я думал.

С другой стороны с точки зрения доступности текущих приложений такой проект большого смысла не имеет. Если это будет делать небольшая группа разработчиков, то на такую ОС просто не будет десктопного софта, а мобильный софт использовать на десктопе неудобно. Поэтому в любом случае надо ориентироваться на те стандарты, которые в линуксе есть здесь и сейчас и под которые собирают софт. Сегодня это flatpak, X или wayland, POSIX API. Т.е. нужно делать ОС так, чтобы юзер мог успешно запускать уже доступные flatpak-и. Иначе такой проект так и останется пустым shell-ом. Полагаю, что запустить какой-нибудь GIMP из Flatpak под андроидом не выйдет, рантаймы отличаются в корне.

👌Ахах. Я почитал эту ветку до того, как меня позвали))

Смысл спорить с людьми, которые привыкли делать сами себе хуже? Пусть продолжает, мне то что)

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

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

там еще был какой-то медисон нужен

Я не знаю лишь того, что ты своими кривыми руками мог понаставить или не поставить в твоей несчастной инсталляции арча

В третий раз повторяю для тех кто в танке: БАЗОВАЯ ДЕФОЛТНАЯ СИСТЕМА! Которая равна по потреблению памяти тому, что я тебе прислал и да, мне туда пришлось понаставить поддержку сети, mc, less и htop, что никак не сказалось на потреблении памяти. Для особо тугих: проверить потребление памяти на базовой системе без сети и htop можно командой free -m которая в базовом наборе присутствует.

Я время в критической зоне и замерял, кретин.

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

Тем, что при сбое ты не сможешь выяснить его причины.

В чём проблема включить систему логгирования и воспроизвести сбой? В нормальных системах это случается от пары раз в год до раза в пару лет. Причём 90% сбоев изучаются без журналда проще чем с ним.

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

Менее чем 1 проценту.

есть множество способов притушить логи.

Из них самый логичный и правльный это systemctl disable journald.service и никакого вопроса бы не возникло если бы некоторые имбецилы не потратили кучу усилий чтобы это поломать.

Повторяю в десятый, наверное, раз: включи логгирование в память,

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

Меня не интересует твоя демагогия.

Как и отвечать за свою чушь видимо.

И ты наткнулся.

Ложь.

Весь тред - один сплошной пруф.

Ну, чукча не читатель... Давай порассказывай мне как я не умею читать инструкции.

Я знаю что потрачу на это слишком дохрена времени. Вероятно обьше чем на void в своё время.

Ну ладно, не выдал.

Пункты 1, 2 и 3 противоречат друг другу. Без пакетов и с монолитным образом обновления нереальны.

От использования пользователем разумеется!

Полная изоляция системы и каждого приложения друг от друга.

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

Здесь что то не так. grub-install может не выставить boot-флага, а может неправильно прописать образ или сам образ может быть незагружаемым и это почти нереально проверить. grub-mkconfig может сгенерировать какую то фигню, а главный недостаток граб2 это именно кошмарный и геморройный конфиг.

boot-флаг, внезапно, устанавливает/снимает не GRUB, а менеджер дисковых разделов, т.е., всевозможные fdisk, parted и др. Задача у GRUB-а – определить активный раздел диска, установить свой код boot.img в MBR этого диска, установить core.img в неразмеченное, специально оставленное место между MBR и первым разделом, согласно конфига создать меню. Всё. И его поведение целиком зависит от того, как ты напишешь /boot/grub/grub.cfg. И хотя его содержимое генерируется скриптами из /etc/grub.d/*, опираясь на информацию из /etc/default/grub, ничто не мешает написать собственный конфиг руками. Ничего там сложного нет, конфиг почти такой же, как у grub-legacy.

grub-install может не выставить boot-флага

Grub начхать на boot-флаг. И, емнип, никакие флаги он не выставляет.

grub-mkconfig может сгенерировать какую то фигню

Что нашел, то и сгенерил.

Генерируется файл настройки grub …
Найден образ linux: /boot/vmlinuz-linux-zen
Найден образ initrd: /boot/initramfs-linux-zen.img
Found fallback initrd image(s) in /boot:  initramfs-linux-zen-fallback.img
Предупреждение: os-prober не будет запущен для обнаружения других загрузочных разделов.
Их системы не будут добавлены в загрузочные настройки GRUB.
Прочтите документацию на параметр GRUB_DISABLE_OS_PROBER.
Добавляется элемент загрузочного меню для настроек микропрограммы UEFI …
завершено

главный недостаток граб2 это именно кошмарный и геморройный конфиг.

Вы туда руками что-ли лезете? DO NOT EDIT THIS FILE для кого там существует? Или /etc/default/grub для вас «кошмарный и геморройный конфиг»?

Как и отвечать за свою чушь видимо.

Неумение отвечать за свою чушь - это твой главный профессиональный навык, клоун. Это ты по второму уже треду бегаешь с горящей дупой и скулишь, что все вокруг дураки и у тебя отобрали возможность отключить journald. Зачем - внятно объяснить не можешь, просто ХОЧЕШЬ. А после того, как тебе объясняют, какой способ ПРАВИЛЬНЫЙ и как жить, если много логов на машине не нужно - соглашаешься или молчишь, а потом начинаешь свою песню по новой.

Ложь.

Это буквально твои слова, кретин. Ты ставил grub1 и у тебя что-то сломалось. Вот твоя проблема.

Давай порассказывай мне как я не умею читать инструкции.

А что, умеешь? Из всех вариантов загрузчиков выбрать неподдерживаемый, хотя об этом везде написано - это именно что не умеешь читать инструкции.

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

Чтобы воспроизвести сбой, надо знать, что воспроизводить. А если у тебя рандомный вылет - то пойди поймай его еще. Для больших дядей любой вылет - это потеря денег, а для работающих людей - потеря времени. Поэтому причину вылета желательно устранить сразу после его возникновения. Но у эникейщиков, типа тебя, таких проблем не возникает, ты просто идешь переустанавливать систему.

Менее чем 1 проценту.

Нет. Подавляющему большинству рабочих станций и абсолютно всем серверам нужны логи.

Из них самый логичный и правльный это systemctl disable journald.service

Нет. Самый правильный - это способ, предусмотренный проектировщики. Всё остальное - твое бестолковые выдумки, и несоответствие реальности твоим ламерским фантазиям.

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

Потому что смотри первый пункт. Логгирование нужно. Если ты этого не понимаешь, ты просто идиот.

Время там тратится только на первоначальную настройку после установки. Установка же, как и везде – примерно час времени. Тем более, что официальное руководство настоятельно рекомендует делать full install. Но если ты знаешь, что делаешь, то можешь выбрать, что тебе надо, а что – нет. Арч поставить гораздо проще ;)

В третий раз повторяю для тех кто в танке: БАЗОВАЯ ДЕФОЛТНАЯ СИСТЕМА!

В третий раз повторяю: я твоим истеричным визгам не верю. Давай мне сюда список пакетов, а еще лучше - видео с установкой обеих систем. Можешь даже в виртаулку. Ах, да, не забудь, что обе системы должны быть 64-битные. А то мало ли.

Ничерта ты не замерял.

Ты врешь, клоун. Напоминаю: мы замеряли время установки kde ( pacman -Ss kde | grep meta | grep -v kdevelop против kde-full) с примерно одинаковым набором софта, с fsync и без. Критическая зона - это собственно момент записи пакетов на диск и исполнение скриптов, потому что прерывание обновление в этот момент оставит систему в неконсистентном состоянии: от полной неработоспособности до глючности. Если выключить fsync, то pacman работает просто гораздо быстрее. Если использовать дефолтное поведение dpkg с fsync - то тормоза еще более значительные.

Вы туда руками что-ли лезете? DO NOT EDIT THIS FILE для кого там существует? Или /etc/default/grub для вас «кошмарный и геморройный конфиг»?

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

никакие флаги он не выставляет.

Именно так. Boot-флаг снимается-ставится в редакторах таблицы разделов, как я уже выше сказал. Вывод из всего этого треда можно сделать только один – у ТС в голове каша. Он ведь продолжает использовать MBR схему разбиения диска на разделы, несмотря на её ограничения.

Пункты 1, 2 и 3 противоречат друг другу. Без пакетов и с монолитным образом обновления нереальны.

Почему противоречат? Поясни.

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

Да так же, как и сейчас. Через общие папки, например. Через системные интерфейсы. xdg-open, xdg desktop portal или их аналоги. Что ещё за обмен состоянием друг друга?

Что-то я не нашёл команды, которая выставляет boot-флаг, в руководстве ;)

Не выставляет груб никакие флаги. Это ТС нам лапшу на уши вешает -нифига не разобрался в системе, а теперь ноет, что арч плохая система))

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

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

С кем я там срался полгода назад по поводу dpkg vs pacman?

Да вы всё делом заняты, чо.

Хорошего должно быть много :)