Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Доступен дистрибутив NixOS 26.05, использующий пакетный менеджер Nix "	+/–
Сообщение от opennews (??), 31-Май-26, 18:38
Представлен релиз дистрибутива NixOS 26.05, основанного на пакетном менеджере Nix и предоставляющего собственные разработки для упрощения настройки и сопровождения системы. В NixOS вся настройка системы осуществляется через единый файл системной конфигурации configuration.nix. Предоставляются возможности для быстрого отката системы на предыдущую версию конфигурации и переключения между различными состояниями системы. Поддерживается установка индивидуальных пакетов отдельными пользователями и возможность одновременного использования нескольких версий одной программы. Обеспечены воспроизводимые сборки. Для архитектур x86_64 и ARM64 подготовлены установочный образы с графическим окружением (3.7 ГБ) и сокращённым консольным вариантом (1.6 ГБ)... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65587
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 31-Май-26, 18:38	+7 +/–
Guix лучше.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #81

2. Сообщение от kravich (ok), 31-Май-26, 18:41	+5 +/–
>пакет firefox может записываться в /nix/store/8onlv1pc3ed6n5nskg6ad4twcfd0d5ae4ed5c4-firefox-151.0.2 Это строчка в новости на месте, я спокоен
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

3. Сообщение от Аноним (3), 31-Май-26, 18:41	+1 +/–
> Содержимое начального RAM-диска (initrd) переведно по умолчанию на использование системного менеджера systemd. Пора на Guix.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #19, #28, #57

4. Сообщение от Аноним (4), 31-Май-26, 18:42	+4 +/–
Надо больше символов в хэше для большего абсурда!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #39

5. Сообщение от Аноним (4), 31-Май-26, 18:42	+/–
И xlibre?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #53

6. Сообщение от Аноним (6), 31-Май-26, 19:25	–1 +/–
Удалено, прекращено, объявлено устаревшим. Ясно-понятно.
Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от Аноним (7), 31-Май-26, 19:43	–4 +/–
> (initrd) переведно по умолчанию на использование системного менеджера systemd. Поддержка старой реализации на базе shell-скриптов объявлена устаревшей и будет удалена От шока чуть не разлил банановый раф на свой макбук. На какой дистрибутив теперь бежать моей андеграундной душе?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

8. Сообщение от Аноним (8), 31-Май-26, 19:55	+/–
> Из-за отсутствия сопровождающих прекращена поставка варианта ядра linux-rt. На этом дистре вообще люди есть?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #15

11. Сообщение от АнонимХ (??), 31-Май-26, 20:35	–1 +/–
Ну сам же видишь, даже по каментам тут: люди есть на некоем другом дистрибутиве ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #16

12. Сообщение от Аноним (12), 31-Май-26, 20:48	–4 +/–
Systemd-boot минималистичнее grub, и от systemd в нем одно название.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

13. Сообщение от Аноним (13), 31-Май-26, 20:54	+/–
Лучше чем? Guix использует shcema, и как следствие возникает вопрос, а как там обстоят дела с ленью, рекурсией, чистотой. Плюс, поскольку столь много людей писали, что не хотят учить ещё один язык, то что именно они собираются писать на scheme.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #18, #20, #21, #25, #55, #56, #71

14. Сообщение от Аноним (13), 31-Май-26, 20:59	+1 +/–
>Добавлен файл system.nix, позволяющий сконфигурировать NixOS без использования nix-channel. Flakes больше не нужны?
Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от Аноним (16), 31-Май-26, 21:02	–4 +/–
Линукс должен стоят на сервере. И у него должна быть коммерческая поддержка, даже если для аасяна она бесплатная. Сабжу на сервере делать нечего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #24, #41

16. Сообщение от Аноним (16), 31-Май-26, 21:04	+/–
Все кому надо то что в сабже уже есть в Арче/Качи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

18. Сообщение от АнонимХ (??), 31-Май-26, 21:41	+1 +/–
> не хотят учить ещё один язык Его и учить-то не нужно особо! Все, кто добрались до сабжа, минимум разберутся в конфиге Emacs — ну а значит и тут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

19. Сообщение от Аноним (20), 31-Май-26, 22:44	+/–
Или на PantherX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

20. Сообщение от Аноним (20), 31-Май-26, 22:56	+9 +/–
> поскольку столь много людей писали, что не хотят учить ещё один язык А, то есть в Nix не нужно учить новый язык, который никуда кроме самого Nix нельзя применить, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

21. Сообщение от Аноним (21), 31-Май-26, 23:18	+1 +/–
>Плюс, поскольку столь много людей писали, что не хотят учить ещё один язык Поэтому из язычка одного проекта и универсального языка, рекомендованным GNU для использования в GNU и расширениях GNU очевиднее выучить именно второй. Особенно зная, что спека у него занимает 50 страниц. >как следствие возникает вопрос, а как там обстоят дела с >ленью srfi-45, если нужно. >рекурсией Оптимизация рекурсии была ещё в Lambda Papers в семидесятых. В Nix её вроде нет. Можно хоть делать вид, что рекурсия есть, хоть делать вид, что нет, хоть написать себе паскалевский for. >чистотой Есть чистые и грязные макросы. Чистоту от эффектов и set! определяешь ты сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #27, #33

24. Сообщение от Ivan1986 (?), 31-Май-26, 23:46	+/–
Ну так линукс и стоит на сервере, другого там обычно не ставят, но там обычно не сабж а убунта, дебиан или редхатоподобное, но как правильно отмечают во многих дистрибтивах это универсальная система, поэтому где она только не установлена, сабж же довольно специфичный, поэтому на десктопах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #51

25. Сообщение от Аноним (25), 31-Май-26, 23:57	+2 +/–
> не хотят учить ещё один язык Любой более-менее распространённый ЯП "учится" за день до уровня 'начать делать что-то полезное", если умеешь программировать и знаешь хотя бы один ЯП. Особенно такие простые языки как схема и никс. Те, кто жалуется не умеют программировать. Поэтому выбор между сабжем и Guix по сути выбор между systemd и shepherd. Всё остальное не имеет особого значения. Особенно сегодня, когда можно скормить это всё модели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #34, #61

26. Сообщение от Аноним (26), 01-Июн-26, 00:22	+/–
Это типа Арча, но для более упоротых?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

27. Сообщение от Аноним (13), 01-Июн-26, 01:18	+/–
>А, то есть в Nix не нужно учить новый язык, который никуда кроме самого Nix нельзя применить, да? Вообще-то, это как раз аргумент сторонников guix, а не nix. >Поэтому из язычка одного проекта и универсального языка, рекомендованным GNU для использования в GNU и расширениях GNU очевиднее выучить именно второй. У вас память ограничена, что вы не осилите ещё один язык? И потом, в который раз спрашиваю, что вы собрались на scheme писать? >srfi-45, если нужно Это - не ответ. В том то и проблема scheme, что универсальный язык пытаются воткнуть для решения нишевой задачи. Например, Nix позволяет описывать рекурсивные структуры вида {   a = { b = "c"; };   d = { e = config.a.b; }; } Кроме того, лень необходима, для быстрого вычисления результатов. А вы рассуждаете не как человек, который scheme пользуется, а как виндузятник, рассуждающий о чём-то крайне далёким и неизвестном. >Есть чистые и грязные макросы. Чистоту от эффектов и set! определяешь ты сам. Звучит крайне неприятно. Получается, что произвольный scm файл может при выполнении запустить любой побочный эффект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #59

28. Сообщение от morphe (?), 01-Июн-26, 03:10	+1 +/–
Было: баш портянка в initrd дублирует половину вещей что делает systemd собственно в системе и запускает systemd Стало: systemd запускается в initrd и передаёт управление systemd в системе Отличие в избавлении от баш портянки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #32, #40

32. Сообщение от Аноним (32), 01-Июн-26, 07:20	+2 +/–
Не хватает только systemd-kerneld, и тогда будет: systemd запускается в systemd, загружает systemd и передаёт управление systemd в systemd.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от Тот_Самый_Анонимус_ (?), 01-Июн-26, 07:37	+1 +/–
>Поэтому из язычка одного проекта и универсального языка, рекомендованным GNU для использования в GNU и расширениях GNU очевиднее выучить именно второй. Особенно зная, что спека у него занимает 50 страниц. Только если ты адепт гну и не имеешь своего мнения. А на деле распространение «язык, рекомендованный GNU» мало где нужен, т.к. влияние самого гну на уровне статистической погрешности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #60

34. Сообщение от Тот_Самый_Анонимус_ (?), 01-Июн-26, 07:38	+2 +/–
Угу, если он в той парадигме, в которой программировал ты. А для понимания иной парадигмы надо затратить время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #47, #85

35. Сообщение от Аноним (35), 01-Июн-26, 08:24	+/–
Нет, арч простой как три копейки и его осилит каждый, а тут сборище костылей с постоянно ломающейся совместимостью опций, с 100Гб для системы мало, с десятками поломанных пакетов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #36, #42

36. Сообщение от q (ok), 01-Июн-26, 08:35	+2 +/–
> с постоянно ломающейся совместимостью опций NixOS — для господ, имеющих большое количество свободного времени. > 100Гб для системы мало NixOS — для богатых господ, могущих себе позволить лишний 8-терабайтный SSD. Я, кстати, из числа обоих. А ты продолжай считать свои три копейки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #63

37. Сообщение от Аноним (37), 01-Июн-26, 08:51	+4 +/–
Дистрибутив суперский. Использую на домашней машине. Steam работает отлично в данном дистрибутиве.
Ответить | Правка | Наверх | Cообщить модератору

38. Сообщение от q (ok), 01-Июн-26, 09:10	+/–
После двух лет использования NixOS, пришел к следующей концепции: Ни в коем случае не настраивайте в NixOS всё подряд. Даже home-manager выкиньте нахрен. На NixOS лучше описывать самую базовую часть системы: драйверы, железо, DE. Всё остальное ставьте через podman и flatpak. Таким образом, если нужно обновить какое-то отдельно взятое приложение или сервис, не придется обновлять всю систему и перезагружаться. База + изолированные независимые приложения = будущее.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #45, #48, #49, #52

