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

"Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
Сообщение от opennews (ok), 25-Июн-25, 14:03
В пакетных менеджерах  GNU Guix, Nix и Lix выявлены уязвимиости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63464
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+4 +/–
Сообщение от IMBird (ok), 25-Июн-25, 14:03
Эти уязвимости кого надо уязвимости. Нужно больше дистрибутивов и больше систем, чтобы никто адекватный об аудите даже не задумывался. Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от bOOster (ok), 25-Июн-25, 14:21
	И в целом там и о расте адекватно задумываются - как о возможности, а не панацее..
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–3 +/–
	Сообщение от Аноним (-), 25-Июн-25, 14:50
	Исходный код раст открыт? Как он с GNU уживётся? Если проприетарный раст будет использоваться, то GNU уже будет не торт. Весь смысл потеряется. Люди тогда прежде чем покупать устройство под PureOS, могут и задуматься - а зачем? Устройства Librem не такие уж и дешевые как кажутся: https://puri.sm/products/
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (12), 25-Июн-25, 14:28
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. И самые неуловимые, как Джо.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	35. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (35), 25-Июн-25, 15:45
	Это раньше было что Джо неуловимый потому что никому не нужен. По текущим нормам корпорации за информацию сколько любой самый ненужный Джо с дивана вставал уже давятся.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (-), 25-Июн-25, 14:44
	Больше пакетных менеджеров и пакетов, пакетов, пакетов!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	19. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (19), 25-Июн-25, 14:50
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	43. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (43), 25-Июн-25, 16:44
	> В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе. Главное, не забывать повторять услышанное в перепеве Рабиновича (кстати, "сборка" чего? pkg ничего не собирает) commit c239d131dc920d6f3dead18a8e9a772372fe9578 Author: Bryan Drewery <bryan@shatow.net> Date:   Wed Jan 31 15:53:19 2018 -0800     audit: Drop privileges after opening the files/database but before parsing. commit f3b0469eb8669967d76d18fb56222853ca30871d Author: Baptiste Daroussin <bapt@FreeBSD.org> Date:   Fri Nov 11 22:18:25 2016 +0100     Stop dropping privileges when fetching as it causes more issues than it     solved commit fcceab3f1e0ae780e8a91918488aab3ba5f5ea1c Author: Baptiste Daroussin <bapt@FreeBSD.org> Date:   Sat Aug 20 01:17:34 2016 +0200     drop privileges when using libfetch Вот еще немного "на закуску" pkg_repo.c    /*    * We need to load this pubkey from meta    */                                   if (pkg_emit_sandbox_get_string(pkg_repo_meta_extract_pubkey, &cbdata pkg_sandbox.c int pkg_handle_sandboxed_get_string(pkg_sandbox_cb func, char **result, int64_t *len,                 void *ud) ... /* Here comes child process */         close(pair[1]);         pkg_drop_privileges();         rl_zero.rlim_cur = rl_zero.rlim_max = 0;         if (setrlimit(RLIMIT_NPROC, &rl_zero) == -1)                 err(EXIT_FAILURE, "Unable to setrlimit(RLIMIT_NPROC)"); #ifdef HAVE_CAPSICUM #ifndef PKG_COVERAGE         if (cap_enter() < 0 && errno != ENOSYS) { void pkg_drop_privileges(void) {         struct passwd *nobody;         if (geteuid() == 0) {                 nobody = getpwnam("nobody");                 if (nobody == NULL)                         errx(EXIT_FAILURE, "Unable to drop privileges: no 'nobody' user");                 setgroups(1, &nobody->pw_gid);
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (61), 26-Июн-25, 00:36
	>Главное, не забывать повторять услышанное в перепеве Рабиновича Вам же хорошо сказано >до недавнего времени Посмотрите на дату коммита >2018, 2016 Когда там bsd появилась, в каком году? Солько лет так жили - 10, 20, а то может и все 40?
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+2 +/–
	Сообщение от Аноним (55), 25-Июн-25, 22:36
	Всю жизнь рут требовался только для make install.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	122. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (122), 27-Июн-25, 18:15
	Ну а pkgsrc в NetBSD с самого своего рождения в 1997 умеет работать без рута со сборкой и установкой пакетов в $HOME/pkg.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	32. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–7 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:38
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. Топорные топоры из каменного века, не способные почти ни на что?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	36. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+3 +/–
	Сообщение от Аноним (35), 25-Июн-25, 15:48
	Иногда топоры покрайней мере надёжные, а все новомодные пукалки не вызывают доверия.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–3 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:56
	Я надеюсь, что еду себе вы готовите на костре, дрова для которого, срублены каменным топором. Мангал, печь и другихе хипсторские смузитехнологии не используете.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (74), 26-Июн-25, 10:40
	Аналогии не работают.
	Ответить | Правка | Наверх | Cообщить модератору

	75. Скрыто модератором	+/–
	Сообщение от Аноним (75), 26-Июн-25, 10:55
	> Аналогии не работают. В принципе очень как работают, просто у оратора выше они очень неудачные и откровенно всратые.
	Ответить | Правка | Наверх | Cообщить модератору

	80. Скрыто модератором	+/–
	Сообщение от Аноним (80), 26-Июн-25, 12:06
	>> Аналогии не работают. > В принципе очень как работают, просто у оратора выше они очень неудачные > и откровенно всратые. Так, наверно, автор комментария и имел ввиду, что именно эти аналогии и не работают.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 11:07
	Давайте без аналогий. В остальных пакетных менеджерах нет и не то что половины, но и пожалуй и одной десятой возможности nix. И то, что в nix делается элементарно, вы, скорее всего сделать просто не сможите, но вам будет стыдно в этом признаться, по этому вы скажете, что это не нужно.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	86. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (-), 26-Июн-25, 13:18
	Да уж, сделать пакетник аж демоном? И накосячить с гонками, давая возможность Васянам выполнить что попало с привилегиями? Вот это я понимаю - возможности ... апгрейда привилегий и поимения систем. Правда объект поимения попробуй еще найди в диком виде.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (61), 26-Июн-25, 13:39
	>Да уж, сделать пакетник аж демоном? Ниже ваш коллега уже сколько сообщений настрочил, и с каждым его сообщение конкретики всё меньше, а общих фраз всё больше. Скоро вообще кроме воды и "я так чувствую" ничего больше не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Голум (?), 25-Июн-25, 17:07
	Они у вас лишь иногда надёжные? А всё остальное время тоже не вызывают доверия?
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	85. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–2 +/–
	Сообщение от Аноним (-), 26-Июн-25, 13:14
	> Топорные топоры из каменного века, не способные почти ни на что? У них и репы под стать. LTS нету, содержат все это абы как, по остаточному принципу. За что и повылетели отовсюду. Кому гемор надо? И типа-серверная ос без LTS и нормальных бинарных реп с адекватными полисями? Да вы шутите, кому такое нахрен надо в 2025 кроме горстки самых отбитых фанатов?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

2. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+12 +/–
Сообщение от Анонимище (?), 25-Июн-25, 14:04
Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят
Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Кошкажена (?), 25-Июн-25, 15:38
	> Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят Я злой и страшный серый волк, я в поросятах^Wпакетных менеджерах знаю толк!
	Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+4 +/–
Сообщение от Fracta1L (ok), 25-Июн-25, 14:08
Фоновые процессы для установки программ, вот это клиника
Ответить | Правка | Наверх | Cообщить модератору

	8. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (-), 25-Июн-25, 14:14
	Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (17), 25-Июн-25, 14:49
	Фоновые процессы для монтирования/размонтирования, для вывода звука, для вывода окошек, для показа диалога "Открыть файл", для отправки сообщения в третий процесс через шину, для всего подряд. А ты тут про какую-то установку программ.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	26. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Fracta1L (ok), 25-Июн-25, 15:17
	Это всё можно понять, потому что для нормальной комфортной работы этих подсистем нужно ловить события. А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона?
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от 12yoexpert (ok), 25-Июн-25, 15:24
	в унбунте до сих пор нельзя выключить попапы обновлений без rm -rf что-то-там?
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (17), 25-Июн-25, 15:25
	Событие "собери/скачай такой-то дериватив". Это позволяет обычным пользователям пользоваться услугами сборщика. Почему так сделано? Ответ в твоем комменте: "для нормальной комфортной работы".
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	34. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+2 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:44
	>А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона? Сразу видно ыксперда. Событие - пользователь инициировал сборку чего-то там. Далее, от непривилегированного пользователя запускается скачиваение и сборка всего этого дела в чистом окружении. Добавим сюда тот факт, что это системный пакетный менеджер, который кеширует результаты сборок, делая их разделяемыми для всей системы целиком, а не только для текущего проекта, удаляет ставшие ненужными пакеты, занимается перезапуском различных служб и так далее.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	48. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 25-Июн-25, 19:22
	> и так далее и для этого всего нужен демон? это же обычный сценарий, который можно и по крону запустить, демон зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 25-Июн-25, 21:11
	>это же обычный сценарий, который можно и по крону запустить А крон давно демоном быть перестал? >который можно и по крону запустить Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день. Минимальное разрешение крона - минута. Далее, у вас будет задача вернуть результат из крона именно той программе, которая его вызвала, поскольку в NixOS nix может вызываться достаточно часто. >демон зачем? Для обработки запросов пользователя. Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ. Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются. Это уже тянет как минимум на условный подман. В условном дебине или арче исходник может во-первых выкачать бекдор прямо в момент сборки, во-вторых, там нет никакой проверки описания пакета, например, можно забыть, что пакету нужен gcc, и если gcc уже стоит в системе, то пакет молча соберётся, но его спецификация будет неверной. это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение. Далее, добавим тот факт, что это системный пакетный менеджер. У условного подмана практически нет кеширования образов. Незначительные изменения докерфайла, и всё будет перекачиваться/пересобираться повторно. Условные bash будет в каждом образе качаться независимо друг от друга. Далее, возьмём удаление пакетов: привычного apt remove в nix нет, поскольку пакеты не ставятся глобально. Вместо этого применяется стратегия со сборкой мусора - есть несколько корней, которые рекурсивно удерживают пакеты от удаления. Как следствие, во время сборки мусора нужно точно знать, какие пакеты используются прямо сейчас, а какие - нет. Есть текущая сборка, есть предыдущие, на которые пользователь может откатится простой перезагрузкой, есть systemd контейнеры, есть анонимные окружения, запущенные через nix-shell -p, есть окружения запущенные через nix файлы. Всё это дело и удерживает пакеты в системе. Условный apt в убунте намертво блокируется, если фоном выполняется какая-то операция, например проверяется наличие обновлений, так как может выполняться только один экземпляр apt, в противном случае один apt поставит пакет с зависимостью о libfoo, а второй эту зависимость снесёт как ставшую ненужной. Подману абсолютно всё равно, сколько libfoo у вас есть, для исправления этого даже специальные файловые системы изобретают.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 25-Июн-25, 23:06
	> А крон давно демоном быть перестал? так для него это необходимость, один демон, исполняющий периодически необходимые сценарии, а не на каждый чих свой демон. > Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день. ну а демон зачем вам, если вы просто запускаете сценарий? Крон это пример где демон - необходимость, когда необходимо периодически запускать сценарии. > Для обработки запросов пользователя. понятие "интерактивная программа" незнакома? > Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ. любая вызванная команда выполняется прямо сейчас и выдает ответ. Nginx - служба по определению, так как работает 24 на 7. В установке (сборке) софта нет необходимости службы 24 на 7. Почему у вас калькулятор еще не служба или там текстовый редактор? > Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются. неважно как там все это происходит, тут главное что это происходит по действию пользователя при необходимости, и необходимости в 24 на 7 нет. > это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение вы лучше про причину необходимости демона напишите
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 00:27
	>а не на каждый чих свой демон. Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например. >ну а демон зачем вам, если вы просто запускаете сценарий? Затем, что кто-то должен слушать /nix/var/nix/daemon-socket/socket. >понятие "интерактивная программа" незнакома? Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше. >любая вызванная команда выполняется прямо сейчас и выдает ответ. Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве. Существуют исключения, игрушечные СУБД типа sqlite, но именно исключения. >В установке (сборке) софта нет необходимости службы 24 на 7. Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы. Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server. Это в дебиане/арче софт ставится разово, или не ставится вообще, так как поставить две версии libfoo без танца с бубнами нельзя, и на этом история заканчивается. Как там было в комиксе xkcd, про ноутбук зону отчуждения, на котором куча установок python. В NixOS даже для установленного софта нужен nix, например для компиляции. И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение. Ибо одному проекту нужна libfoo 0.5 версии, а второму - 2. Более того, в некоторых случаях nix может идти в самом начале shebang-а - у вас каждый запуск софта будет запускаться nix. >неважно как там все это происходит Как раз таки важно. Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно. >и необходимости в 24 на 7 нет. Вы вначале придумали аргумент 24/7, и теперь его повторяете. >вы лучше про причину необходимости демона напишите Вам уже написали кучу причин, но вы притворяетесь что их нет.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 01:01
	> Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например. Дайте определение понятия демон (служба), я думаю вы не понимаете значение этого термина. > Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше. Я не вижу в этом списке ни калькулятора, не текстового редактора, ни сапера (игра), но вероятно в этом списке явно должен быть виджет погоды или температуры процессора. Так в чем дело? > Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве. Ну существует, и что мы не запускаем клиент? Мы не получаем интерактивного приглашение? В чем дело? А сервер СУБД - служба, и служит она не только мне по определению службы. А клиент - это интерактивная программа запускаемая при необходимости, почему у вас клиент не служба? > Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы. У вас шо там другого способа меж-процессного взаимодействия не нашлось? Правильно говорит  Fracta1L - это клиника. > Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server. Почему в этом списке нет калькулятора? > Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Когда поймете для чего необходимы демоны, тогда поймете как достичь. > Уже этих свойств более чем достаточно. Ей ГНУ-шники, почему ваш gcc до сих пор не демон? Вы можете не отвечать, вопрос не вам. > Вы вначале придумали аргумент 24/7, и теперь его повторяете. Потому-что до вас элементарно не доходит значение слова демон (служба) > Вам уже написали кучу причин, но вы притворяетесь что их нет. Отправьте эти причины ГНУ-шникам, чтобы в следующей версии gcc был демоном.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (17), 26-Июн-25, 03:23
	> другого способа меж-процессного взаимодействия не нашлось? Если есть меж-процессное взаимодействие, значит процессов как минимум два. На этом коммент можно завершать, так как ты уже сам постулируешь необходимость демона (второй процесс из двух). Но продолжим: "Другой способ меж-процессного взаимодействия" -- это активация по требованию. И он требует демон, который будет активировать другого демона: 1. Прога А обращается к шине (демону d-bus) с просьбой активировать прогу Б. 2. Демон активирует (запускает) прогу Б. 3. Прога Б регистрируется в шине d-bus в качестве демона, отвечающего на запросы. 4. Прога А и прога Б (два процесса) общаются меж собой через шину (через демон d-bus, третий процесс). Как видишь, альтернатива двум процессам -- это три процесса. Рассмотрим другой случай: прога А запускает напрямую прогу Б без всяких демонов. В этом случае прога Б будет иметь те же права, что и прога А, а значит уже не сможет запускать билдеров, напрямую записывать в /nix/store результаты и выполнять прочие вещи, необходимые с точки зрения nix. Поэтому прогу А придется запускать из-под рута. Это неудобный вариант. При желании, можно отказаться от демона nix, там это именуется "single-user mode" https://nix.dev/manual/nix/2.24/installation/nix-security -- со всеми вытекающими ограничениями. В NixOS правда никто так не делает: иметь демона тупо удобно, а без демона тупо неудобно. Когда я запускаю VSCode, и в нем поднимается окружение из flake.nix + direnv, я не хочу вводить рутовый пароль, чтоб скачать/собрать зависимости моего проекта. Спасибо демону, который слушает мои просьбы собрать/скачать зависимости и делает все необходимое с рутовыми правами, которые у него есть (а у меня нет на момент запуска VSCode).
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 11:46
	> На этом коммент можно завершать, так как ты уже сам постулируешь необходимость демона (второй процесс из двух). Демон это не понятие взаимодействия, для взаимодействия двух процессов мне нет необходимости делать один из них демоном. Демон это СЛУЖБА, процесс который работает 24 на 7 и на то должна быть обоснованная необходимость. Служба может играть роль автономную и посредническую. Например служба сетевого времени, она автономна, а вот служба буфера обмена - это как раз служба выполняющая посредническую роль, но это не является механизмом меж-процессного взаимодействия. Мы можем сказать, что служба буфера обмена является посредником между калькулятором и текстовым редактором, но в тоже время службу буфера обмена можно спокойно заменить на любую другую службу хранения информации к примеру СУБД, от этой замены взаимодействие между калькулятором и текстовым редактором не изменилось. Калькулятор может сохранять результат в файл, а текстовый редактор открывать его при необходимости, или передача по сокету и т.д. и для всего этого нет необходимости в понятии службы. В контексте nix, для банальной сборки и установки софта в демонах нет необходимости, это тупо сценарий. А чему удивляться то, когда у вас гугл_хром_апдейтер это служба :) Давайте объясните мне необходимость в этой блоатвари. Короче, мне то ясна цель всех этих блоатварщиков, отсюда и диагноз клинический. > я не хочу вводить рутовый пароль, чтоб скачать/собрать зависимости моего проекта Рожденный ползать - летать не может! > Спасибо демону, А че не модулю ядра?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 12:53
	>Демон это СЛУЖБА, процесс который работает 24 на 7 Вы сами придумали это определение. Демон - это фоновый процесс. Формально, тот который при запуске отсоединяется от терминала. Время жизни программы не делает её демоном. Условный firefox, который имеет неделю аптайма - не демон, условный ssh, который активируется по сокету, работает пять минут и завершается после закрытия подключения - демон, хотя по вашей логике всё наоборот - firefox - демон, ssh - нет. >В контексте nix, для банальной сборки и установки софта в демонах нет необходимости, это тупо сценарий. Какой сценарий? Вы в курсе, что nix - бинарник? Вы сами признались, что nix не видели. На вас не действуют аргументы, ибо вы банально некомпетентны. Будь вы нейросетью, ваши рассуждения назвали бы галюцинацией. >А чему удивляться то, когда у вас гугл_хром_апдейтер это служба Всё правильно. >Давайте объясните мне необходимость в этой блоатвари. Отсутствие в винде пакетного менеджера, очевидно же, а так же кривые ручонки пользователей, которые боятся консоли как огня, но знающих лучше любого линуксоида, сисадмина и программиста, как должен работать софт. >Рожденный ползать - летать не может! Вы не предложили абсолютно никаких альтернативных вариантов.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 14:14
	> Время жизни программы не делает её демоном. Запущенный 24 на 7 калькулятор - не демон (служба), но любое ПО которое мы считаем демоном (службой) подразумевает работу 24 на 7. Есть у вас пример службы, для которой нет необходимости работать 24 на 7? > условный ssh, который активируется по сокету, работает пять минут и завершается после закрытия подключения - демон условный ssh кто? клиент или сервер? клиент на то и не служба, что после завершения работы нет необходимости оставлять его запущенным и он не выполняет никакой автономной работы. Слушать сокет - автономная работа, но понятие "слушать сокет" еще не делает ПО демоном (службой). Сокет это обычный механизм меж-процессного взаимодействия. Строгое определение демона (службы) - автономности (исполнение без интеракции с пользователем) и необходимость в 24 на 7. Короче, демон это та программа которой ОБОСНОВАННО НЕОБХОДИМО работать 24 на 7. Если вам есть необходимость 24 на 7 числа дробить, то ваш калькулятор должен быть спроектирован как демон (служба). Для любого клиент-серверного приложения необходим сервер демон по определению, потому-что при любом запуске клиента, сервер должен быть доступен! Эту доступность обеспечивает демон (служба). Вспомните модель inetd. Одна служба, которая при необходимости запускала другие программы :) > Какой сценарий? Вы в курсе, что nix - бинарник? Вы сами признались, что nix не видели. И видеть не хочу блоатварь, а все что вы описываете это обычный сценарий, вот и приметили "Фоновые процессы для установки программ, вот это клиника". > Всё правильно. Ясно, понятно, блоатварь, и цель ясна, передайте привет куратору. > Отсутствие в винде пакетного менеджера Правой кнопкой на значке пуск -> "Установленные приложения" - это что? > Вы не предложили абсолютно никаких альтернативных вариантов. Критик не обязан предлагать, что за чушь? Критика это обоснованное За и Против в совокупности. Как можно предлагать "ужу порхать крыльями"? Новость была про повторяемость сборок которую они завезли, так курам на смех с точки зрения ибешника.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 14:56
	>но любое ПО которое мы считаем демоном (службой) подразумевает работу 24 на 7 Кто подразумевает? Ыксперд, который сам признаётся, что ничего не знаете? >Есть у вас пример службы, для которой нет необходимости работать 24 на 7? Да любой. Та же СУБД на компьютере разработчика. Приходит человек в офис, работает 8 часов, уходит. Зачем в остальное время греть воздух? >условный ssh кто? клиент или сервер? По контексту могли бы догадаться, что речь идёт об ssh.socket, и как следствие о сервере. >и необходимость в 24 на 7. Сколько можно как попугай это повторять? Вы хотя бы один пример приведёте, где кто-то компетентный так же считает? >Для любого клиент-серверного приложения необходим сервер демон по определению Отлично, nix как и snap, как и docker, как и systemd, как и lxd, как и lxc клинет-серверный. С прозрением. >И видеть не хочу блоатварь Вы как попугай повторяете "блоатварь", "24/7", на этом ваш поток аргументов резко заканчивается. Просто признайте поражение. Вы всё равно, ничего большего, чем эникейщик до сих пор не написали. >Ясно, понятно, блоатварь Тыжпрограммист, расскажи как именно на системе без пакетного менеджера хромой должен обновляться? Или вы из тех, кто будет хостить ботнет до тех пор, пока к вам шифровальщик не придёт? >Правой кнопкой на значке пуск -> "Установленные приложения" - это что? Ну и каким образом эта штука обновляет пакеты? Если вы не заметили, то на винде почти каждая программа обновляет себя самостоятельно, либо не обновляется никогда. И установщик имеет свой собственный. И удаление программы тоже своё собственное, которое далеко не всегда сносит программу целиком. >Критик не обязан предлагать, что за чушь? А разбираться в теме критик обязана или нет? А знать вообще возможно это реализовать или нет? >Критика это обоснованное За и Против в совокупности. У вас нет ни одного обсонования, кроме "я так чувствую".
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	96. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 15:46
	> Кто подразумевает? Ыксперд, который сам признаётся, что ничего не знаете? кек, тот кто дает определение, я дал свое определение и обосновал, а вы до сих пор нет. > Приходит человек в офис, работает 8 часов, уходит. Зачем в остальное время греть воздух? ну этот же вопрос вашему nix зачем после установки софта у вас висит демон? То же тушите его? Или он после 8 часов потушится? И что СУБД от этого перестала быть демоном? У вас 8 часов бесперебойно на одном запуске работает служба, вы же не на каждый клиентский запрос запускаете службу СУБД или каждый? :) До вас все еще не доходит разница между обычной программой и демоном? > По контексту могли бы догадаться, что речь идёт об ssh.socket, и как следствие о сервере. так вы не видите разницы между обычной программой и службой. Сервер - по определению служба. > Сколько можно как попугай это повторять? Вы хотя бы один пример приведёте, где кто-то компетентный так же считает? потому-что до вас до сих пор это не доходит. > Отлично, nix как и snap, как и docker, как и systemd, как и lxd, как и lxc клинет-серверный. С прозрением. Я критикую необходимость установщика пакетов быть демоном (службой)! И считаю это клиникой, точка! Есть вопросы? Обоснование в комментах выше. > Вы как попугай повторяете "блоатварь" Ну замените на благо :) тут надо оставить поговорку про "Божью росу". > Вы всё равно, ничего большего, чем эникейщик до сих пор не написали. Каким боком? Код вам не показал? :)))) "а вам все покажи" - одни мусорские понты. > Тыжпрограммист, расскажи как именно на системе без пакетного менеджера хромой должен обновляться? Там кнопочка есть "проверить обновления" :) > Ну и каким образом эта штука обновляет пакеты? А кто определил, что эта штука должна обновлять пакеты? Может она еще и кряки должна качать? Что будет обновлять ваш пакетный менеджер если ПО не имеет больше новых версий? Ей достаточно удалять пакеты, а установка и обновление - дело самого пакета. И поэтому в винде достаточно сделать пакет.exe /install условно, можно также и /uninstall и делов то, а то тут нагородили огород из демонов :) > И удаление программы тоже своё собственное, которое далеко не всегда сносит программу целиком. Да и далеко не все программы благие :) ну вот ваше не любимые блоатвари, которые даже удалить невозможно как самсунговских андроидах. А nix это такая блоатварь, которая не даст любой другой блоатвари так просто существовать. > А разбираться в теме критик обязана или нет? А знать вообще возможно это реализовать или нет? Должен каждый теоретик быть практиком? Практика тут в контексте эмпиризма. Теория от практики не зависит, все на оборот, вы ставите эксперимент по теории. И как говорится, чем дальше эксперимент от теории тем ближе он к "премии Дарвина" (в оригинале - Нобелевской). Вот и я говорю, что надо дать "премию Дарвина" тем кто пакетный менеджер запускает как демон. > У вас нет ни одного обсонования, кроме "я так чувствую". Делаю вывод, что вы не читали комменты выше. А если прочли и сделали такой вывод, то тут ничего не поделаешь. Можно на этом закончить разговор.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	99. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 16:35
	>тот кто дает определение, я дал свое определение и обосновал Попугайство - не обоснование. >а вы до сих пор нет. Вбейте в поисковик запрос, быстренько найдёте. Даже в мануале emacs-а. >              --daemon[=name], --bg-daemon[=name] >                      Start Emacs as a daemon, enabling the Emacs server and disconnecting from the terminal.  You can then use the emacsclient (see emacsclient(1)) command to  connect  to >                      the server (with optional name). Удивительно, но тут нет никаких 24/7. Признавайте поражение. >ну этот же вопрос вашему nix зачем после установки софта у вас висит демон? Первый запуск nix-shell установит пакет. Второй запуск nix-shell проверит, что пакет установлен, и настроит переменные окружения. nix-shell запускается регулярно, хочу открыть проект - cd project/ && nix-shell. Вы хотя бы сейчас увидели, что nix-shell это регулярно запускаемая программа, как условный bash? >И что СУБД от этого перестала быть демоном? У вас 8 часов бесперебойно на одном запуске работает служба, вы же не на каждый клиентский запрос запускаете службу СУБД или каждый? Ух ты, вы почти согласились, что демоны это не только 24/7, но и 8/5. Давайте, признайтесь в своей неправоте. >У вас 8 часов бесперебойно на одном запуске работает служба, вы же не на каждый клиентский запрос запускаете службу СУБД или каждый? xterm - клиент, xorg - сервер. firefox - клиент, nginx - сервер. nix-shell - клиент, nix-daemon - сервер. Любой сервер работает долго и фоном. Любой клиент запускается руками и часто. >потому-что до вас до сих пор это не доходит. Постойте, я запутался, сервер - это 24/7 или 8/5? А если я sshd на полчаса включил, это сервер или нет? >Каким боком? Код вам не показал? Ой, оказывается ыксперды не пишут код, ибо не умеют, вот это новость. Зато осуждать тех, кто код писать умеет они любят и практикуют. >Ей достаточно удалять пакеты, а установка и обновление - дело самого пакета. Ну вот и получается, что хром ставит свою службу, для проверки обновлений. С чего начали, к тому и пришли. Не, можно ещё чтобы хром без всяких служб и интерфейс рисовал, и обновления скачивал, но это ни на что не повлияет.. >ну вот ваше не любимые блоатвари, которые даже удалить невозможно как самсунговских андроидах Какое отношение самсунг и андроид имеют к nix? Что там в винде, иконки? >Практика тут в контексте эмпиризма. Аргументы закончились, пошла философия. >Теория от практики не зависит, все на оборот, вы ставите эксперимент по теории. Практика от теории тоже зависит. Вы не будете ждать того, чтобы вас сбила машина, чтобы начать смотреть на светофор. И кучу других вещей не будете делать на авось. >Делаю вывод, что вы не читали комменты выше. Как раз таки читал. То у вас сервер 24/7, то 8/5, то полчаса. То хром не может ставить службу для проверки обновлений, то должен ставить именно хром а не винда. То в винде есть пакетный менеджер, то программы полностью предоставлены себе. То демон не нужен, то нужен кто-то, кто будет прослушивать сокет. Постоянно меняете своё мнение на противоположное. >Можно на этом закончить разговор. Нет, вы ещё не признали свою неправоту.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	101. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 17:45
	> Удивительно, но тут нет никаких 24/7. Признавайте поражение. ага у вас emacsclient будет работать 24 на 7 когда встретит unable to connect :) > Вы хотя бы сейчас увидели, что nix-shell это регулярно запускаемая программа, как условный bash? и что bash - демон? > Ух ты, вы почти согласились, что демоны это не только 24/7, но и 8/5. Давайте, признайтесь в своей неправоте. а в чем разница между 24/7 и 8/5? у вас же вовсе это не определитель демона. Повторяю вопрос - что в вашем понимании есть определитель демона, как понять программа А демон или нет? По наличию опции --daemon? Отлично, а потом прочти описание этой программы и необходимость этой опции. А если нет этой опции, а есть --foreground демон или нет? > nix-shell - клиент, nix-daemon - сервер. Любой сервер работает долго и фоном. Любой клиент запускается руками и часто. Все верно. Я же не спорю, что nix-daemon не является демоном, так в чем необходимость пакетному менеджера быть демоном? Отсюда, есть ли необходимость калькулятору быть демоном? > Постойте, я запутался, сервер - это 24/7 или 8/5? А если я sshd на полчаса включил, это сервер или нет? там буковка d на конце имени вашей программы - значит демон, забейте на все эти 24/7 и 8/5, вам так не понять. Так ясней? :) > Зато осуждать тех, кто код писать умеет они любят и практикуют. Я критикую, не осуждаю, осуждать вас будут ваши потомки, как вы щас обоснованно плюетесь в поделие ваших дедов. > Ну вот и получается, что хром ставит свою службу, для проверки обновлений. Потому-что такие же д*билы как и те кто пакетный менеджер сделал демоном. Ваш хромой еще по всем файлам в системе лазает как антивирус заботясь о вашей безопасТности. > С чего начали, к тому и пришли. Ну да критика пакетного менеджера как демона. > Какое отношение самсунг и андроид имеют к nix? Что там в винде, иконки? никакого, вы видать и русского языка не знаете, это все было сказано в контексте блоатвари. Ваш nix демон - блоатварь, подобно самсунговской в андроиде. Так ясно? > Аргументы закончились, пошла философия. Какие аргументы, 5-ый комент, а до вас не доходит в чем разница между обычной программой и программой демоном. > Практика от теории тоже зависит. Ну да, но не теория же от практики, а я что сказал? > Вы не будете ждать того, чтобы вас сбила машина, чтобы начать смотреть на светофор. И кучу других вещей не будете делать на авось Вас сначала машина сбивает, а потом появляется необходимость в светофоре, это обычно у "практиков". В теории, необходимость светофора появляется тогда когда пересекаются два пути. Там где нет пересечения путей там и не будет светофоров, а машины вас все равно будут сбивать, почему? > То у вас сервер 24/7, то 8/5, то полчаса. Сервер ведь по определению - демон, в чем проблема? А вот что есть демон вы так и не поняли. > То хром не может ставить службу для проверки обновлений, то должен ставить именно хром а не винда. Где такое утверждение? Где утверждение, что для апдейтов хрома НЕОБХОДИМО иметь службу? > То в винде есть пакетный менеджер, то программы полностью предоставлены себе. Да есть в винде пакетный менеджер, и он тоже как ни странно служба Установщик Windows Позволяет добавлять, изменять и удалять приложения, предоставленные пакетом установщика Windows (*.msi, *.msp). Если эта служба отключена, запуск любых явно зависящих от нее служб невозможен. Тип запуска: Вручную Состояние: Остановлена Вопрос - почему в ручную? почему не "24/7 или 8/5" это же ведь демон? > То демон не нужен, то нужен кто-то, кто будет прослушивать сокет. лол, что есть демон, и в чем необходимость пакетному менеджеру быть демоном? > Постоянно меняете своё мнение на противоположное. а как же попугайство? я уже не в первом коменте повторяю одно и тоже, до вас до сих пор не дошло. > Нет, вы ещё не признали свою неправоту. Неправоту в чем? Неправ в том, что пакентному менеджеру НЕОБХОДИМО быть демоном? """ rpm is a powerful Package Manager, which can be used to build, install, query, verify, update, and erase individual software packages. A Package consists of an archive of files, and package information, including name, version, and description. One of the following basic modes must be selected: Initialize Database, Rebuild Database, Build Package, Recompile Package, Build Package from Tarball, Query, Show Querytags, Install/Upgrade/Freshen, Uninstall, Verify, Signature Check, Resign, Add Signature, Set Owners/Groups, and Show Configuration. """
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	105. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 18:59
	>ага у вас emacsclient будет работать 24 на 7 когда встретит unable to connect :) Формально всё же emacs, хотя в tmux-е или его аналоге может и emacsclient. Вот, пример того, как из коробки запустить emacs как демона https://nixos.wiki/wiki/Emacs#Enabling_the_Emacs_daemon >и что bash - демон? Вы утверждали, что установка пакета делается однажды, я говорю, что запуск окружения делается часто. Уже забыли? >а в чем разница между 24/7 и 8/5? Похоже, вы начали о чём-то догадываться. >Повторяю вопрос - что в вашем понимании есть определитель демона, как понять программа А демон или нет? Читайте описание данного ключа. Там нет ничего про 24/7, но есть про отсоедниение от терминала. >А если нет этой опции, а есть --foreground демон или нет? Формально, нужно отсоединение от терминала, но практически, всегда можно засунуть такую программу в systemd unit. >так в чем необходимость пакетному менеджера быть демоном? Вы до сих пор не написали, кто и как будет выполнять  роль nix-daemon. Вы даже не ознакомились с тем, какой именно у него функционал. >там буковка d на конце имени вашей программы - значит демон, забейте на все эти 24/7 и 8/5, вам так не понять. Так ясней? :) Нет. Где буква d в конце у emacs? У nginx? Формальный признак ровно один - работа в фоне, никаких других признаков нет. >Я критикую, не осуждаю, осуждать вас будут ваши потомки, как вы щас обоснованно плюетесь в поделие ваших дедов. От плохих поделий дедов нужно избавляться, хорошие - оставлять, что непонятного. >Ваш хромой еще по всем файлам в системе лазает как антивирус заботясь о вашей безопасТности. У меня стоит firefox, так что хромой не мой. Кроме того, у меня многопользовательская система, и хромой туда принципиально не доберётся. И да, вы знаете что бывает с теми, кто ставит винду и хромого. >Ну да критика пакетного менеджера как демона. Вы так и не ответили, как хромой должен себя обновлять. Или вы хотите сидеть на насквозь дырявом xp, под который даже вирусы уже не каждый собрать сможет, зато те кто могут, пробивают с первой попытки? >Ваш nix демон - блоатварь, подобно самсунговской в андроиде. Вы называете "блоатварю" всё то, что вам не понимаете. Не надо так. >Сервер ведь по определению - демон, в чем проблема? Сервер не обязан быть демоном, если он не уйдёт в фон. Можно открыть сокет, и так и оставаться на переднем плане. Сервер - тот кто имеет клиентов, но не обязательно в фоне, демон - это тот кто в фоне, но не обязательно имеет клиентов. Если условный rm /tmp/cache запускается в фоне, то это уже демон, хотя клиентов у него не будет по определению. >Где утверждение, что для апдейтов хрома НЕОБХОДИМО иметь службу? Предложите вариант без службы, давайте. Ыксперды не умеют писать код. >Да есть в винде пакетный менеджер, и он тоже как ни странно служба Значит виндовый пакетный менеджер, который не может почти ничего, вас не смущает, а nix, который может кучу всего - смущает? >Вопрос - почему в ручную? почему не "24/7 или 8/5" это же ведь демон? А что ей делать? Может она проверяет наличие установленных пакетов? Отслеживает используемые пакеты? Инициализирует окружения? >Тип запуска: Вручную >Состояние: Остановлена $ systemctl status nix-daemon.service ○ nix-daemon.service - Nix Daemon      Loaded: loaded (/etc/systemd/system/nix-daemon.service; linked; preset: ignored)     Drop-In: /nix/store/some-hash-system-units/nix-daemon.service.d              └─overrides.conf      Active: inactive (dead) TriggeredBy: ● nix-daemon.socket        Docs: man:nix-daemon              https://nixos.org/manual Ой. Удивительно то как, оказывается всё точно так же, как и в видне, пакетный менеджер активруется по сокету вручную. Признавайте поражение. >лол, что есть демон, и в чем необходимость пакетному менеджеру быть демоном? Почему пакетный менеджер винды, с ваших же слов, служба? Признавайте поражение. >а как же попугайство? Как попугайство отменяет повторение одного и того же? Вы по циклично повторяете несколько противоположных точек зрения. Повторение одих и тех же мыслей называется непротиворечивостью или согласованностью, такого я про вас не писал. >я уже не в первом коменте повторяю одно и тоже Вы в каждом сообщении неправы. Вы неправы, когда осуждаете nix, за то, что он имеет nix-daemon, приводите в пример винду, в которой пакетный менеджер тоже демон. То утверждаете про 24/7, то 8/5, но ни разу про работу в фоновом режиме. И так далее. Да даже в том, что это вы придумали про то, что nix работает непрерывно 24/7, бросились за это обвинять, а на проверку оказалось, что это не так. >Неправ в том, что пакентному менеджеру НЕОБХОДИМО быть демоном? И в этом тоже. >rpm is a powerful Package Manager Во-первых, сам по себе rpm напрмяую мало кто использует, нужен как минимум dnf. Во-вторых, dnf практически ничего не может. Вы не напишите аналог для dnf просто так. >Что всего? Вот вам такой вариант: запуск xterm 320(сейчас в репозиториях 397) от 2016-05-19, который находился в ветке 15.09-beta в nixos 25.05, при том, что между ними 19 релизов. При этом, xterm работает в wayland. >nix-shell -p xterm -I nixpkgs="https://github.com/NixOS/nixpkgs/archive/$(echo 5d540387713f2d29dac423f5faadafd5aea2ff09).tar.gz" --run xterm После этого смело принимайтесь за статическую линковку, автоматическое наложение патчей и так далее.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	110. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 20:17
	> Нет. Где буква d в конце у emacs? У nginx? Формальный признак ровно один - работа в фоне, никаких других признаков нет. Потому-что ГНУ Нот Юникс :))))))))) > Формально, нужно отсоединение от терминала, но практически, всегда можно засунуть такую программу в systemd unit. Ну так нужно или не нужно? Демон но не в бекграунде :)))) > От плохих поделий дедов нужно избавляться, хорошие - оставлять, что непонятного. Ну раз деды не делали из пакетного менеджера демонов это о чем говорит? В любом случае выкинуть и сделать по своему? > Вы так и не ответили, как хромой должен себя обновлять. chrome://settings/help "проверка наличия обновлений ... Обновление Chrome (50%)" Почти готово! Чтобы завершить обновление, перезапустите Chrome. Версия: 137.0.7151.120 (Официальная сборка) (64 бит) Мне нужна блоатварная служба? > Вы называете "блоатварю" всё то, что вам не понимаете. Не надо так. вы же мне не объяснили необходимость пакетному менеджеру быть демоном. > Сервер не обязан быть демоном, если он не уйдёт в фон. А ну да у нас же есть дыркер :) If you add a custom CMD in the Dockerfile, be sure to include -g daemon off; in the CMD in order for nginx to stay in the foreground, so that Docker can track the process properly (otherwise your container will stop immediately after starting)! > Если условный rm /tmp/cache запускается в фоне, то это уже демон, хотя клиентов у него не будет по определению. Ага калькулятор в фоне, и что он там делает? правильно блоатварит (жрет ресурсы), а не вычисляет. > Предложите вариант без службы, давайте. Ыксперды не умеют писать код. # blablabla install new_version_google_chrome_pkg Remove old version?: [Y] :) > Значит виндовый пакетный менеджер, который не может почти ничего, вас не смущает, а nix, который может кучу всего - смущает? Я же критикую по сабжу nix, а не виндовый, в теме про виндовый буду его критиковать. > А что ей делать? Может она проверяет наличие установленных пакетов? Отслеживает используемые пакеты? Инициализирует окружения? А как она список выводит и регистрирует в системе установленное ПО? Там еще неизвестно сколько скрытого функционала и какой экспериенс она собирает. > TriggeredBy: ● nix-daemon.socket Не напоминает inetd от которого все плевались еще во времена дедов? > Ой. Удивительно то как, оказывается всё точно так же, как и в видне, пакетный менеджер активруется по сокету вручную. Признавайте поражение. так он у вас в итоге оказался не до демоном по определению :) > Почему пакетный менеджер винды, с ваших же слов, служба? Признавайте поражение. Какое поражение если ни nix-овый, ни виндовый пакетный менеджер не выдерживает критики в необходимости быть демоном, это клиника. > Как попугайство отменяет повторение одного и того же? Вы по циклично повторяете несколько противоположных точек зрения. Я не вижу никаких противоречий в определении демона, которое дал я. А повторяю, потомучто до вас до сих пор это не доходит. > Вы неправы, когда осуждаете nix, за то, что он имеет nix-daemon, приводите в пример винду, в которой пакетный менеджер тоже демон Потому-что сразу видно откуда ноги растут, вам про системд другие пусть расскажут. > То утверждаете про 24/7, то 8/5, но ни разу про работу в фоновом режиме. Ага еще про букву d на конце имени файла :) > Да даже в том, что это вы придумали про то, что nix работает непрерывно 24/7 Если он столько не способен работать, а точнее в этом нет никакой необходимости, тогда в чем необходимость его как демона? :)))))))))))) > бросились за это обвинять, а на проверку оказалось, что это не так. То есть вы щас хотите сказать, что nix-daemon это совсем не демон? :))) Все, устал ржать. >> Неправ в том, что пакентному менеджеру НЕОБХОДИМО быть демоном? > И в этом тоже. Только обоснования этой необходимости я так и не услышал! > Во-первых, сам по себе rpm напрмяую мало кто использует, нужен как минимум dnf. А до появления dnf чем пользовались? Лично я ./configure, make, make install (на крайняк) Что не так? > Вы не напишите аналог для dnf просто так. А мне он не нужен. # cd /usr/ports/port_name # make config # make # make install # make clean > После этого смело принимайтесь за статическую линковку, автоматическое наложение патчей и так далее. писал как-то про секту любителей менять иконку у корзины, кажись вы из этих :)
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	114. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 27-Июн-25, 09:21
	>Ну так нужно или не нужно? Есть возможность, сделать это сторонними инструментами. >Ну раз деды не делали из пакетного менеджера демонов это о чем говорит? В первую очередь, это говорит о дедах, а не о пакетном менеджере. Поскольку эти же деды подарили замечательный си с кучей ub, и кучей вещей типа strcpy, которые просто непригодны для любой серьёзной задачи. >chrome://settings/help Вы по прежнему не ответили на вопрос. Прогрессбар может что угодно рисовать. >А ну да у нас же есть дыркер :) Клиент докера может демонизировать запущенную в нём программу, что непонятного? >Мне нужна блоатварная служба? Для обновления софта, установленного глобально - да. Ваши варианты в студию, хотя я давно не имел дела с виной, вряд ли смогу полноценно оценить. >вы же мне не объяснили необходимость пакетному менеджеру быть демоном. Прочитайте предыдущие сообщения. Я не собираюсь вам повторять. >То есть вы щас хотите сказать, что nix-daemon это совсем не демон? :))) Все, устал ржать. Вы сами придумываете критерии, сами удивляетесь, что софт ему не соответствует. >А до появления dnf чем пользовались? Лично я ./configure, make, make install (на крайняк) Что не так? Такие вещи вам должно быть стыдно писать. У вас мало того, что софт при установке может снести систему, так и зависимости не отслеживаются, и удаление пакета не даёт никаких гарантий удаления. Про возможность использования разных версий и прочее лучше вообще не вспоминать.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	117. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 27-Июн-25, 13:14
	> Есть возможность, сделать это сторонними инструментами. От добавления & при вызове того же калькулятора и перевода его в фоновый режим, не делает калькулятор программой демоном, так как это приложение по определению интерактивное и взаимодействует напрямую с пользователем, отсюда в фоновом режиме оно будет тупо простаивать (не ожидать взаимодействия, хочу отметить) и занимать ресурсы системы, при этом не делая ничего "полезного", что равносильно блоатвари! > В первую очередь, это говорит о дедах, а не о пакетном менеджере. Деды плевались в свое время на такое поделие как inetd, а молодежь даже глазом не моргнуло, когда системГ это заново переизобрела, потому-что молодежь глупа по большей части и хавает что дадут. Отмечу, что не молодой вовсе человек придумал системГ. > Поскольку эти же деды подарили замечательный си с кучей ub, и кучей вещей типа strcpy, которые просто непригодны для любой серьёзной задачи. Эти же деды подарили вам и кучу других ЯП одинаково непригодных? Куча УБ к чему приводит ? к проблемам безопасносТности? Так у вас как аппаратная (архитектура ЦПУ) так и программная (ОС и прочий софт) составляющая "инсекур бай дезинг", вы этого понять не можете, но брызжите за УБ о которых вам буквально носом тычат где и при каких условиях они встречаются. Так что за УБ в контексте безопасТности лучше молчите. Один уже пытался мне доказывать, что алгоритмы шифрования должны применятся и быть безопасТными в любой небезопасной среде, при любых условиях, не понимая главного - "Безопасность не продукт, а процесс" Б. Шнайер (ц) > Вы по прежнему не ответили на вопрос. > Для обновления софта, установленного глобально - да. Ваши варианты в студию, хотя я давно не имел дела с виной, вряд ли смогу полноценно оценить. setup.exe /install Uninstall previous version? [Y]: Сложно? Хотите сказать, зачем это делать руками? Я бы вам советовал бы сначала релиз нотсы почитать перед обновлением, надеюсь вы этого делаете. > Вы сами придумываете критерии, сами удивляетесь, что софт ему не соответствует. Вы обозначили его как демон и вы же его отрицаете (вы - в смысле разработчик) Я же говорю за клинику всяких демонизаций процесса установки, обновления, удаления и т.д. в пакетном менеджере. Далее как вы еще не поняли процесс демонизации это не механизм меж-процессного взаимодействия. > Такие вещи вам должно быть стыдно писать. Такие вещи существовали за долго до вашего рождения, существуют и щас за ширмой вашего недодемона, так что не надо мне этого говорить, я испытываю только "испанский стыд". > У вас мало того, что софт при установке может снести систему, так и зависимости не отслеживаются, и удаление пакета не даёт никаких гарантий удаления. Это произойдет ровно один раз, а после дураком будет тот кто будет использовать этот софт. Встретил бы я вас в начале нулевых (увы, вы еще не родились тогда, хотя предполагают дату вашего рождения не раньше 2004 года), когда всякие пхп, перлы и питоны собирались из исходников со всеми зависимостями и приходилось каждую зависимость отдельно конфигурировать под нужды и разбираться в каждом ворнинге или ошибке. Знаете сколько это по времени занимало? Ну конечно прибыль теряется, все должно быть х*як, х*як и в продакшен, континиус деливери, апт-гет апдейт и пох что там сломалось. > Про возможность использования разных версий и прочее лучше вообще не вспоминать. Лол, кек - ./configure --help вам в помощь. пс: Успехов, на этом все. "Мы должны брать из прошлого огонь, а не пепел." Ж. Жорес (ц) //ru.wikiquote.org/wiki/Жан_Жорес
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	119. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 27-Июн-25, 14:36
	>Куча УБ к чему приводит ? к проблемам безопасносТности? Вы рассуждаете как типичный дед - уб - это не страшно, уязвимости - это не страшно, падения программ и фантомные ошибки - это не страшно, а вот условный haskell, rust, ocaml - это страшно, очень страшно. >о которых вам буквально носом тычат где и при каких условиях они встречаются Уб должен быть ошибкой компиляции. >setup.exe /install И как непривеллигированный пользователь должен это дело запускать? Признавайте поражение. >Хотите сказать, зачем это делать руками? Обновления безопасности нужно ставить принудительно почти всем виндузятникам, так как иначе, всё это быстро превратится в один большой ботнет. >Я бы вам советовал бы сначала релиз нотсы почитать перед обновлением Вы не пишите софт даже уровня hello world. Вам нет смысла их читать, так как вы в готовом софте вообще ничего не измените. Зато вот захостить уязвимый сервис запросто сможете. >Вы обозначили его как демон и вы же его отрицаете Я не отрицаю, это вы отрицаете. >Такие вещи существовали за долго до вашего рождения Мракобесие тоже существует задолго до моего рождения, но это не повод им гордится. >когда всякие пхп, перлы и питоны собирались из исходников со всеми зависимостями Вы гордитесь тупой, бессмысленной работой? Бинарные кеши давным давно изобретены. >и разбираться в каждом ворнинге или ошибке О, так вы тот самый тысячеглаз, пропустивший миллионо cve? И вам не стыдно? >Лол, кек - ./configure --help вам в помощь. Соберите для начала xterm, как я приводил пример выше, потом поговорим. Ну конечно, вы же не осилили. >пс: Успехов, на этом все. Ой всё. Слив засчитан.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	120. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 27-Июн-25, 15:24
	> Вы рассуждаете как типичный дед - уб - это не страшно, уязвимости - это не страшно, падения программ и фантомные ошибки - это не страшно Где я такое писал? Я написал, что не надо мне говорить в контексте УБ за безопасТность, когда у вас как аппаратура так и софт - небезопасны по дизайну. УБ в ЯП это последнее о чем можно говорить в контексте инфобеза. > а вот условный haskell, rust, ocaml - это страшно, очень страшно. Вас не страшит, что машинный код за вас генерит левая программа? Когда поймете на сколько это страшно, тогда вам ни один ЯП не нужен будет. > Уб должен быть ошибкой компиляции. Да ради Бога, пусть так и будет в вашем компиляторе языка С, ведь стандарт вам говорит - поступай как хочешь, в чем проблема? А проблема в том, что вам нужно все готовое, а мне достаточно того, что есть, и признаю, что мне ни холодно и не жарко от того, что компилятор не может (не хочет) обработать УБ, я принимаю его таким какой он есть, но проблема ведь не в ЯП. Как можно "плеваться" в сторону естественного языка, только потому-что на нем можно матерно высказываться? Ну где логика? И тоже самое за всякие haskell, rust, ocaml, лично для меня все ЯП "высокого уровня" - не нужны, в них нет необходимости, это излишество, когда достаточно машинного мнемонического кода. > И как непривеллигированный пользователь должен это дело запускать? Признавайте поражение. Как вы собираетесь открывать замок, ключей от которого вы не имеете? > Обновления безопасности нужно ставить принудительно почти всем виндузятникам, так как иначе, всё это быстро превратится в один большой ботнет. Лучше, принудительно делать процедуру а*ального расширения всем программистам, которые пишут дырявый софт. > Вы не пишите софт даже уровня hello world. Ну и вы не создаете машин, на который исполняется ваш хелловрот. > Вам нет смысла их читать, так как вы в готовом софте вообще ничего не измените. Когда поймете, что значит "готовый" софт, тогда и придем вам озарение о бесполезности ваших действий по его апдейту. > Я не отрицаю, это вы отрицаете. Я вам цитату из документации привел. > Мракобесие тоже существует задолго до моего рождения, но это не повод им гордится. Я же сказал, я критик, мне нет нужды что-либо выгораживать, или чем-либо гордиться. Критик говорит за все За и за все Против в совокупности. В контексте сабжа, я критиковал ЛИШЬ демонизацию пакетного менеджера, и ничего более не сказал за его функциональность и все его плюшки за которые вы говорили, так как не было моей целью в полноте критиковать ваш nix. Но при необходимости могу и это сделать и покритиковать в полноте, каждую строчку кода и т.д. что равносильно аудиту, но делать этого не буду ведясь на чей-то понт, готовы платить за эту критику? > Вы гордитесь тупой, бессмысленной работой? Бинарные кеши давным давно изобретены. Вы ровно этим же и занимаетесь, в глаза не видавший ./configure --help > О, так вы тот самый тысячеглаз, пропустивший миллионо cve? И вам не стыдно? Мы же о сборке говорим (проблемах компиляции), причем тут cve? Повторяю, испытываю только "испанский стыд" именно за вас! > Соберите для начала xterm, как я приводил пример выше, потом поговорим. Ну конечно, вы же не осилили. Чтобы собрать xterm, надо открыть файл INSTALL и следовать инструкции по установке, не более, америку не открывайте. Но делал это я 20 лет назад, а щас мне достаточно сделать pkg install putty > Ой всё. Слив засчитан. Успехов!
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	71. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 09:47
	>Дайте определение понятия демон Всё вам дайте. Сами вы привести определение демона почему-то не хотите. >Я не вижу в этом списке ни калькулятора, не текстового редактора Где-то в соседнем сообщении вам написали про emacs, но вы опять почему-то не видете. Про vs code с веб интерфейсом тоже не забудьте. >ни сапера (игра) В нём нет мультиплеера. Отличие демона от не демона сугубо формальное в контексте тех же игр. >А клиент - это интерактивная программа запускаемая при необходимости, почему у вас клиент не служба? Значит в postgresql вы верите в существование отдельно клиента и отдельно сервера, а в случае nix - нет? >У вас шо там другого способа меж-процессного взаимодействия не нашлось? Какого другого? Вы уже привели пример с кроном, я вам привёл возражение, почему крон не подходит. На этом любые ваши предложения резко закончились. >Почему в этом списке нет калькулятора? Почему вы из всех примеров взяли калькулятор? Почему не взяли ту же vs code web? Вы берёте вещи с потолка и требуете пояснений. >Когда поймете для чего необходимы демоны, тогда поймете как достичь. Разумеется вы сами ничего не скажите, так как сами ничего не знаете. >Ей ГНУ-шники, почему ваш gcc до сих пор не демон? Какие из перечисленных свойств имеет gcc? Кроме того, вы хотя бы раз фронтенд на js писали? Не замечали, что сборщик можно запустить фоном, чтобы он перекомпилировал фронтенд по сохранению файлов? Или вы как всегда лезете туда, где не разбираетесь?
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	81. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 12:23
	> Всё вам дайте. Сами вы привести определение демона почему-то не хотите. Вы же у меня его не просили, а я у вас спрашиваю из необходимости, потому-что вижу, что вы им не владеете. > Где-то в соседнем сообщении вам написали про emacs, но вы опять почему-то не видете. Про vs code с веб интерфейсом тоже не забудьте. у вас имакс это клиент и сервер, понятие сервер по определению есть демон (служба). Для взаимодействия двух программ по сетевому сокету нет необходимости, чтобы одна из них работала 24 на 7, то есть была демоном (службой). Служба это не механизм взаимодействия, это вид деятельности. > Отличие демона от не демона сугубо формальное в контексте тех же игр. Ага, и античит должен быть в контексте ядра :) Вот поэтому и спрашиваю у вас определение понятия демон. > Значит в postgresql вы верите в существование отдельно клиента и отдельно сервера, а в случае nix - нет? Лол, собрать и установить программный пакет это действие по необходимости (сценарий). А служба базы данных - 24 на 7, разницу смекаем?. Зачем какая-то блоатварь необходимая мне раз в месяц должна висеть у меня в системе и отжирать мои ресурсы? Аля андроид, зачем завершать процессы если мы их все равно будем запускать :) > Вы уже привели пример с кроном, я вам привёл возражение, почему крон не подходит. На этом любые ваши предложения резко закончились. У меня в системе уже есть служба работающая 24 на 7 которая может выполнять любые сценарии, зачем мне еще какая-то служба блоатварная? О да крон у вас через минуту исполняет, а вам ежесекундно надо пакеты собирать? Ок, вам тогда нужен инструмент собирателя пакетов, а мне этот инструмент не нужен, мне достаточно вызвать команду blabla install xyz_software. Как говорил nooby, "есть такая профессия, пакеты собирать". > Почему вы из всех примеров взяли калькулятор? Почему не взяли ту же vs code web? Вы берёте вещи с потолка и требуете пояснений. с потолка, ну хоть не с бодуна. Я заведомо знаю, что вы мне не поясните, потому-что из первого же вашего комментария ясно, что вы не владеете определением понятия демон (службы). А чем калькулятор как программа отличается от программы установки пакетов? Калькулятором я пользуюсь чаще чем установкой новых программа, отсюда и вопрос почему он не демон? Потому-что это будет клиникой? Вот вам Fractal1 и указал на это. А на вопросы, почему взяли то, а не то, ответ очевиден, я же не могу отвечать за клинику людей. Гугл апдейтер в виде службы - разве не клиника? Не клиникой будет, разве, вкомпилить все драйвера в ядро и отказаться от модульности (запуске при необходимости)? А че не так? > Разумеется вы сами ничего не скажите, так как сами ничего не знаете. Успехов вам. > Не замечали, что сборщик можно запустить фоном, чтобы он перекомпилировал фронтенд по сохранению файлов? Он у вас 24 на 7 будет компилять? А там рассказы про кеши и т.д. это вообще что? Этим может заниматься только демон? Короче привет inetd :)
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 13:35
	>Вы же у меня его не просили Я у вас спросил, почему вы взяли, что демон это 24/7. В ответ громовая тишина. >Для взаимодействия двух программ по сетевому сокету нет необходимости Где вы увидели сетевой сокет? Опять галюцинации? Или вы не знаете, что бывают ещё и unix сокеты? >чтобы одна из них работала 24 на 7, то есть была демоном (службой). А теперь к вам наводящий вопрос: сокет может слушать только запущенная программа. Вот я запустил любую команду nix, демонов у меня нет, сокет никто не слушает. Каким образом должна запустится программа слушающая сокет? >понятие сервер по определению есть демон (служба) Давайте смешаем абсолютно всю терминологию, какую знаем. Так, что там у нас, на винде иконки значит есть, да? >Ага, и античит должен быть в контексте ядра А где ему быть? Либо в ядре, либо - нигде. >Вот поэтому и спрашиваю у вас определение понятия демон. Программа отделившаяся от консоли с которой её запустили и работающая фоном. >собрать и установить программный пакет это действие по необходимости (сценарий) Давайте возьмём ещё один термин, придумаем для него смысл и вставим в текст. >А служба базы данных - 24 на 7, разницу смекаем? Активация по сокету уже давным давно изобретена, но вы живёте так, словно на дворе максимум - 90-ые. >Зачем какая-то блоатварь необходимая мне раз в месяц должна висеть у меня в системе и отжирать мои ресурсы? Мы уже поняли, что вам нужен максимум каменный топор и костёр. Непонятно только, что вы в интернете забыли. >У меня в системе уже есть служба работающая 24 на 7 которая может выполнять любые сценарии, зачем мне еще какая-то служба блоатварная? У вас гарантированно есть init, но вы себе зачем-то поставили ненужный крон, следующая вашей же логике. Только не надо оправдываться. >а вам ежесекундно надо пакеты собирать? Вам уже написали, что кроме сборки пакетов, nix настраивает окружение, и привели пример программы, у которой прямо в shebang указан nix. >О да крон у вас через минуту исполняет, а вам ежесекундно надо пакеты собирать? При запуске любой команды nix, я ожидаю получить результат сразу же, а не когда-то там, когда крон отработает. >а мне этот инструмент не нужен, мне достаточно вызвать команду blabla install xyz_software Ну наконец-то. С этого и надо было начинать. Вам просто надо было в самом начале сказать: на дворе семидесятые/девяностые, и что вы не умеете и не хотите ни статическую линковку, ни контейнеры, ни изоляцию, ни в воспроизводимость сборок, ни в чистоту, ни разные версии библиотек, ни сменить libc, ни накладывать патчи, ни разделяемые зависимости, ни кучу других благ, дарованных nix-ом. Будете потешным линуксоидом, который в ubuntu 25.04 не может запустить программу, которую буквально вчера собрали в ubuntu 24.04. Который элементарные действия делает по часов пять в терминале, под всеобщий смех, а потом его постигает неудача. >Как говорил nooby, "есть такая профессия, пакеты собирать". То, что я делаю за секунд за тридцать, вы не сделаете никогда. >Что всего? Вот вам такой вариант: запуск xterm 320(сейчас в репозиториях 397) от 2016-05-19, который находился в ветке 15.09-beta в nixos 25.05, при том, что между ними 19 релизов. При этом, xterm работает в wayland. >nix-shell -p xterm -I nixpkgs="https://github.com/NixOS/nixpkgs/archive/$(echo 5d540387713f2d29dac423f5faadafd5aea2ff09).tar.gz" --run xterm Ваше решение в студию. >Так как opennet любит переписывать ссылки, то я воткнул echo для наглядности. Давайте, скажите, что запускать старые программы, это нинужна, на потеху виндузятникам и пользователям nix, snap, flatpak. Если справитесь, то давайте остальные вещи nix-а воспроизведите. Только вот учтите, что вы, как и ваш nooby, должны результат выдавать так же быстро как и nix, так же надёжно, как и nix, и так же бесплатно, как nix. >А чем калькулятор как программа отличается от программы установки пакетов? Давайте, расскажите, почему jupiter notebook не может работать в браузере без демона. >Потому-что это будет клиникой? Вот вам Fractal1 и указал на это. Я вас удивлю, но некомпетентность в МКБ почему-то отстутствует. >Гугл апдейтер в виде службы - разве не клиника? Ваши предложения. Вы код не то, что не пишите, вы даже внятно сформулировать не можете. >Он у вас 24 на 7 будет компилять? Держите https://nixos.wiki/wiki/Nix-shell_shebang #! /usr/bin/env nix-shell #! nix-shell -i bash -p imagemagick cowsay # scale image by 50% convert "$1" -scale 50% "$1.s50.jpg" && cowsay "done $1.q50.jpg" >А там рассказы про кеши и т.д. это вообще что? Незнакомые слова встретились? >Этим может заниматься только демон? Решение задачи nix-collect-garbage в студию.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 15:17
	> Я у вас спросил, почему вы взяли, что демон это 24/7. В ответ громовая тишина. Ну ка номер коммента где вы это спросили? > Где вы увидели сетевой сокет? Опять галюцинации? Или вы не знаете, что бывают ещё и unix сокеты? Сокеты это механизм взаимодействия, непойму вашу придирку. > Каким образом должна запустится программа слушающая сокет? Слушающий сокет программа не обязательно демон (служба), а запускается может всеми доступными способами запуска. Сокеты это механизм взаимодействия программ и ни как не определитель демон это ли нет. > Давайте смешаем абсолютно всю терминологию, какую знаем. Вы сначала дайте определение термину демон (служба), потом уже мешайте, я уже 10 раз повторил определение, а вы ни разу. > А где ему быть? Либо в ядре, либо - нигде. А потом обижаетесь почему обозвали клиникой. Мне нечего тут сказать. > Программа отделившаяся от консоли с которой её запустили и работающая фоном. То есть не интерактивная, а взаимодействие с ней как вообще происходит? и должно ли быть с ней взаимодействие? А "предоставление услуг", этой отделившейся от консоли программы, считается взаимодействием интерактивным? Если да, то чем она отличается от не отделившейся от консоли интерактивной программы? В чем разница между программой калькулятор и программой демоном (службой) синхронизации времени по сети? не догадались? Разница - в необходимости второй работать 24 на 7. > Активация по сокету уже давным давно изобретена, но вы живёте так, словно на дворе максимум - 90-ые. Это должно определять программа демон или нет? > Мы уже поняли, что вам нужен максимум каменный топор и костёр. Непонятно только, что вы в интернете забыли. Там где достаточен топор в бензопиле нет необходимости. Необходимость и достаточность - два критерия оптимальности. > У вас гарантированно есть init, но вы себе зачем-то поставили ненужный крон, следующая вашей же логике. Только не надо оправдываться. ну так это претензии не ко мне, ваши эти юниксы и линуксы я еще много могу покритиковать, далеко не ходите там еще и inetd есть :) С чего вы взяли, что я критикую nix в угоду юникс линукс традициям :) > При запуске любой команды nix, я ожидаю получить результат сразу же, а не когда-то там, когда крон отработает. ну запускайте программу в консоли, blablabla install new_software, в чем проблема? Крон был приведен в пример как служба исполняющая сценарии по расписанию. Установка конкретной программы - операция исполняемая единожды по требованию пользователя, а вот обновление смело можно делать через службу расписаний (на свой страх и риск). > ни кучу других благ, дарованных nix-ом. Прав все таки nooby - "есть все же такая профессия - пакеты собирать" :) Да ради Бога, пользуйтесь, вам же предъявили за то как "вы" это сделали :) Приведу простой пример из жизни про "кучу благ": Вот простой пленочный фото-аппарат от sony меня без моего ведома не сфоткает в целях злодейских, а вот "ваш" айфон с камерой делает это. Кому сказать спасибо за эти блага? Кто решил, что возможность иметь телефон, камеру, магнитофон в одном флаконе это необходимое благо? Возразите, скажите, что принцип "швейцарского ножа" - благо, да благо, только вы пробовали поработать со швейцарским ножом когда раскрыты все его благие части? Вот ваш телефон это раскрытый "швейцарский нож" и благо он приносит тому кто его таким задумал, не вам вовсе. Отсюда человеку которому необходим нож для строгания дерева "швейцарским" не пользуется. > То, что я делаю за секунд за тридцать, вы не сделаете никогда. Каждому свое, я тут с вами не соревнуюсь в чем то. Я критикую! > Ваше решение в студию. > Только вот учтите, что вы, как и ваш nooby, должны результат выдавать так же быстро как и nix, так же надёжно, как и nix, и так же бесплатно, как nix. лол, кек, ни я ни nooby никому ничего не должны :) > Давайте, расскажите, почему jupiter notebook не может работать в браузере без демона. хром ОС :)) я должен знать почему у дурака иногда голова болит, когда он бьется об стену? Фрактал написал ведь - клиника, а я пояснил по какой причине это верно, а причина одна - не понимания понятия демон (служба). Блоатварьность это новая тенденция, а как еще зарабатывать, как еще маскировать (кто в теме тот поймет). > Ваши предложения. Вы код не то, что не пишите, вы даже внятно сформулировать не можете. Блоатварный код не пишу, верно заметили. > Держите https://nixos.wiki/wiki/Nix-shell_shebang а че не в докер докер докер докер докер шел шел не запускаете? Клиническая блоатварь! > Незнакомые слова встретились? Надо же греть планету новыми словами (ц) :) > Решение задачи nix-collect-garbage в студию. Мой гербейдж во дворе убирают по расписанию, что не так они делают? Надо постового (службинца) поставить перед урной, чтобы в реалтайме перехватывал мой гербейдж и перерабатывал его, возвращая мне какой-нибудь производный продукт? :)
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 16:05
	>Ну ка номер коммента где вы это спросили? Ctrl + F, а далее введите 24. >непойму вашу придирку. Не нужно путать частное с целым. >а запускается может всеми доступными способами запуска Например. Вот я ввёл nix-shell. Кто должен этот запустить программу, слушающий сокет? >Вы сначала дайте определение термину демон Вам уже давали: >Вы сами придумали это определение. Демон - это фоновый процесс. Формально, тот который при запуске отсоединяется от терминала. Но вы так и не заметили. >я уже 10 раз повторил определение, а вы ни разу. Вы несколько раз повторили придуманное собой же определение. Даже сейчас вы не потрудились ответить, откуда его взяли, ибо вы его просто придумали. >Мне нечего тут сказать. Всё верно, "вам тут сказать нечего". В противном случае, вы бы поняли, что античиты запускаются в режиме ядра для полного контроля системы. Чтобы затруднить скрытие чита, например запуском его от другого пользователя или отладчика. Именно для этого и нужны привелегии ядра. Ибо будь античит запущен в юзерспейсе, первый же ядерный модуль или просто программа, запущенная от другого пользователя, его бы обошла. >То есть не интерактивная, а взаимодействие с ней как вообще происходит? Отсутствие в определении "интерактивная" как раз таки и говорит, что интерактивность на это никак не влияет. >и должно ли быть с ней взаимодействие? Не должно. >Если да, то чем она отличается от не отделившейся от консоли интерактивной программы? Тем, что она отделилась и работает в фоне, очевидно же. >Это должно определять программа демон или нет? Клиент не активируется по сокету, очевидно же. >Там где достаточен топор в бензопиле нет необходимости. До изобретения бензопил все использовали топоры - вывод: бензопила нигде ненужна. >ну запускайте программу в консоли, blablabla install new_software, в чем проблема? nix, если вы не заметили, тоже запускается и консоли. Ваш совет заведомо ложный. И докер тоже запускается из консоли. >Установка конкретной программы - операция исполняемая единожды по требованию пользователя Установка - однократная, настройка окружения - многократная. Я вам привёл пример: попробуйте скомпилировать программу с разными версиями библиотек. В ответ тишина. >Да ради Бога, пользуйтесь, вам же предъявили за то как "вы" это сделали :) Нет, не ради. Вы осознали, что повторить эффект от команды, которую можно написать за несколько минут, вы не сможите. Полагаю и ваш nooby вам в этом не сильно поможет. Но публично признаться в собственной некомпитентности, пускай и под анонимом, вам стыдно. >Вот простой пленочный фото-аппарат от sony меня без моего ведома не сфоткает в целях злодейских Зато чужой аппарат вас прекрасно нащёлкает. >Кто решил, что возможность иметь телефон, камеру, магнитофон в одном флаконе это необходимое благо? Не имейте, разрешаю. Заметьте, вы не выступаете с инициативой как сделать айфон безопаснее. >Я критикую! Вы хвастаетесь своей безграмотностью. "Смотрите, я ничего не знаю, знать не хочу, пусть мир прогнётся под моё незнанение". А когда вас спрашиваю, как именно он должен прогнуться, вы тут же уходите от темы. >лол, кек, ни я ни nooby никому ничего не должны :) В первую очередь, вы точно так же не должны быть сколь угодно компетентными. Монитор - это процессор, да. >не понимания понятия демон (служба) А у вас это понимание есть? Даже по вашей логике, программа не обязана работать 24/7, а должна быть доступна. Но если с тем, что условный nginx работает несколько часов в день вы соглашаетесь, а с тем что nix работает точно так же - нет. Типичное лицимерие. >Блоатварный код не пишу, верно заметили. Вы никакой не пишите, даже hello world. >а че не в докер Тяжёлый случай. Вы и докер ниасилили. >Мой гербейдж во дворе убирают по расписанию, что не так они делают? Вопрос не в уборке по расписанию, это как раз можно сделать. Вопрос в поиске достижимых пакетов. Вот проснётся сборщик мусора по расписанию в полночь, увидит что условный gcc никому не нужен и снесёт его. Мне удивительно, что такие очевидные вещи нужно пояснять. Кроме того, если нужно видеть, какие пакеты используются, а какие - нет - нам нужно это как-то мониторить. Вы до сих пор не привели ни одного варианта, как отличить одноразовый пакет от активно исползуемого. В условном дебиане/винде с этим проблема. В дебиане её костылят тем же чрутом, о котором я уже писал. ЗЫ если вы настолько некомпитентны, что у вас нет технических аргументов, то просто признавайте своё поражение.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	102. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 18:36
	> И докер тоже запускается из консоли. Docker Engine Docker Engine is an open source containerization technology for building and containerizing your applications. Docker Engine acts as a client-server application with: 1) A server with a long-running daemon process dockerd. 2) APIs which specify interfaces that programs can use to talk to and instruct the Docker daemon. 3) A command line interface (CLI) client docker. The CLI uses Docker APIs to control or interact with the Docker daemon through scripting or direct CLI commands. Many other Docker applications use the underlying API and CLI. The daemon creates and manages Docker objects, such as images, containers, networks, and volumes. client-server application и long-running :) > Я вам привёл пример: попробуйте скомпилировать программу с разными версиями библиотек. В ответ тишина. попробуйте еще и по-жонглировать пока идет сборка, речь же не об этом, речь об обоснованной необходимости демона в этом процессе. > Вы осознали, что повторить эффект от команды, которую можно написать за несколько минут, вы не сможите. я и микроскопом забиваю гвозди, да только обычно микроскопические, но к вопросу о необходимости пакетному менеджеру быть демоном это никак не относится. Если до вас до сих пор не дошло определение понятия демона, как до вас дойдет описание "повторить эффект от команды". > Вы хвастаетесь своей безграмотностью. "Смотрите, я ничего не знаю, знать не хочу, пусть мир прогнётся под моё незнанение". А когда вас спрашиваю, как именно он должен прогнуться, вы тут же уходите от темы. ну где там определение: Демон - это .... > А у вас это понимание есть? Даже по вашей логике, программа не обязана работать 24/7, а должна быть доступна. Должна быть доступна тогда и только тогда когда запустится клиент. Да именно тогда должна она быть доступна. Потому-что это демон, и не обязана быть доступна когда в ней нет необходимости. В случае с nginx - это по определению демон, так как необходима доступность веб ресурсов 24 на 7. А в случае с пакетным менеджером, что мне необходимо в доступности 24 на 7 или всего лишь минуту? Да ничего. Пакетный менеджер обычная интерактивная программа, и необходимости быть демоном в ней нет. Отсюда и клиника, делать из пакетного менеджера демона. > Но если с тем, что условный nginx работает несколько часов в день вы соглашаетесь, а с тем что nix работает точно так же - нет. Типичное лицимерие. для nginx обоснована необходимость быть демоном, для nix - нет. Так в чем лицемерие если вы сравниваете два демона? У вас ведь nix-daemon это демон по определению, где обоснованность его необходимости? Почему rpm - не демон? > Вы никакой не пишите, даже hello world. на кой мне ваши хеловроты, как говорит пох,нах :) > Тяжёлый случай. Вы и докер ниасилили. на кой он мне когда давно существует бсдешные джейлы :) > Вы до сих пор не привели ни одного варианта, как отличить одноразовый пакет от активно исползуемого. Дайте угадаю, для этого нужен демон подобия старт_меню_юзер_экспириенс ? :)))))) рассмешили, понятно теперь откуда появляются всякие идеи телеметрии и а*альных зондов в системе. > В условном дебиане/винде с этим проблема. Рожденный ползать - попугай :) > ЗЫ если вы настолько некомпитентны, что у вас нет технических аргументов, то просто признавайте своё поражение. :))) я не воюю, я критикую. Это вы должны технически аргументировать необходимость пакетному менеджеру быть демоном, rpm-у нет необходимости быть менеджером, что не так с nix?
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	109. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 19:40
	>client-server application и long-running Ну и? Что вы этим хотите сказать? nix устроен похожим образом. >речь об обоснованной необходимости демона в этом процессе. Каким образом, вы собираетесь заниматься изоляцией и сборкой мусора? Я от вас дождусь этот ответ или нет? >ну где там определение: Демон - это .... Вспоминайте. То, что работает в фоновом режиме. >Должна быть доступна тогда и только тогда когда запустится клиент. Я вам давным давно писал про активацию по сокету. Вы это молча проигнорировали, а сейчас повторяете свои прошлы выдумки. >А в случае с пакетным менеджером, что мне необходимо в доступности 24 на 7 или всего лишь минуту? Вам уже даже привели статус из консоли, где видно, что активация происходит по сокету, а не круглосуточно. >Пакетный менеджер обычная интерактивная программа, и необходимости быть демоном в ней нет. Как вы реализуете поддежания целосности системы, без сервера? Или ыксперды не занимаются такими скучными вещами? >для nginx обоснована необходимость быть демоном Нет. Условный python -m http.server вполне себе работает без ухода в фон. >Почему rpm - не демон? Потому, что не работает в фоне. В частности, там нет сборки мусора, и прочих других вещей. Керосиновой лампе почему-то тоже не требуется электроенергия. >на кой мне ваши хеловроты, как говорит Ну вы программировать не умеете, а учите программистов как им программы писать, хотя это наоборот, программисты должны вас учить. >на кой он мне когда давно существует бсдешные джейлы :) Давайте возьмём допотопную технологию, и будем рассказывать, какая она хорошая. jail-ы научились разделять зависимости с хостом? Или десять джейлов, - одинадцать zsh? >Это вы должны технически аргументировать необходимость пакетному менеджеру быть демоном, rpm-у нет необходимости быть менеджером, что не так с nix? Тот факт, что rpm куда примитивнее, чем nix. В rpm нет возможности поставить несколько разных версий библиотеки - нет необходимости конфигурировать перменные типа PATH динамически. Нет сборки мусора, как следствие необходимость удалять ненужные пакеты целиком на плечах пользователя. Забыл удалить пакет - система забивается. Нет изоляции при сборке пакета - кривые спеки могут не собираться на чистой машине. Нет воспроизводимости - на двух машинах может установится разная система. Возможность запустить только один экземпляр пакетного менеджера одновременно. И так далее. Вы до сих пор ни по одному из этих пунктов ничего не отвтетили.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	111. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 20:34
	> Ну вы программировать не умеете, а учите программистов как им программы писать, хотя это наоборот, программисты должны вас учить. я видел "программистов", которые писали апач, и видел сисадмина, который написал nginx! И вижу смузихлебную чатгопоту брызжащая с клаудшмарной пингоры. > jail-ы научились разделять зависимости с хостом? вот не надо начинать > Забыл удалить пакет - система забивается. детский сад, короче все устал обсуждать эту ересь. > И так далее. Вы до сих пор ни по одному из этих пунктов ничего не ответили. И для всего этого необходим демон? Все, все, я этим не пользуюсь мне это не нужно :)
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	115. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 27-Июн-25, 09:29
	>я видел "программистов", которые писали апач, и видел сисадмина, который написал nginx! Любой человек, пишущий код - программист. >> jail-ы научились разделять зависимости с хостом? >вот не надо начинать Надо. Об этом нужно постоянно говорить, чтобы показать, что отказались от старых технологий не просто так, а по причине их примитивности и непригодности к современным реалиям. >детский сад, короче все устал обсуждать эту ересь. Надо же, кто-то опять понял, что возразить ему нечего. Поскольку единственный признак для rpm - вручную пакет установлен или нет, то даже одноразовый пакет, поставленный на пять минут, ничем не будет отличаться от того, который нужен постоянно. И то, что в nix делается букавльно из коробки, в rpm нужно ещё выяснить как сделать.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	116. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (80), 27-Июн-25, 09:37
	> Любой человек, пишущий код - программист. А любой человек, завывающий по пьяне, певец? > Надо. Об этом нужно постоянно говорить, чтобы показать, что отказались от старых > технологий не просто так, а по причине их примитивности и непригодности > к современным реалиям. Если вы сейчас не про конкретное ПО, а вообще, то это вздор! При разумном подходе новое ПО: 1. Должно решать проблемы, которые не могло решить предыдущее ПО, и должно решать теже проблемы, что решало предыдущее. 2. Не должно быть усложнено. 3. Не должно создавать новые проблемы. 4. Должно быть свободным. А современные реалии могут быть разными. В т.ч. вредоносными для человеческой цивилизации (будь то хоть отвратительное техническое решение, будь то хоть угнетающее свободу индивида).
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	118. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 27-Июн-25, 13:19
	> Надо же, кто-то опять понял, что возразить ему нечего. Вам на этот комент уже ответили, а я воздержусь, ибо согласен с выше сказанным в комменте 19.116, Аноним (80), 09:37, 27/06/2025
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	121. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (43), 27-Июн-25, 15:31
	> Давайте возьмём допотопную технологию, и будем рассказывать, какая она хорошая. jail-ы научились разделять зависимости с хостом? Или десять джейлов, - одинадцать zsh? Всегда умели. И пользовались этим еще с древних времен, хотя вместо "хоста" обычно таки предпочтительней отдельный "шаблон" (template/base-jail), который шарят service-jails с конкретным сервисом ...
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	103. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 18:38
	Note that this daemon does not fork into the background. :)))))))))
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	108. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 19:14
	Как и ожидалось, ыкспердище откопал экспиреминтальную программу и делает выводы. Сейчас запускается команда nix-daemon nix-daemon --daemon
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	68. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (68), 26-Июн-25, 08:30
	> Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно. > И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение. Вы сами на свои вопросы и отвечаете, нет? Делаете окружение пользователя-сборщика пакетов, компилируете пакет с указыванием нужного ABI (а не libчто-то.so), собираете в тарбол и файликом, который говорит, какой конкретно ABI мы хотим. Вы проблему версий "одному нужно то, другому это" из пальца высасываете банальным нежеланием напрямую пользоваться инструментами, которые у вас в линуксе уже есть.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	72. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 09:54
	>банальным нежеланием напрямую пользоваться инструментами, которые у вас в линуксе уже есть. Нет у вас никаких инструментов. Весь смысл nix в том, что он как раз таки и является инструментом сам. >компилируете пакет с указыванием нужного ABI (а не libчто-то.so) Код в студию. Или вы как и фрактал код не пишите, а только рассуждаете? >собираете в тарбол и файликом, который говорит, какой конкретно ABI мы хотим. Про разделяемые зависимости вы слышали? Про кеширование? И потом, тарбол нужет только для переноса на другую машину, для локальной разработки он избыточен. Опять же, код в студию.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 00:32
	>Почему у вас калькулятор еще не служба или там текстовый редактор? emacs --daemon передаёт вам пламенный привет. Условный vs code или phpstorm тоже где-то внутри обениваются ipc, ибо запуск нового экземпляра открывает не новое окно редактора, а вкладку в текущем сеансе. Да даже браузеры, не важно firefox или chrome тоже живут по такой логике. Не пишите то, в чём не разбираетесь.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	64. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 01:15
	> emacs --daemon передаёт вам пламенный привет. Ну вот уже прогресс, а теперь вопрос, возможно ли клиент-серверную архитектуру ПО реализовать без понятия службы? Вы понимаете что сервер может быть удаленным? """ Emacs supports a client/server mode where new files are opened in a running instance of Emacs. This saves you from having to load configuration and packages for every new file you open and allows the sharing of buffers between different emacs frames opened externally. This involves two configuration steps: using EmacsClient to open files, and running the Emacs server. This page focuses on how to launch the server at startup, a.k.a. daemon mode. This feature was introduced in Emacs 23.1 """ > Условный vs code или phpstorm тоже где-то внутри обениваются ipc, ибо запуск нового экземпляра открывает не новое окно редактора, а вкладку в текущем сеансе. Клиент-серверная архитектура - это не ipc! > Не пишите то, в чём не разбираетесь. лол, точно клиника.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 09:26
	>Вы понимаете что сервер может быть удаленным? Откройте unut файл nixos-container, и обнаружите, что для котнейнера nix как раз таки удалённый, обращается к хостовому. Вы вообще nix хоть раз своими глазами видели?
	Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