39. Сообщение от pfg21 (ok), 01-Июн-26, 09:18	+/–
когда эти строчки станут вызывать демонов тогда никосописатели и успокоятся !! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

40. Сообщение от Некто (??), 01-Июн-26, 09:24	+2 +/–
У меня на systemd в initrd система ощутимо дольше грузится. Не знаю, что они там насовали, но я пока на bash портянках посижу. А вот ещё: на systemd сначала появляется ввод пароля на зашифрованный раздел, а потом тут же загружается модуль ядра видео и меняется разрешение экрана, текст уходит наверх, а курсор остаётся где-то посередине... Это выглядит как-то криво.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

41. Сообщение от Аноним (41), 01-Июн-26, 09:42	+1 +/–
Давно ты rt-ядра на серверах крутишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

42. Сообщение от Аноним (13), 01-Июн-26, 09:53	+1 +/–
>с 100Гб для системы мало nix-collect-garbage -d запускать не пробовали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #64

43. Сообщение от Аноним (43), 01-Июн-26, 10:05	+/–
> (initrd) переведно по умолчанию на использование системного менеджера systemd. Поддержка старой реализации на базе shell-скриптов объявлена устаревшей и будет удалена RIP, теперь проект официально можно закапывать. Без почестей. Хотя немного жаль, жил он достаточно долго, но всё хорошее когда-нибудь заканчивается
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от user1985 (?), 01-Июн-26, 10:08	+/–
Интересная мысль! Спасибо! Попробую обкатать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

45. Сообщение от user1985 (?), 01-Июн-26, 10:23	–1 +/–
Начал читать информацию по FlatPak. Возник вопрос: а можно ли с помощью FlatPak установить какую-либо конкретную версию программного обеспечения? Насколько я смог найти информацию, FlatPak позволяет установить только последнюю версию программного обеспечения. Это так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #46

46. Сообщение от q (ok), 01-Июн-26, 10:29	+/–
Нихрена не позволяет. Ну, вообще позволяет, но не так удобно. Во-первых, смотришь коммиты:     flatpak remote-info --log flathub org.chromium.Chromium Выбираешь нужный коммит и устанавливаешь/обновляешь вот такой "простой" командой:     sudo flatpak install --assumeyes --noninteractive flathub org.chromium.Chromium     sudo flatpak mask --remove org.chromium.Chromium || :     sudo flatpak update --commit="$COMMIT" --assumeyes org.chromium.Chromium     sudo flatpak mask org.chromium.Chromium Удобно, правда? Справедливости ради, далеко не всегда это нужно. Лично у меня жестко контролируется только хромиум.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #65

47. Сообщение от Аноним (13), 01-Июн-26, 10:29	+/–
Сейчас даже джаваскриптеры пишут функциональный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #78, #79

48. Сообщение от Аноним (13), 01-Июн-26, 10:30	+2 +/–
>Таким образом, если нужно обновить какое-то отдельно взятое приложение или сервис, не придется обновлять всю систему и перезагружаться Империативные контейнеры изобретены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

49. Сообщение от Аноним (13), 01-Июн-26, 10:32	+1 +/–
>Ни в коем случае не настраивайте в NixOS всё подряд. Возьмите NixOS и кастрируйте до уровня убунты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

51. Сообщение от Аноним (51), 01-Июн-26, 10:56	–1 +/–
Вот ты и ответил вопрос почему на нём никто и не сидит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #99

52. Сообщение от Аноним (51), 01-Июн-26, 10:56	+/–
Зачем тогда сидеть на NixOS ты конечно же пояснять не будешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #54

53. Сообщение от Аноним (55), 01-Июн-26, 11:06	+/–
Да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

54. Сообщение от q (ok), 01-Июн-26, 11:07	+/–
- Легкий патчинг пакетов. Во всех остальных дистрах, пакетный менеджер и сборщик пакетов -- две разные системы. В NixOS сборка пакета с нуля или скачивание готового, рулится одной одним и тем процессом. Например, если хочешь свой RPM-пакет в Fedora, то тебе придется снаряжать ни_уёвую экспедицию-приключение на часа два, с оформлением собственной репы, собственной подписи, и так далее. А в итоге получишь невоспроизводимую херотень. - Легкий rollback на предыдущую генерацию, если драйверы/конфигурация подвели. - Иммутабельность системы. Например, /etc смонтирован как readonly. Никакая херня императивно не доустановится. Эти преимущества распространяются только на окружение. Когда начинаешь их применять к прикладным программам/сервисам, это уже приносит больше вреда, чем пользы. А потому лучше ограничить NixOS той областью, где он лучший из лучших, а не применять его как мужик с молотком, который везде видит гвозди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #67, #90, #93, #129

55. Сообщение от Аноним (55), 01-Июн-26, 12:29	+/–
Как обстоят дела в Guix c Лёнькой? Отлично обстоят, Лёнька там послан дремучим лесом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #58

56. Сообщение от Аноним (56), 01-Июн-26, 12:38	+1 +/–
Правильно я понимаю, что опция: "не пepdолиться с найтройкой системы" - не предусмотрена у обоих дистров как класс?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #62, #75, #89

57. Сообщение от Аноним (71), 01-Июн-26, 13:02	+/–
NixOs, самое прогрессивное De.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

58. Сообщение от Аноним (13), 01-Июн-26, 13:16	+/–
Сопоставимый по возможностям инструмент есть или там нужно самому невелосипедить кустарный суррогат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #88

59. Сообщение от Аноним (59), 01-Июн-26, 14:17	–1 +/–
> У вас память ограничена, что вы не осилите ещё один язык? У нас время ограничено. Мы смертны. И поэтому мы, в отличие от бессмертных рептилоидов с планеты Nёхберу, предпочитаем тратить его на общепризнанно-полезные вещи, а не изучение студенческих поделок, переизобретающих велосипеды, но с квадратными колесами и перламутровыми пуговицами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #74

60. Сообщение от Аноним (59), 01-Июн-26, 14:25	–1 +/–
> А на деле распространение «язык, рекомендованный GNU» мало где нужен, т.к. влияние самого гну на уровне статистической погрешности. Ему достаточно использовать Емакс, чтоб твоё замечание имело ценность на уровне белого шума. Тем более, что в Guix службы описываются на том же языке, что и декларации пакетов. Пока Nёх использует системду с её собственным ("грязным") подходом, и прекращает поддержку альтернатив. Что, почему-то, адептов чистоты, как всегда - очень избирательно, не волнует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #77

61. Сообщение от Аноним (59), 01-Июн-26, 14:28	+/–
> Любой более-менее распространённый ЯП "учится" за день Ты тот самый путешественник во времени, который выучил С++ за 21 день, заменив себя из прошлого собой из далекого будущего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #86, #123

62. Сообщение от Аноним (59), 01-Июн-26, 14:35	+/–
Учитьcя, учиться и ещё раз учиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

63. Сообщение от Аноним (59), 01-Июн-26, 14:51	+/–
> NixOS — для господ, имеющих большое количество свободного времени. Господа заседают в NixOS Foundation на окладе. И заключают выгодные (для избранных лиц) сделки с Пентагоном. Пока ты в поте лица отрабатываешь свой 8-терабайтный автомобиль, взятый в кредит. > А ты продолжай считать свои три копейки. А ты, вместе с другими 2842 подневольными работниками плантации, продолжай копаться в грязи, чтобы за горстку риса наскрести господам-землевладельцам целый урожай к новому релизу, о котором те гордо возвестят на всю округу. Впрочем, судя по "удалено, прекращено, объявлено устаревшим", дураков работать на господ с каждым новым релизом всё меньше и меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

64. Сообщение от Аноним (20), 01-Июн-26, 14:51	+/–
Так они же сами себя удалят!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

65. Сообщение от user1985 (?), 01-Июн-26, 14:55	+/–
Надо попробовать. Я тут ещё поковырял FlatPak. Поискал в нём Qt, но не нашёл. Я правильно понимаю, что Qt из FlatPak-а установить нельзя?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #66, #68

66. Сообщение от q (ok), 01-Июн-26, 15:08	+1 +/–
Qt - это библиотека, а не программа. Флатпак распространяет программы. Если программа использует Qt, то он придет в составе рантайма, который тебе самому ставить не надо -- он поставится сам. Думай про флатпак как про магазин приложений, Android/iOS-style. Из магазина приложений ты ставишь приложения, а не библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #76

67. Сообщение от Аноним (59), 01-Июн-26, 15:21	–1 +/–
> Легкий патчинг пакетов. Который в нормальных дистрах, где не сломали FHS, не огребали с rpath, и пакеты просто работают, конечному пользователю их не нужно исправлять, а потому патчинг ему нужен в одном пакете из десятков тысяч, раз в десять лет. И то, через два дня все исправит сопроводитель, если пользователь догадается тому сообщить. > с оформлением собственной репы, собственной подписи, и так далее Что тривиально для любого разработчика, родившегося не вчера. А главное, в последствии, что очень гибко и удобно в применении (о чём я ещё упомяну ниже). > А в итоге получишь невоспроизводимую херотень. А что мешает никсоводам пихать бинарники из неизвестных источников в декларации и получать тоже самое? Но только под видом ложной "воспроизводимости". "Воспроизводимости" чего, кстати? Ага, если не уточнять, то шалость удалась. > Во всех остальных дистрах, пакетный менеджер и сборщик пакетов -- две разные системы. Само собой. Ведь в нормальных дистрибутивах  собрать пакеты можно на выделенном сервере один раз, а на миллионны клиентских машин тянуть готовые, не требуя от конечных пользователей держать в системе компилятор (тяжело и небезопасно), 32ГБ RAM только для рядового обновления и.. Компилять, компилять, компилять! > Легкий rollback Легко настраивается в любом дистре один раз. Не требуя вековечных страданий с не прекращающим ломаться конфигом. > Иммутабельность системы. Например, /etc смонтирован как readonly. Никакая херня императивно не доустановится. Чтобы догнать и перегнать Винду по количеству перезагрузок? Добавив их после каждой тривиальной правки реестра? > Эти преимущества распространяются только на окружение. Ну, то есть, это обыкновенная замена контейнерам и виртуалкам? А шуму-то было! "Революционный метод дистрибуции ПО!" А оказалось обычный podman на минималках. Только без настоящей изоляции (имитация на симлинках) и неработающими программами в репо. А также кучей проблем в виде поломок конфига и перезагрузок. И неадекватными функции требованиями к железу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #69, #72

68. Сообщение от Аноним (13), 01-Июн-26, 15:36	+1 +/–
>Я правильно понимаю, что Qt из FlatPak-а установить нельзя? Совершенно верно. Flatpak - это суррогат, пригодный только для настольных приложений. Консольные, серверные, библиотеки - всё мимо. И да, если вам особенно неповезёт, то два приложения из flathub будут брать две отдельные версии qt.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #70

69. Сообщение от q (ok), 01-Июн-26, 15:41	+/–
> конечному пользователю их не нужно исправлять Я применяю патчи собственного авторства, которые не отправляю в апстрим, потому что они содержат мою вкусовщину. Что-то вроде конфигурирования, но на уровне патчей. Это та самая "свобода изменять", которую тебе обещал Столлман, и на которую наплевали все дистры, сделав патчинг чрезвычайно неудобным. А в NixOS это буквально     foo = prev.foo.overrideAttrs {       patches = [ ./my-cool-patch.patch ];     }; Всё! Никаких репозиториев, никакого добавления своих ключей в /etc, никакой отдельной процедуры rpmbuild/mock. То, использовать оригинальный пакет или пропатченный, зависит от того, закомментируешь ты те три строчки или нет. > Что тривиально для любого разработчика, родившегося не вчера. А главное, в последствии, что очень гибко и удобно в применении (о чём я ещё упомяну ниже). Нихрена неудобно. Приватный ключ надо еще где-то хранить. Деплоить. Интегрировать в решение для секретов. Ради чего? Чтобы пропатчить строчку кода в одном пакете? > Ведь в нормальных дистрибутивах  собрать пакеты можно на выделенном сервере один раз, а на миллионны клиентских машин тянуть готовые, не требуя от конечных пользователей держать в системе компилятор Значит NixOS -- это нормальный дистр, ведь именно такой подход там и используется. Собранные пакеты кладутся в кеш, а клиентские тянут из кэша. И вот если в кэше не оказалось, тогда собирают сами. В твоих дистрах за тебя решили и приняли одну парадигму. В NixOS доступны обе: binary-based и source-based. Оба одновременно. > Легко настраивается в любом дистре один раз. Не требуя вековечных страданий с не прекращающим ломаться конфигом. Но ты никому не скажешь, что это за такая легкая настройка. А в NixOS ее и настраивать не надо: сразу идет. > Чтобы догнать и перегнать Винду по количеству перезагрузок? Добавив их после каждой тривиальной правки реестра? Именно потому и говорю, что в NixOS надо конфигурять исключительно базу: железо, драйверы, DE. Которые конфигурируются крайне редко. > Ну, то есть, это обыкновенная замена контейнерам и виртуалкам? Ошибся окошком? Потому что прямо сейчас ты уже галлюцинируешь. NixOS -- это операционная система. Как она может быть "заменой контейнерам и виртуалкам" -- не ясно. Примерно как говорить, что "помидор не замена пылесосу! телевизор не замена сковородке!" -- bruh, никто не утверждает, что помидор -- замена пылесосу, телевизор -- замена сковородке, а NixOS -- замена контейнерам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #80

70. Сообщение от q (ok), 01-Июн-26, 15:48	+/–
> пригодный только для настольных приложений Именно для настольных приложений он и задумывался. > Консольные, серверные, библиотеки - всё мимо Консольные зовутся на раз-два. Для серверных уже есть OCI-контейнеры. А библиотеки не являются зависимостями конечного пользователя. Пользователь не использует библиотеки -- их используют приложения. Наглядная схема, чтоб было подоходчивее:     пользователь   ---использует-->   приложение   ---использует-->   библиотека > если вам особенно неповезёт, то два приложения из flathub будут брать две отдельные версии qt Говоришь так, словно Qt занимает гигабайты пространства. Размораживайся уже, времена 640 Кб уже давно в прошлом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #73

71. Сообщение от Аноним (71), 01-Июн-26, 15:49	+/–
NixOs, лучшее Ос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

72. Сообщение от Аноним (13), 01-Июн-26, 15:59	+/–
>Который в нормальных дистрах, где не сломали FHS steam-run-free изобретён >конечному пользователю их не нужно исправлять Вопрос весьма дискуссионный. Например, у вас есть патч, который по каким-то причинам не принимают авторы пакета. >Что тривиально для любого разработчика, родившегося не вчера. Написать несколько строк на Nix, которые можно закинуть хоть github, это куда проще, чем делать грязное(антоним чистому) решение с репозиторием. >А что мешает никсоводам пихать бинарники из неизвестных источников в декларации и получать тоже самое? У вас будут предельно конкретные бинарники, а не спагетти из неизвестных файлов. >Ведь в нормальных дистрибутивах  собрать пакеты можно на выделенном сервере один раз, а на миллионны клиентских машин Двоичный кеш изобретён. Более того, если брать пакеты по умолчанию, то в отличии от генты, они не будут компилироваться. >Чтобы догнать и перегнать Винду по количеству перезагрузок? Добавив их после каждой тривиальной правки реестра? Нет. Это реализовано поверх символических ссылок, которые атомарно заменяются. Перезагружаться после этого не надо. Ничем не хуже условной убунты. >Ну, то есть, это обыкновенная замена контейнерам и виртуалкам? Nix не занимается изоляцией. >А оказалось обычный podman на минималках Для получения эквивалентного решения, вы утонете в инфраструктурной сложности быстрее, чем получите приемлемый результат. >и неработающими программами в репо Очередная ничем не подкреплённая фантазия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #84

73. Сообщение от Аноним (13), 01-Июн-26, 16:06	+/–
>Консольные зовутся на раз-два. Для серверных уже есть OCI-контейнеры. Вместо одного инструмента у вас будет несколько. >Пользователь не использует библиотеки -- их используют приложения. Программисты - используют. >Говоришь так, словно Qt занимает гигабайты пространства. Размораживайся уже, времена 640 Кб уже давно в прошлом. Приложения во флатпаках не разделяют библиотеки. Чем больше приложений вы поставите, тем больше будет потребление памяти, за исключением малого процента, который вынесли в рантаймы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #82

74. Сообщение от Аноним (13), 01-Июн-26, 16:15	+1 +/–
>У нас время ограничено. Мы смертны. Да? Изучение Nix - это буквально открыл пару мануалов, и уже пишешь код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

75. Сообщение от Аноним (1), 01-Июн-26, 16:15	+/–
Если говорить про guix, то никакого красноглазия тут нет, по крайнеймере для обычного домашнего использования. Документация довольно хороша и охватывает все необходимое (хотелось бы больше примеров конечно, но и так неплохо). Довольно просто настроить и использовать, при этом куча плюшек сверху, как например обновление или пересборка софта со своими опциями не дожидаясь ментейнера. В общем-то все сделано удобно и предсказуемо (продуманный cli), конечно не без нюансов: для уверенного пользования хорошо бы разобраться с системой сборки софта, но это не рокет сайнс. Короче говоря, для конечного пользователя работает как условная убунта (до того момента, когда нужно опакетить что-то эдакое :)). В этом случае можно обойтись каким-нибудь distrobox/flatpak/nix/appimage, да хоть заворачивай в скрипт guix shell с эмуляцией fhs. В последние годы дела в guix стали гораздо лучше, в плане пакетов, сервисов и обновлений, особенно после переезда на codeberg. Первое впечатление может быть не «вау», но как только распробуешь, уже не захочешь возвращаться на классический дистрибутив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

76. Сообщение от user1985 (?), 01-Июн-26, 16:21	+/–
Спасибо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

77. Сообщение от Аноним (13), 01-Июн-26, 16:23	+/–
>Ему достаточно использовать Емакс, чтоб твоё замечание имело ценность на уровне белого шума. Emacs - далеко не самый популярный редактор, чтобы говорить "достаточно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #103

78. Сообщение от Аноним (78), 01-Июн-26, 16:29	+1 +/–
ага, городят коллбечный адок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

79. Сообщение от Аноним (78), 01-Июн-26, 16:33	+/–
ага, городят коллбечный адок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