Сообщение от Аноним (4), 25-Июн-25, 14:10
О про Nix. Все пытаюсь узнать - можно ли одной общей настройкой сделать сборку своего пакета во множестве вариантов (все используемые библиотеки всех версий)? Типа написал один конфиг сборки - и генерируешь пакеты своей программы на каждую комбинацию библиотек. Иначе смысла для разработчиков в Nix особо не вижу.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Amerigo (?), 25-Июн-25, 14:26
	Flakes + Overlays вам в помощь.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (4), 25-Июн-25, 14:55
	Быстро просмотрел. Но, кажется, там нет возможности задать использование разных версий библиотек в разных комбинациях.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (17), 25-Июн-25, 15:06
	> все используемые библиотеки всех версий Это ж сколько там будет версий! Попробуй взять калькулятор и рассчитать, сколько миллиардов сборок тебе придется сделать.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	31. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 25-Июн-25, 15:36
	>Типа написал один конфиг сборки - и генерируешь пакеты своей программы на каждую комбинацию библиотек. Можно, map reduce изобретён. Ну разумеется, если исходный код и компилятор такое переживёт, со стороны nix таких ограничений нет. Всё же nix это функциональный язык.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	37. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (17), 25-Июн-25, 15:48
	А вообще, в никсе так не принято. (Да и нигде так не принято.) Ты оформляешь пакет в виде функции, которая: 1) принимает все свои зависимости во входном attrset, 2) возвращает дериватив. Далее этот пакет вызываешь при помощи pkgs.callPackage. И все, финальный пакет соберется с зависимостями, подтянутыми из pkgs. Но если кому-то приспичило подменить одну зависимость на другую, он сделает your-package.override { libfoo = libfoo-123; }. Пытаться сразу собирать пакет со всеми возможными комбинациями действительно приведет к миллиардам сборок: месяцами будешь тестировать 24/7 и платить за электричество.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	41. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 25-Июн-25, 16:03
	>А вообще, в никсе так не принято. (Да и нигде так не принято.) Не совсем. Вот есть, например pkgs.pkgsMusl, который хранит в себе дерево пакетов для musl. Или есть pkgs.linuxPackages, который позволяет как выбрать версию ядра, так и сразу какой-то набор патчей. Так что уже прямо в репозитории есть готовые пакеты несколькоих разных версий.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (57), 25-Июн-25, 22:57
	> Пытаться сразу собирать пакет со всеми возможными комбинациями действительно приведет к миллиардам сборок: месяцами будешь тестировать 24/7 и платить за электричество. Очевидно это в общем случае. В частном - у меня используется, скажем, 5 библиотек для которых выпускают версии раз в год - два. В итоге сборок будет много - но не бесконечно много.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	73. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от scor (ok), 26-Июн-25, 09:56
	Как уже сказали, nix хоть и самобытный, но полноценный язык, на котором можно реализовать любую логику. Вот, как пример, flake, который собирает кастомную питонячку для разных архитектур https://github.com/mindwm/mindwm-sdk-python-ng/blob/master/f... Точно также, как в цикле подставляется нужный `${system}`, можно и для всех нужных версий библиотек сделать permutation и пройтись по этому списку, нагенерив туеву хучу вариантов сборок.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (4), 26-Июн-25, 13:38
	Как я понял, system захардкожено. Остальное надо как-то по-другому реализовывать.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 13:54
	>Остальное надо как-то по-другому реализовывать. Вам прямо сказали использовать map reduce. https://nix.dev/manual/nix/2.18/language/builtins#builtins-map https://nix.dev/manual/nix/2.18/language/builtins#builtins-f...' хотя для данной задачи скорее всего только map нужен будет. Ну и посмотреть как это реализовано для тех пакетов, у которых несколько версий, типа python, ocmal и так далее.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 13:59
	То есть, вы вначале определяете список всех версий библиотек, потом взаимно рекурсивно определяете пакеты https://nix.dev/manual/nix/2.18/language/constructs#recursiv..., а потом условным map-ом собираете все версии сразу. Ну или делаете что-то вроде этого https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/devel.... Ну или любую другую логику, какая вам нужна.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	106. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от scor (ok), 26-Июн-25, 19:05
	Не очень понял, что значит "захардкожено".:) Определён список архитектур, под которые можно собрать. Автор flake-а сам определяет, какой именно список ему нужен. С версиями библиотек примерно тоже самое. Откуда-то они (нормера версий) должны же взяться? Типа, берём список версий двух библиотек, считаем произведение: ``` ghci> libA = ["liba-1.0.0", "liba-1.1.2", "liba-2.3.0"] ghci> libB = ["libb-1.2.1", "libb-1.3.5", "libb-2.0.1"] ghci> mapM print $ [(x,y) | x <- libA, y <- libB] ("liba-1.0.0","libb-1.2.1") ("liba-1.0.0","libb-1.3.5") ("liba-1.0.0","libb-2.0.1") ("liba-1.1.2","libb-1.2.1") ("liba-1.1.2","libb-1.3.5") ("liba-1.1.2","libb-2.0.1") ("liba-2.3.0","libb-1.2.1") ("liba-2.3.0","libb-1.3.5") ("liba-2.3.0","libb-2.0.1") ``` Соответственно, для каждой бибилиотеки, каждой версии нужно будет описать как её собирать. Дальше, по этому списку собираем наш проект с конкретными версиями, на выходе получаем очень много бинарников. Хз зачем, но можно и так.:)
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

5. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+2 +/–
Сообщение от Аноним (-), 25-Июн-25, 14:11
Это тот самый NIX который используется в самой лучшей (по мнению её фанатов) NixOS ? Которая самая удобная и безопасная, не то что ваши эти...
Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (-), 25-Июн-25, 14:14
	Ага.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (9), 25-Июн-25, 14:19
	Что же безопасно...
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

15. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+3 +/–
Сообщение от Шарп (ok), 25-Июн-25, 14:40
Лабораторная уязвимость. В реальности недостижимо.
Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (4), 25-Июн-25, 14:58
	Вообще-то стандартная. Делаешь свою сборку пытающуюся использовать эту уязвимость. 100000 соберут - у одного сработает. Все - профит.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от User (??), 25-Июн-25, 15:12
	Поди што и чинить не надо? Хотя... не rhel с ubuntu'ой - на той машине с NIX'ом один черт, ничего интересного нет, а те 5 сольдо что есть - проще выцыганить звонком про "безопасный счет ФСБ"...
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	70. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от yet another anonymous (?), 26-Июн-25, 09:44
	Согласен. Техника сродни "эстонскому вирусу".
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

46. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
Сообщение от Аноним (46), 25-Июн-25, 17:46
Не доверяю я всем этим никсам. Раздражает все это жуткое дробление, каждый норовит придумать свою систему сборки, свой линукс, свой язык. Думает, что лучше других знает как надо программировать. А простве работяги от этого страдают, захламляют свои системы всяким барахлом, нужным для одного конкретного пакета. Думаю, что nih синдром пора классифицировать как реальное заболевание и принудительно лечить на рабочих местах(и организовать патрули в местах проживания/скопления программистов)
Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+4 +/–
	Сообщение от аноним1277zx (?), 25-Июн-25, 18:01
	Вам лишь бы зарегулировать и патрулей наставить, ей богу.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (61), 25-Июн-25, 21:14
	Типичный вахтёр - сам ничего не делает, а другим запрещает. Осуждаю.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

76. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
Сообщение от Анатолька (?), 26-Июн-25, 11:02
Я вот Эльбрус ОС пользуюсь - там залатали все что можно, а часть ядра просто переписали
Ответить | Правка | Наверх | Cообщить модератору

	113. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (-), 27-Июн-25, 00:49
	Завидую. А я даже купить не имею возможности чтоб глянуть
	Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
Сообщение от Аноним (75), 26-Июн-25, 11:07
Тот случай, когда о существования сабжа узнал из новости про его уязвимость (я про Lix, кстати забавно что оно созвучно со словом Leaks)) И вот что я прочёл у них на сайте в описании почему нужно использовать этот форк Nix, в одной из главных фич: A safe community for developers of all backgrounds.     Lix is developed by a diverse group of users – and accordingly is committed to providing a space that’s safe for users and developers typically underrepresented in technical projects. We take moderation seriously, and are committed to preventing bad actors from driving out marginalized groups. https://lix.systems/about/ Дальше можно было бы не читать, но там ещё рассказывают что Nix зарегрессировал однажды, а Lix мудро остановился в развитиии на стабильной версии, но всё же не забывает бэкпортить некоторые фичи. Это в принципе всё, что нужно знать про этот форк, ящитаю.
Ответить | Правка | Наверх | Cообщить модератору

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

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