80. Сообщение от Аноним (59), 01-Июн-26, 16:35	+/–
> Это та самая "свобода изменять", которую тебе обещал Столлман, и на > которую наплевали все дистры, сделав патчинг чрезвычайно неудобным. Дистры - это, прежде всего, коллектив. Если ты часть этого коллектива, у тебя есть доступ к инфраструктуре. Правишь исходники в общем репо, тянешь сборку из тестовой ветки с сервера. Экономишь киловатт и своё время. Но и гордым "независимым" индивидуалистам, никто не запрещает создать своё локальное репо с переопределениями пакетов, от которых они так "независимо" зависят. Хотя могли бы разрабатывать и сопровождать всё сами! С нуля! Тогда бы у них, правда, не осталось СВОБОДНОГО времени проклинать Столлмана, а это большая потеря для Опеннета! (Не, ну как ОН, во всех бедах виноватый, мог так преступно нас всех не осчастливить! Мы ждём когда к столу подадут "свободу по-свободски" уже 30 лет! Официант! Сколько нам ещё осталось, сложа руки, ждать?!) >       patches = [ ./my-cool-patch.patch ]; Эка невидаль! Это и в PKGBUILDе одна строчка. > Приватный ключ надо еще где-то хранить. Для локальных реп не обязательно подписывать пакеты. Для не нелокальных - тут и Nёх ничем не поможет. > В твоих дистрах за тебя решили и приняли одну парадигму. За меня разделили на модули в соответствии с принципом наименьших привилегий. А не свалили всё в кучу. Нужны патчи - тяну сырцы, компилятор и компиляю. На отдельной машине с 16ГБ RAM. На другие - тяну пакеты из кэша пакетов. Там хватает 4ГБ RAM за глаза. Против только банкиры - закредитованность населения снижается. Не нужны патчи - беру собранный из реп (с зеркала), проверяю подпись, проверяю воспроизводимость [сборки из исходников]. Автоматически, разумеется. Используемое включается, на неиспользуемое - никаких дополнительных расходов. > Но ты никому не скажешь, что это за такая легкая настройка. Я - нет. Но, по-секрету, ходят слухи, что на ArchWiki знают как. Но я - могила. > в NixOS ее и настраивать не надо: сразу идет. Само-собой. Иначе как бы перезагружать систему после каждой правки конфига. Сущий ад! В других дистрах, где всё просто работает, ни как в этом, это по умолчанию нужно не каждому. У большинства система грузится за секунду, и они не знают, что можно выбрать какие-то загрузочные опции и даже не знают зачем. > NixOS -- это операционная система. Ты определись. Если ценно в ней, по твоим словам, только окружение, а саму её лучше лишний раз не настраивать (и, от себя добавлю, вообще не ставить), то остаётся только Nix (nix-env). А чем он лучше того же systemd-nspawn? В последнем, хотя бы, изоляция настоящая, ядерная. И хостовую систему можно выбрать любую, например такую, где пакеты из реп сразу работают, без лишнего патчинга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #83, #91, #117

81. Сообщение от Аноним (13), 01-Июн-26, 16:42	+/–
Кстати говоря, в Guix завезли релизы, или там каждый раз может что-то отвалится, например, при смене версии плазмы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

82. Сообщение от q (ok), 01-Июн-26, 17:00	+/–
> Вместо одного инструмента у вас будет несколько. Да. Каждой задаче - свой инструмент. Или ты предпочитаешь неповоротливый награможденный комбайн? > Программисты - используют. Программисты ставят библиотеки из реп дистра. Или из реп экосистемы своего языка (cargo, npm, pypi, etc.) Флатпак не задумывался как среда для разработки. Он распространяет уже готовое. Попытка использовать флатпак для вещей, для которых он не задумывался -- признак комбайн-ментальности, противоположный UNIX-way. > Приложения во флатпаках не разделяют библиотеки. Чем больше приложений вы поставите, тем больше будет потребление памяти, за исключением малого процента, который вынесли в рантаймы. Разделение библиотек -- это фантастика. В дистрах прилагают массу усилий, чтобы в системе была лишь одна версия какого-нибудь ffmpeg, а все остальные бы использовали только ее. Ты этих усилий не видишь, а я, как тусовавшийся в дистро-мейнтейнерных кругах, вижу дохренища патчей по адаптации прог к той версии либ, которые присутствуют в дистре (а не те, которые предпочел сам разраб). Это добавляет массу времени на тестирование и сопровождение. Это та причина, по которой обновления доходят до тебя за месяц, а не ровно в ту же минуту, когда разраб зарелизил софт. Можно долго рассуждать на эту тему, но самая лучшая версия либы -- это та, с которой протестировал сам разраб. И про диск/RAM не задвигай тут. Не в 1980-ые живем. Терабайты диска, гигабайты рама. Чему там не влезть -- не ясно, хоть сто копий Qt держи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #98

83. Сообщение от q (ok), 01-Июн-26, 17:14	+/–
> Если ты часть этого коллектива, у тебя есть доступ к инфраструктуре. Я тебе уже указал, что я применяю патчи, против которых будут все. Потому что они отражают лично мою вкусовщину. Я не хочу их отсылать куда-то. Я хочу инструмент, который позволяет патчить вещи за пару минут. > никто не запрещает создать своё локальное репо с переопределениями пакетов В NixOS у меня нет необходимости создавать репозиторий. Нет необходимости обслуживать плюс одну вещь. Вдобавок, если nixpkgs обновит версию пакета, то мой патч просто применится и к нему. А в "своем локальном репо" мне придется заново вбивать rpmbuild/mock -- каждый раз. > Эка невидаль! Это и в PKGBUILDе одна строчка. В моем случае, я не ввожу плюс одну дополнительную команду по сборке пакета. Как он был nixos-rebuild, так и останется nixos-rebuild. Одна команда для обновления, сборки, скачивания и так далее. Ровно одна. Будет он собирать или скачивать -- зависит от того, закомментирована ли строка. Но команда -- одна. Твой дистр так может? > Для локальных реп не обязательно подписывать пакеты. А я иду максимально безопасным путем, выбранным в дистре. Если максимально безопасный путь в твоем дистре подразумевает головняк, то это фигня, а не дистр. В моем дистре, максимально безопасный путь -- это все та же одна команда nixos-rebuild. > Нужны патчи - тяну сырцы, компилятор и компиляю. > Не нужны патчи - беру собранный из реп Молодец! А в случае с nixos-rebuild, он сам проверяет, нужно качать сорцы или нет. Вот прикинь? Качать сорцы, качать компилятор, компилирование, скачивание бинаря из кэша -- это все делается единой командой nixos-rebuild. В этом главное преимущество: в nix-файле ты пишешь, *чего* ты хочешь достичь, а он уже решает, *как* этого достичь. > ходят слухи, что на ArchWiki знают как Неплохая вики, но тот факт, что ты отсылаешь туда, уже говорит про то, что вопрос очень непростой, и придется помучиться. Туда идут от безнадежности. Качество статей -- замечательное, но если ты там оказался, значит у тебя серьезная проблема, требующая серьезного изучения вопроса и гигантского количества свободного времени. > В других дистрах, где всё просто работает, ни как в этом, это по умолчанию нужно не каждому. Если в других дистрах все просто работает, то почему как минимум версию ядра дают выбирать в грубе? Несостыковочка, однако! А в NixOS ты выбираешь версию ядра + конфигурацию всей системы, как единый юнит загрузки. > остаётся только Nix (nix-env). А чем он лучше того же systemd-nspawn? Опять сравниваешь несравниваемое. Чем пылесос лучше сковородки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #87

84. Сообщение от Аноним (59), 01-Июн-26, 17:17	+/–
> Например, у вас есть патч, который по каким-то причинам не принимают авторы пакета. Сомнительно. Если не принимают, есть резон? Надо исправлять патч? Эгоистичное решение - переопределение пакета в локальном репозитории. > Написать несколько строк на Nix, которые можно закинуть хоть github, это куда > проще, чем делать грязное(антоним чистому) решение с репозиторием. Пару команд в консоли для того, пару - для сего. Один раз в десять лет. О чём вообще спор? Настоящая проблема - это завязка на одного единственного поставщика услуг (M$), который банит неугодных за неправильное гражданство или за что ему ещё в голову взбрёдет. > У вас будут предельно конкретные бинарники, а не спагетти из неизвестных файлов. Серьезно? В пакетах предельно конкретные файлы, у каждого подсчитана контрольная сумма и совпадает с источником-отправителем. Доставка прошла успешно. Вопрос доверия к отправителю (его инфраструктуре) как решать будем? > Двоичный кеш изобретён. Compile cache? Давно в курсе (https://wiki.archlinux.org/title/Ccache). > Более того, если брать пакеты по умолчанию, то в отличии от генты, они не будут компилироваться. Это называется кэш-пакетов. Понимаю, типичный пользователь NixOS, как Rust-программист, ничего кроме не использовал, но совершенно убежден, что у него всё самое лучшее и передовое, ведь так в рекламе рассказывали, а в рекламе не могут врать. > Nix не занимается изоляцией. О том и речь, что ничего полезного он не делает. Делает то же, что и другие, но спотыкаясь на каждой кочке. NIH-синдром во всей красе. Не станем разбираться, как и почему так делают другие, мы художники, у нас своё, ни своим, ни чужим опытом не подкрепленное, ВИДЕНИЕ. > Для получения эквивалентного решения Эквивалетное - не нужно. Нужно работающее и удобное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #96

85. Сообщение от Аноним (25), 01-Июн-26, 17:39	+/–
Ещё раз: если ты умеешь программировать, то начать пользоваться новым языком (или понять новую парадигму) дело одного дня. Если не умеешь, то будешь ныть про синтаксис, конструкции, и почему всё не так как в xyzlang. С ллм это всё на порядок проще: пишешь код, который делает то, что тебе нужно на языке который ты знаешь, ллм переводит его на другой язык и объясняет что чему соответствует. Если кто-то не может осилить даже это, он ошибся профессией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

86. Сообщение от Аноним (25), 01-Июн-26, 17:41	+/–
Выучить и начать делать что-то полезное -- две разные вещи. Если тебе что-то полезное начать делать надо, а не экзамен по крестам сдать, дня хватит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #121

87. Сообщение от Аноним (59), 01-Июн-26, 17:51	+/–
> Я хочу инструмент, который позволяет патчить вещи за пару минут. GNU patch. > В NixOS у меня нет необходимости создавать репозиторий. Нет необходимости обслуживать плюс одну вещь. Репозиторий - суть директория, куда попадают собранные пакеты перед установкой, плюс база данных пакетов. Обслуживание - добавление записи о новом пакете в базу данных. Это всё - пара команд и предельно автоматизируется при сборке, очевидно. > Как он был nixos-rebuild, так и останется nixos-rebuild. Как он был makepkg, так и останется makepkg. Только без перезагрузки. Придётся привыкнуть. Понимаю, иногда самому хочется перезагрузить всё к чертям, но нужно себя сдерживать. > Будет он собирать или скачивать -- зависит от того, закомментирована ли строка. Но > команда -- одна. Твой дистр так может? Нет. Так не может. Мы условились, что для разного поведения нужны разные команды (или аргументы команд). Иначе не очевидно, что произойдёт, если всё делать одной командой. (Странные мы.) > А я иду максимально безопасным путем, выбранным в дистре. Пакет не уходит с машины. Отправитель и получатель совпадают. Подпись не нужна. Что небезопастно-то? > он сам проверяет, нужно качать сорцы или нет. Вот прикинь? Наверное, это потому, что у меня все пакеты сразу бинарные, кроме тех, которые я собираю сам. Поэтому и проверять там нечего, всё известно заранее? > Неплохая вики, но тот факт, что ты отсылаешь туда, уже говорит про > то, что вопрос очень непростой, и придется помучиться. Туда идут от > безнадежности Туда идут, когда настраивают систему сами. Настройка загрузки системы - вещь нетривиальная, требует общих знаний и некоторой острожности. Впрочем, для типовых сценариев решения обычно готовые и простые. Вот только нужно это далеко не каждому. Но кому нужно, настраивается это единожды, относительно малой кровью, без переезда на другой край света, узучения новых языков и ритуалов. > Если в других дистрах все просто работает, то почему как минимум версию > ядра дают выбирать в грубе? fallback образ существует на случай, если аппаратная начинка изменится и не выйдет загрузиться с "урезанной" версией ядра. Сейчас у многих ноуты, но раньше были ПК, и практиковалось менять в них железки (вроде видеокарт, звуковух и сетевух), что могло сломать загрузку. > Опять сравниваешь несравниваемое. Чем пылесос лучше сковородки? Что Nix делает, что не делали до него? Что он делает лучше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #92, #94, #105

88. Сообщение от Аноним (103), 01-Июн-26, 17:53	+/–
Shepherd намного более гибкий и удобный. Особенно в плане апи. Меня впечатлила возможность добавления примесей других сервисов к своему. Недавно, например, закатывал гуиксом одну софтину в минимальный "живой" образ для виртуалки и описывал для неё сервис. Помимо, собственно, запуска он добавляет правила в nftables, создаёт себе пользователя и группу (на самом деле, это происходит в момент конфигурирования системы, но оформлено как подмешиваемый сервис), назначает дополнительные привилегии исполняемому файлу, создаёт себе директорию. Все эти перечисленные задачи решаются с помощью подмешивания соотсветсвующего типа сервисов, никаких неконтроллируемых портянок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #97, #116

89. Сообщение от Аноним (103), 01-Июн-26, 18:01	+/–
Я не считаю, что guixsd годится в качестве настольной системы (сам guix как вторичный пакетный менеджер, система управления окружениями, опакечивания и сборки образов - отличный инструмент), но удвою предыдущего оратора насчёт cli, в этом guix действительно преуспел и даже обогнал nix, что редкость для gnu-проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

90. Сообщение от Аноним (103), 01-Июн-26, 18:15	+1 +/–
>Легкий патчинг пакетов. Во всех остальных дистрах, пакетный менеджер и сборщик пакетов -- две разные системы. Void же. Про слакобилды и генту молчу. >Например, /etc смонтирован как readonly. И чтобы изменить одну строчку в конфиге, нужно сначала поискать в документации никса, есть ли для этого выделенная опция. Потом понять, что её нет и нужно вставлять кусоком текста через extraConfig. Потом осознать, что в генераторе конфига эта опция уже захардкожена и конфликтует с твоей добавкой, поэтому тебе нужно или патчить его, или костылить подмену своим конфигом. В итоге ловишь дзен и решаешь, что не очень-то тебе это нужно. Профит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #95

91. Сообщение от Аноним (13), 01-Июн-26, 18:16	+/–
>Если ты часть этого коллектива, у тебя есть доступ к инфраструктуре. Если. Вы забываете про наличие форков вроде Debian - Ubuntu - Mint, а то и более длинные цепочки. Тот же Arch, который породил кучу форков, часть из которых совсем-совсем молодые. >Эка невидаль! Это и в PKGBUILDе одна строчка. Ваш pkgbuild научился автоматически пересобираться при выходе новой версии? >В других дистрах, где всё просто работает Сейчас бы рассказывать, как у вас в арче всё работает, после ручных доработок напильником за недопоактентым менеджером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

92. Сообщение от q (ok), 01-Июн-26, 18:19	+/–
> GNU patch. Ты не понял. Я хочу инструмент, при помощи которого установка дистрибутивного пакета и патчинг пакета -- это задачи одного уровня сложности. Во всех дистрах, установка дистрибутивного пакета -- легкая задача. Во всех дистрах, кроме NixOS, патчинг дистрибутивного пакета -- это плюс два часа работы; а в NixOS -- это плюс две минуты работы. > Как он был makepkg, так и останется makepkg В арче готовые дистрибутивные пакеты ставятся через makepkg? Ай по-изди мне тут. Либо ты тупо не понял, чего я хочу. (см. выше) > для разного поведения нужны разные команды Это называется императивный подход. А есть целый другой подход, о котором ты не подозреваешь: декларативный. При котором ты задаешь сразу желаемое состояние, а не шаги по его достижению. Сравни: - императивный подход: "скачай сорцы (если уже не скачаны), пропатч (если уже не пропатчено), скачай компилятор (если уже не скачан), скомпиль (если уже не скомпилен)..." Дохрена условий, да? И дохрена шагов. - декларативный подход: "мое величество изволит пакет foo, но такой, чтобы к нему вдобавок был применен вот этот патч; исполняй." > Пакет не уходит с машины. Отправитель и получатель совпадают. Подпись не нужна. Что небезопастно-то? Уходит. > Поэтому и проверять там нечего, всё известно заранее? Проверять есть что, просто твой инструмент не может проверять. Тебе приходится ему рассказывать, что делать. Представь, что тебе каждый раз бы приходилось бы объяснять шоферу, как заводить тачку, как ехать, куда ехать... Это твой императивный подход. Быть умнее шофера. Циклиться на деталях. Да, факт необходимости скачивания сорцов -- это деталь. А в моем подходе, я говорю: "Домой." Все. Шофет все сделает сам. Он даже проверит, а не дома ли я уже! В твоем случае, шофер заведет тачку,  даже если ты уже дома. Почему? Потому что ты ему сказал ее завести, а потом отвезти тебя... по тому адресу, где ты уже находишься. Почему? Потому что твой шофер туп как пробка! Тебе приходится самому в своей голове прогонять микро-программу: "а не дома ли я уже... а заведена ли тачка... если заведена, то я не должен говорить 'заведи тачку'..." > Туда идут, когда настраивают систему сами Ты отклонился от темы. Как сделать выбор генераций системы на других дистрах? Ты говорил, что это "просто". > Что Nix делает, что не делали до него? Что он делает лучше? Декларативность (*что* делать, а не *как* делать). Nix предвосхитил Ansible. Nix предвосхитил воспроизводимые сборки. Nix -- это по сути до сих пор единственный пакетник, поддерживающий и source-based, и binary-based доставку софта. Это лучшее из миров Fedora и Gentoo. По многим вопросам, Nix -- это самый лучший пакетник, который остается таковым с ~2004. И до сих пор нет даже ближайших конкурентов ему. По организации дискового пространства, Nix лучше OCI-контейнеров. Контейнеры хранят кучу дублирующих файлов в разных слоях. Nix хранит все в content-addressable store. Короче -- лучшего не найти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #104

93. Сообщение от Аноним (103), 01-Июн-26, 18:21	+/–
>Например, если хочешь свой RPM-пакет в Fedora, то тебе придется снаряжать ни_уёвую экспедицию-приключение на часа два, с оформлением собственной репы, собственной подписи, и так далее. Кстати, OBS у опенсуси. Просто форкаешь нужный пакет, редактируешь рецепт и оно тебе его постоянно собирает с актуальными зависимостями. Такая-то облачная гента.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

94. Сообщение от Аноним (13), 01-Июн-26, 18:25	+/–
>GNU patch. Я набираю одну единственную команду, nixos-rebuild switch, и всё делается автоматически. Вы со своим патчем будете играться вручную. >Как он был makepkg, так и останется makepkg. Только без перезагрузки. Придётся привыкнуть. Вы умолчали про такие вещи, как ручное выкачиваение исходников, установка зависимостей, наложение патчей, сборка пакета и установка пакета. Зато, нагаллюцинировали перезагрузку. >Наверное, это потому, что у меня все пакеты сразу бинарные, кроме тех, которые я собираю сам. Так и в nix точно так же. >Что Nix делает, что не делали до него? Что он делает лучше? Управляет пакетами. Вы вот, например, упорно умалчиваете о том, как набираете команды вручную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #106

95. Сообщение от q (ok), 01-Июн-26, 18:29	+/–
> Void же Ты не поверишь, но до NixOS именно на Void я и пытался перейти. Плюнул, как только выяснилось, что для патчинга пакетов нужно чуть ли не склонировать их репозиторий целиком. Если не согласен с этим тезисом, то покажи, как сделать в Void вот такое:     # Использовать в системе мой собственный ffmpeg, с моими патчами.     # Каждый раз, когда дистр обновляет ffmpeg, продолжать применять к нему мой патч.     # Взять официальное дистрибутивное определение ffmpeg, плюс мой патч.     # Если какая-то программа использует ffmpeg, то она должна линковаться с моим ffmpeg.     ffmpeg = prev.ffmpeg.overrideAttrs {       patches = [ ./my.patch ];     }; На написание этих строк у меня ушла минута. Как это сделать за минуту в Void? > И чтобы изменить одну строчку в конфиге, нужно сначала поискать в документации никса, есть ли для этого выделенная опция. > Потом понять, что её нет и нужно вставлять кусоком текста через extraConfig. Правильно. Мне как разработчику не лень сходить посмотреть официальный апи. Дело дисциплины. > Потом осознать, что в генераторе конфига эта опция уже захардкожена и конфликтует с твоей добавкой Именно такая ситуация возникает редко. И как правило, люди создают issue, и мейнтейнеры с ними соглашаются, давая возможность избежать конфликта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #100

96. Сообщение от Аноним (13), 01-Июн-26, 18:36	+/–
>Сомнительно. Если не принимают, есть резон? Надо исправлять патч? Перепишите патч от linux mint так, чтобы его приняли сначала в ubuntu, а потом в debian. >Эгоистичное решение - переопределение пакета в локальном репозитории. Вы опять галлюцинируете >Пару команд в консоли для того, пару - для сего. Один раз в десять лет. О чём вообще спор? Вы сами выдумали аргумент про раз в десять лет. >Настоящая проблема - это завязка на одного единственного поставщика услуг (M$) Прописываете путь к nixpkgs, и хоть голубями его получайте >Compile cache? https://wiki.nixos.org/wiki/Binary_Cache >Понимаю, типичный пользователь NixOS, как Rust-программист, ничего кроме не использовал Перед тем, как фантазировать про других, сначала посмотрите на себя. >Эквивалетное - не нужно. Нужно работающее и удобное. Возьмите условный haskell, и соберите пакет, который зависит от не haskell библиотеки, например для sqlite.  Добавьте сюда пакет, которого нет в репозитории. Нужна возможность прозрачной замены glibc на musl, включая возможность сборки статических библиотек. Про чистоту и лень тоже не забывайте. А так же, это решение не должно выкачивать десятки докеров. Лёгкость копировать - один файл. Приступайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

97. Сообщение от Аноним (13), 01-Июн-26, 18:37	+/–
И чем это принципиально отличается от модулей? Как к этому добавить изоляцию по cgroup и namespace?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #102

98. Сообщение от Аноним (13), 01-Июн-26, 18:45	+/–
>Да. Каждой задаче - свой инструмент. Или ты предпочитаешь неповоротливый награможденный комбайн? У вас кроме пакетного менеджера ОС есть ещё пакетный менеджер flatpak. А в docker вообще целая операционка, с своим собственным экземпляром coreutils. Если особо повезёт, то из неё ещё и пакетный менеджер вырежут, и образ придётся собирать с нуля. >противоположный UNIX-way. Unix-way - это иллюзия. Поскольку flatpak это комбайн, объединяющий в себя редуцированный пакетный менеджер плюс средства для изоляции. >Разделение библиотек -- это фантастика. И именно по этой причине, в podman у вас в каждом контейнере будет свой собственный bash. >Терабайты диска, гигабайты рама. Чему там не влезть -- не ясно, хоть сто копий Qt держи. Во-первых, поделитесь своими терабайтами, желательно в виде денег. Во-вторых, гораздо логичнее хранить на этих терабайтах что-то полезное, а не дубликаты библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

99. Сообщение от Ivan1986 (?), 01-Июн-26, 18:50	+/–
чел, ты читать умеешь? про более продвинутый скил - понимать что прочитал не спрашиваю, потому что явно нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

100. Сообщение от Аноним (103), 01-Июн-26, 19:00	+/–
>Плюнул, как только выяснилось, что для патчинга пакетов нужно чуть ли не склонировать их репозиторий целиком. Ты не в курсе про git clone --depth=1? Там не так уж много, явно меньше портежей генты. >На написание этих строк у меня ушла минута. Ты забыл про время на чтение документации. >Как это сделать за минуту в Void? Просто добавляешь патч в папку patches/ к пакету и делаешь xbps-src pkg >Правильно. Мне как разработчику не лень сходить посмотреть официальный апи. Двойная работа. Сначала изучаешь доступные опции конфига, потом апи генератора конфигов, а потом... я уже описывал. И зачем? Ничего, кроме головной боли, на настольной системе это не даёт. >Именно такая ситуация возникает редко. Проблема, когда генератор не покрывает и половины опций и требует тех или иных костылей, актуальна для практически для каждого конфига в /etc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #110

102. Сообщение от Аноним (103), 01-Июн-26, 19:21	+/–
>И чем это принципиально отличается от модулей? Логика сборки своих примесей остаётся за сервисом. >модулей Каких модулей? Никсовских? Я уже не помню, как они устроены. >Как к этому добавить изоляцию по cgroup и namespace? Это не входит в задачи shepherd'а, но с контейнеризацией в guix всё хорошо. Вот нагуглилось: >The Shepherd itself remains unaware of namespaces, it simply ends up calling make-forkexec-constructor/container instead of make-forkexec-constructor and that’s it. The changes to the service definitions of BitlBee and Tor are minimal. https://guix.gnu.org/pt/blog/2017/running-system-services-in.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #122

103. Сообщение от Аноним (103), 01-Июн-26, 19:35	+/–
Ты так говоришь, будто существует что-то другое. Мир делится на емакс и его неполноценные клоны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #126

104. Сообщение от Аноним (59), 01-Июн-26, 19:36	+/–
> Во всех дистрах, кроме > NixOS, патчинг дистрибутивного пакета -- это плюс два часа работы; а > в NixOS -- это плюс две минуты работы. Как проводилось это сравнение? Команда склонировать сырцы пакета (скрипты сборки). Команда кинуть готовый патч в директорию с сырцами пакета. Добавить в скрипт сборки команду применения патча. Команда сборки пакета. (Опционально.) Команда установки пакета. Я легко справлюсь за две минуты и ещё успею на построение. И это стандартными средствами, без автоматизации. > В арче готовые дистрибутивные пакеты ставятся через makepkg? Через pacman, как требует Unix-way и принцип минимальных привилегий. Но у makepkg есть ключ, который вызовет pacman, если нужно. Но какая разница? Можно свою обёртку написать единожды и использоваться всегда. Когда всё модульное, собирается как конструктор. Да хоть службу поднять, которая следит за изменениями в репозитории и устанавливает новые пакеты. Кому как удобнее (безопаснее и т.п.) на его локалхосте. > Это называется императивный подход. А есть целый другой подход, о котором ты > не подозреваешь: декларативный. При котором ты задаешь сразу желаемое состояние, а > не шаги по его достижению. Это миф. Нет никакого декларативного подхода. Попытки его изобрести неизбежно сталкиваются с переменчивой реальностью и начинаются сплошные ЕСЛИ. ЕСЛИ архитектура. ЕСЛИ окружение. ЕСЛИ установлено. И прочие ЕСЛИ. В итоге, всё равно, интерпретатор последовательных команд. В данном случае, ещё и написанный на императивном С++. Положи мои команды в скрипт. Назови его pkgbuild. И вот тебе декларация. Только это всё ещё набор инструкций. Потому что это программа для CPU и такова природа CPU - последовательно исполнять инструкции. И сколько в функциональные фантазии не упарывайся, а против природы не попрёшь. > Уходит. Если подписывать принципиально не желаешь, предоставь контроль целостности доставки пакета средству доставки (допустим, rsync). Уж не хуже чем страшилки /nix/store/8onlv1pc3ed6n5nskg6ad4twcfd0d5ae4ed5c4-firefox-151.0.2/. > Проверять есть что, просто твой инструмент не может проверять. Тебе приходится ему > рассказывать, что делать. Просто у меня два инструмента. Один - для сборки, другой - для установки. Если мне нужно было бы работать с ними единообразно, то я бы просто написал обёртку, где искал бы пакет в репе, не нашел - в сырцах. Пара строчек на Баше. Только мне не нужно. Потому что я хочу знать, КАК шофер доставит меня до места назначения. Сушей или морем. По кочкам или с укачкой. За час или за день. Чтобы знать, каких вызовов ожидать от путешествия, к чему готовиться, что взять собой, сколько времени займёт. Если я буду автоматизировать эти задачи, то (пере)сборка будет в свободном временном окошке и на специальном выделенном оборудовании, а установка будет более свободной, иметь минимум требований к железу и времени. > Как сделать выбор генераций системы на других дистрах? И не расскажу. Даже под пытками. > Декларативность Иллюзия. > воспроизводимые сборки Обман. Вот воспроизводимые сборки: https://reproducible.archlinux.org/ > пакетник, поддерживающий и source-based, и binary-based доставку софта Единственный свалил всё в кучу и назвал это преимуществом. > Nix -- это самый лучший пакетник, который остается таковым с ~2004. По версии журнала Космополитан? > нет даже ближайших конкурентов ему А вот это верно. Остальные пакетники решают настоящие проблемы, им некогда решать надуманные. И делают это хорошо. > Контейнеры хранят кучу дублирующих файлов в разных слоях. Дедупликация (файлов или блоков) в файловых системах? Копирование с reflink/hardlink? > Nix хранит все в content-addressable store Угу. Чтоб никто не догадался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #108, #127

105. Сообщение от Аноним (1), 01-Июн-26, 19:47	+/–
>makepkg А потом libfoo обновилось в системе и твой пакет не работает, ну ты конечно пойдешь пересобирать с новой библиотекой, только вот незадача, с этой версией софт уже не собирается или просто падает на старте. И тут ты идешь к разрабу софта слезно просить пофиксить, а то ментейнеры арчика на одном месте вертели твои хотелки)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #107

106. Сообщение от Аноним (59), 01-Июн-26, 20:11	+/–
> Вы со своим патчем будете играться вручную. > Вы умолчали про такие вещи, как ручное выкачиваение исходников, установка зависимостей, > наложение патчей, сборка пакета и установка пакета. Я умолчал, потому что о таком говорить не принято. Только в узком кругу друзей и близких родственников. Вам я могу сказать только одно: "GNU makepkg!". И вот ещё: "GNU Bash!". Не принимайте близко к сердцу. > Зато, нагаллюцинировали перезагрузку. Паранойя и тревожность из-за искусственного интеллекта (ИИ) — это распространенная психологическая реакция на стремительное развитие технологий, которая часто проявляется в страхе потери контроля, недоверии к контенту в интернете или боязни слежки. Такое состояние не является официальным медицинским диагнозом, но в психологии его часто называют «ИИ-тревожностью» (AI anxiety) или «ИИ-паранойей». -- Галлюцинация ИИ >>Что Nix делает, что не делали до него? Что он делает лучше? > Управляет пакетами. Оригинально! Никогда такого не было, и вот опять.. > Вы вот, например, упорно умалчиваете о том, как набираете команды вручную. Я пользуюсь историей команд в командной оболочке. CTRL+R - сами попробуйте. Очень удобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #113

107. Сообщение от Аноним (59), 01-Июн-26, 20:21	+/–
> А потом libfoo обновилось в системе Нет. У нас такого не случается. Нужно самому, явно обновить libfoo вместе с другими пакетами. Наверное, это потому что мы используем разные команды для разных действий. Одного nix-rebuild для всего не хватает, к сожалению. > ты конечно пойдешь пересобирать с новой библиотекой Буду пересобирать со старой, всему миру назло! > этой версией софт уже не собирается или просто падает на старте Так "не собирается" или "падает на старте"? Это две разные проблемы. > И тут ты идешь к разрабу софта слезно просить пофиксить Слезно просить я хожу в комментарии на Опеннет. Во, например, "свободу по-свободски" у Столлмана недавно просил. ("И я всё ещё жду, Ричард!") А патч я и сам могу обычно написать, тем более, раз уж взялся сопровождать этот пакет. > то ментейнеры арчика на одном месте вертели твои хотелки) И правильно делают! Я переживу. Главное, чтоб вместе с моими они вертели и твои, на пару! Чтобы у тебя (и окружающих) был стимул развиваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #125

108. Сообщение от q (ok), 01-Июн-26, 20:24	+/–
> Как проводилось это сравнение? Вот так и проводилось, что ты расписал кучу команд, а у меня на все nixos-rebuild. Понял? Держи шпаргалку NixOS: - скачать бинарный пакет: nixos-rebuild boot (без аргументов, Enter в конце) - скачать сырцы: nixos-rebuild boot (без аргументов, Enter в конце) - скомпилировать пакет: nixos-rebuild boot (без аргументов, Enter в конце) - пропатчить пакет: nixos-rebuild boot (без аргументов, Enter в конце) - установить пакет: nixos-rebuild boot (без аргументов, Enter в конце) > Можно свою обёртку написать единожды и использоваться всегда А можно написать нормальный пакетный менеджер. Что и сделали в Nix. > И не расскажу. Даже под пытками. Потому что не знаешь. > Иллюзия Хочешь сказать, люди с ~2004 пользуются иллюзией и не догадываются об этом? > Потому что я хочу знать, КАК шофер доставит меня до места назначения Я об этом узнаю из логов. Ты об этом узнаешь, набирая одни и те же команды каждый раз. Мы на разном уровне. Технологическое превосходство здесь за Мной. > Обман. Вот воспроизводимые сборки: "Arch Linux is 87.8% reproducible" ахах > Единственный свалил всё в кучу и назвал это преимуществом Это действительно преимущество, ибо в том или ином виде кэш используется в любой системе. Например, браузер не заставляет тебя выбирать, скачивать логотип опеннета заново или брать из кэша. Он тебя не спрашивает и задействует кэш. Тут то же самое. > Остальные пакетники решают настоящие проблемы, им некогда решать надуманные. Если проблема надуманная, то почему ты патчишь пакеты? Лол. Короче, ты уже свалился в тотальнейшую галлюцинацию и denial, как плохая нейросетка. Проблема: как пропатчить пакет? Мое решение: nixos-rebuild boot (Enter в конце, без аргументов). Твое решение: пачка команд, которые еще и вводить надо в правильном порядке. > Дедупликация (файлов или блоков) в файловых системах? Копирование с reflink/hardlink? Файлов. Хардлинки используются. > Угу. Чтоб никто не догадался. Ни разу не было необходимости лезть в /nix/store.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #111

110. Сообщение от q (ok), 01-Июн-26, 20:50	+/–
> Ты не в курсе про git clone --depth=1? Мне не размер важен, а тот факт, что мне где-то надо держать свой форк и обслуживать его. > Ты забыл про время на чтение документации. А еще забыл про время на изучение алфавита, получение образования, изучение компуктера, накопление денег на комп, и далее по списку. От тебя, впрочем, я спрашивал, сколько это займет у продвинутого пользователя void, который всё уже изучил. Меньше или больше минуты? > Просто добавляешь патч в папку patches/ к пакету и делаешь xbps-src pkg Окей. Правда патч будет лежать в форке, а не в моем собственном минимальном репозитории. Грубо говоря, я его должен держать в ~/Projects/void, а не в ~/Projects/my-cool-pc (часть бэкап-плана). > Ничего, кроме головной боли, на настольной системе это не даёт. Дает тотальный контроль. Головная боль возникает, если начинать описывать на Nix прикладную часть, от чего я и советую отказаться (читай корневой коммент внимательнее). > генератор не покрывает и половины опций и требует тех или иных костылей Генератор покрывает только те части конфигов, которые могут быть переиспользованы (запрошены) в каком-то другом месте. То есть, если существует опция services.foo.bar, то она может читаться не только сервисом foo при генерации конфига, но и сервисом xxx, которому тоже почему-то интересно его значение. Например:     services.xxx.enable может требовать, чтобы services.foo.bar был равен false. Если же настройка наверняка не будет никем запрашиваться таким образом, то смысла для нее создавать опции нет. Когда создавать опцию? Это творческий вопрос, ответ на который дается на основании опыта эксплуатации. Если ты программист, то ты в курсе, что бывают вопросы, на которые нет однозначного ответа, и все смотрят на тебя как на носителя опыта, дающего некоторую интуицию. А если ты не программист, то ты эту аналогию наверняка и не поймешь. (И даже не поймешь, что ты ее не понял.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #114

111. Сообщение от Аноним (59), 01-Июн-26, 21:25	+/–
> Вот так и проводилось, что ты расписал кучу команд Я описал алгоритм действий. Его нужно понимать, на случай если на каком-то из этапов возникнут проблемы, чтобы быстро локализовать проблему. А команды наизусть не помню. У меня вообще самописная обёртка под мой сценарий, то есть одна команда после редактирования сборочного сценария. > Держи шпаргалку NixOS А где ещё десять томов веб-документации, чтобы разобраться с тем, что там происходит в декларациях для этого волшебного nixos-rebuild? > А можно написать нормальный пакетный менеджер. Что и сделали в Nix. А "декларации" им зачем? На птичьем языке? "Нормальный" и без сценариев, ведь, должен работать, не? > Потому что не знаешь. Каюсь, не знаю. А зачем? Но рукописи на ArchWiki не горят. > Хочешь сказать, люди с ~2004 пользуются иллюзией и не догадываются об этом? Думаю, что раньше. С момента появления Человека Разумного. С тех пор он находится в плену иллюзизий. > Ты об этом узнаешь, набирая одни и те же команды каждый раз. Обновления могу и службой, они проходят гладко. А сборку - вручную, мне ж придётся править сборочный сценарий, чтобы обновить версию, добавить патчи, если нужно, пока их не принял апстрим. А за тебя патчи в декларацию какая-то волшебная сила добавит? А вот конфиги программ я могу изменить отдельным пакетом: drop-in или alpm-hook. Намного адекватнее, чем писать генератор конфигов на Nёхе под каждый чих. > "Arch Linux is 87.8% reproducible" ахах Почти 88 процентов честно воспроизводимых и работающих пакетов, собранных из сырцов. Это только заявления делать легко, а в действительности бинари в декларациях, полученные неизвестным способом. И куча банально неработающего ПО. > Это действительно преимущество, ибо в том или ином виде кэш используется в любой системе. В описанных случаях кэш используется для экономии времени доставки - копирования. Это и других пакетных системах используется (кэш-пакетов). Но Nёх подсовывает на этап доставки ещё и сборку, у которой совершенного другие требования к системе. > Если проблема надуманная, то почему ты патчишь пакеты? Потому что новый код пишут. Иногда пишут с ошибками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

113. Сообщение от Аноним (13), 01-Июн-26, 21:37	+/–
>Я умолчал, потому что о таком говорить не принято. Вы умолчали, потому, что вы - воинствующе безграмотны. >Я пользуюсь историей команд в командной оболочке. А теперь возьмите проектов хотя-бы пять, с разным набором зависимостей, и перекиньте это на другую машину. Опционально перекиньте тому, кому остальные ваши пакеты не интересны. И да, вы упорно не хотите рассказывать, как вы сделаете при этом прозрачную статическую линковку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #115

114. Сообщение от Аноним (103), 01-Июн-26, 21:42	+/–
>Мне не размер важен, а тот факт, что мне где-то надо держать свой форк и обслуживать его. Всё обслуживание - это периодический git pull. Что ты там ещё обслуживать собрался? А за актуальностью патча тебе и на никсе следить придётся. >Грубо говоря, я его должен держать в ~/Projects/void, а не в ~/Projects/my-cool-pc (часть бэкап-плана). Ничего страшного, забекапишь на 50-100мб больше. Либо сохранишь свои изменения в виде патча, если тебе это так принципиально. >Дает тотальный контроль. Самообман. Ты просто дублируешь /etc на инородном конфигам языке с другой идиоматикой. Если не собираешься разворачивать эту систему на целой куче машин, то это бесполезное занятие. Даже более, чем постинг на опеннете. Конфиги из етц никуда от твоего контроля не уйдут. >описывать на Nix прикладную часть, от чего я и советую отказаться А вот это как раз то, в чем guix и nix хороши - в управлении окружениями и их изоляцией. На мой взгляд, тут они вобрали лучшее от виртуаленва (если бы он был декларативным), докера и флатпака. >Генератор покрывает только те части конфигов, на которые хватило мотивации разработчика. Очевидно, что переизобретать dsl для конфигурации для каждой утилитки и потом поддерживать это в актуальном виде -- неподъёмная задача даже для достаточно крупного сообщества, такого, как у nix. Костыли будут всегда, но с ними можно мириться, если тебе важна воспроизводимость. Но это явно не про настольную систему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #118

115. Сообщение от Аноним (59), 01-Июн-26, 21:51	+/–
> А теперь возьмите проектов хотя-бы пять, с разным набором зависимостей, и перекиньте > это на другую машину. Так мне ж не в падлу, простите мой воинствуще безграмотный французский, репозиторий завести на центральной машине. А на другой машине просто тянуть из него обычным пакетником. Подписывать пакеты меня тоже не обременяет. Концепция репозиториев совсем не понятна никсоводам? Но у вас же, вроде, есть каналы (channel)? Или что? В худшем случае, если упарываться по-Nёxовски, можно утянуть весь кэш пакетов репозитория rsync-ом, но установить только избранные. Обычно он мал (пакеты сжаты), но если нужно можно ещё сильнее уменьшить - сделав несколько репозиториев (это просто директория) и подключая на клиенте только нужные. > как вы сделаете при этом прозрачную статическую линковку. Боже упаси от статической линковки!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #124

116. Сообщение от Аноним (25), 01-Июн-26, 22:18	+/–
> Shepherd намного более гибкий и удобный Возможно. Но индустриальный стандарт не он. И потому интересен только в плане хобби.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

117. Сообщение от Аноним (25), 01-Июн-26, 22:25	+/–
> Дистры - это, прежде всего, коллектив. Спасибо, не надо. Мне социальной жизни хватает IRL, а от дистрибутива мне хочется только поставить, настроить, и забыть как он называется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

118. Сообщение от Аноним (25), 01-Июн-26, 22:32	+/–
> Ты просто дублируешь /etc на инородном конфигам языке с другой идиоматикой. В линуксе /etc целиком состоит из инородных конфигов с другой идиоматикой. Нет ни стандарта на формат конфигов, ни даже каких-то традиционных соглашений на то, как опеделить формат по имени файла. Про типизацию значений я и вовсе молчу. Всё файл, а внутри файла всё строка, а все строки -- последовательности байтов, разделённые \0. По сравнению с этим, виндовый реестр -- верх инженерной мысли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #119

119. Сообщение от Аноним (103), 01-Июн-26, 23:08	+/–
>В линуксе /etc целиком состоит из инородных конфигов с другой идиоматикой. Язык конфига, скажем, nginx не является для него инородным или неидиоматичным, а nix - является. Я об этом. >Про типизацию значений я и вовсе молчу. Да, ещё одна головная боль никса, связанная с конфигами. Не всё легко типизируется. п.с. Я что-то не припомню, в никс АДТ завозили или нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #132

120. Сообщение от Аноним (120), 02-Июн-26, 00:40	+/–
Буду обновлять НиксОс до тех пор пока X11 не выпилят окончательно, в таком случае пересяду на Мини/Артикс. В худшем случае достану ISO с Windows 7
Ответить | Правка | Наверх | Cообщить модератору

121. Сообщение от Аноним (121), 02-Июн-26, 09:05	+/–
А я, грешным делом, всё думаю: а кто же это так напрограммировал, что XFCE стал жрать в 2 раза больше РАМы, кто же это напрограммировал, что системГ, призванное ускорить загрузку (параллелизм же) - привело к замедлению загрузки минимум втрое (лично на моём ПК), кто же это напрограммировал, что при обновлении (замечено на void linux) не стартует виртуалка с базовой системой (без ничего) с 512 Мб РАМы, - а не стартует по причине увеличение initramfs со 134 Мб до 203 Мб и выделенной РАМы тупо не хватает (увеличил до 1024 и пошло-поехало)... Но теперь, благодаря Вам я понял - это погроммисты, которые выучили за день и сделали полезное. Прогресс, однако.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #133

122. Сообщение от Аноним (13), 02-Июн-26, 10:31	+/–
И в чём тогда заключается его гибкость, если чего не коснись - это не его задача?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

123. Сообщение от Аноним (13), 02-Июн-26, 10:32	+/–
Сейчас конечно nix с крестами сравнивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

124. Сообщение от Аноним (13), 02-Июн-26, 10:37	+/–
>Концепция репозиториев совсем не понятна никсоводам? При чём здесь репозитории? Вы выучили одно единственное слово, и теперь размахиваете им как флагом? Вам даже в голову не приходит, что если два программиста общаются, то они обмениваться будут исходниками, а не двоичными файлами. >Боже упаси от статической линковки! Вот это - как раз хорошо показывает ваш уровень. Как только задача чуть-чуть выходит за рамки привычного, вы приходите в ужас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

125. Сообщение от Аноним (13), 02-Июн-26, 10:39	+/–
>Нет. У нас такого не случается. Нужно самому, явно обновить libfoo вместе с другими пакетами. Наверное, это потому что мы используем разные команды для разных действий. Одного nix-rebuild для всего не хватает, к сожалению. Надо нажимать сразу на больное, когда разным проектам требуются разные версии одной и той же библиотеки, и как арчеводы будут играться с докерами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #128

126. Сообщение от Аноним (13), 02-Июн-26, 15:54	+/–
Конечно существует. Начиная от (n)vim, продолжая всякими самописными редакторами типа helix, куче ide на java, вроде eclipse, netbeans, jetbrains, а так же vs code. Зачем нужен редактор, написанный на динамически типизированной лапше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

127. Сообщение от chemistmail (ok), 02-Июн-26, 16:46	+/–
Ты не прав. У меня один и тот же конфиг стоит на mac, лабе в датацентре, домашнем медиасервере, компе сына, ноутбуке жены. Окружение для моей комфортной работы. На ноутбуке жены была сконфигурированна полностью операционка с десктом менеджером и играми, потом этот конфиг по ssh был перекинут на комп который был загружен с liveusb и через 15 минут на компе была полная копия окружения с ноутбука. Ноут dell с ips матрицей и интеловской встройкой, комп самосбор с nvidia на этих машинах нет вообще никаких конфигураций кроме того что лежит в /etc/nixos (на маке другой путь, но не суть) В моем окружении у меня стоит 5 версий kubectl (есть кубы разных версий) и в зависимости от того какой контекст у меня выставлен для куба работает kubectl именно той версии как и на версия апи на сервере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

128. Сообщение от chemistmail (ok), 02-Июн-26, 17:12	+/–
Ну что уж сразу с козырей то )) Я бы просто попросил побырому настроить десктоп с каким нибудь hyperland с wayland + законфигурять там noctalia-shell со своими комбинациями клавиш ну там раскладку на капслок, добавить туда какой нить терминал типа kitty и сразу сконфигурять его под теже клавиатурные комбинации + шрифты определенные влить, добавить стим, neovim (сразу с кофигом), тудаже zsh с oh-my-zsh так же с плагинами и настроенный, какой нить xray, ну и всякого софта до кучи. Еще хочу 5 версий условного kubectl (потому что надо) и механизм чтоб было удобно между ними переключаться. Еще k3s локально развернуть, ну там для тестов локально хотябы. А потом повторить это на другой железке которая отличается от первой. )) И еще раз повторить. Железка опять же другая. )) И вот сколько времени человек будет первый комп делать ну не суть, там пока шрифты выберет пока то да се, а вот сколько времени у него займет повторить все это на другой железке это уже любопытно. Ну еще обновить это все, ну там вон 26.05 вышла, можно обновиться в принципе.....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

129. Сообщение от chemistmail (ok), 02-Июн-26, 17:15	+/–
Ну спорно, я помимо базы предпочитаю окружение тоже конфигурять.... мне как то проще так. Условно на новую машину кинул конфиг, получил привычные zsh, альясы, nvim сразу с нужными плагинами, mc с подсветкой как нравится и тд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

130. Сообщение от chemistmail (ok), 02-Июн-26, 17:25	+/–
Что такое nix и что он может: Ниже переключаю альясом k8s контекст, следом за контекстом меняется версия kubectl на модуль который ставит все это и реализует переключение потратил 10 минут, попросил deepseek написать )) мне лень. k8s:(haskell)  😀  ~/work/haskell ➜ kubectl version Client Version: v1.34.8 Kustomize Version: v5.7.1 Server Version: v1.34.5+k3s1 k8s:(haskell)  😀  ~/work/haskell ➜ astra Switched to context "astra". k8s:(astra) git:(main) ✗  😀  ~/work/astra/adm ➜ kubectl version WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.16", GitCommit:"c5f43560a4f98f2af3743a59299fb79f07924373", GitTreeState:"clean", BuildDate:"2023-11-15T22:39:12Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"darwin/arm64"} Kustomize Version: v4.5.7 Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4+k3s1", GitCommit:"0dc63334c0db3e7b99244427615e091909fc486e", GitTreeState:"clean", BuildDate:"2022-11-18T18:17:40Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"} k8s:(astra) git:(main) ✗  😀  ~/work/astra/adm ➜ astra-new Switched to context "astra-new". k8s:(astra-new) git:(main) ✗  😀  ~/work/astra/adm ➜ kubectl version Client Version: v1.30.14 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.30.0
Ответить | Правка | Наверх | Cообщить модератору

132. Сообщение от Аноним (25), 02-Июн-26, 21:33	+/–
> Язык конфига, скажем, nginx не является для него инородным или неидиоматичным, а nix - является. Я об этом. Ну значит и проблемы нет положить конфиг в файлике, и скопировать его никсом куда надо, раз ты такой эстет. > Да, ещё одна головная боль никса, связанная с конфигами. Не всё легко типизируется. Это головная боль линукса. Никс тут вообще не при делах, когда он пришёл тут уже был бардак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

133. Сообщение от Аноним (25), 02-Июн-26, 23:56	+/–
Да, это именно из-за них и тех, кто их PRы смержил. По секрету скажу, что целью той работы было нагадить тебе персонально, и как я могу видеть цели были достигнуты. Весь мир вращается вокруг тебя, твоего личного ПК и void linux, зайчик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема