Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
[ERROR] The compilation of ocaml-base-compiler failed at "/home/me/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /home/me/.opam/ocaml-base-compiler.4.02.3 -with-debug-runtime".
#=== ERROR while compiling ocaml-base-compiler.4.02.3 =========================#
# context 2.0.0 | linux/x86_64 | | https://opam.ocaml.org#12c8601e
# path ~/.opam/ocaml-base-compiler.4.02.3/.opam-switch/build/ocaml-base-compiler.4.02.3
# command ~/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /home/me/.opam/ocaml-base-compiler.4.02.3 -with-debug-runtime
# exit-code 2
# env-file /tmp/opam-me-3195/ocaml-base-compiler-3195-d6d332.env
# output-file /tmp/opam-me-3195/ocaml-base-compiler-3195-d6d332.out
### output ###
# ./configure: line 195: rm: command not found
# ./configure: line 196: touch: command not found
# ../gnu/config.guess: line 35: sed: command not found
# ../gnu/config.guess: line 1364: mkdir: command not found
# ../gnu/config.guess: line 1364: mkdir: command not found
# : cannot create a temporary directory in /tmp
# [ERROR!] Cannot guess host type. You must specify one with the -host option.
^ ...И так там со всем.
Кто там хотел попробовать "NixOS"? Могу поделиться впечатлениями: если вы надеятесь, что в этой оси можно будет пользоваться привычными "autotools", "opam" и "cabal", то фиг там. Из-за сломанного FHS ебаться с "Nix" придётся с первой минуты. cast @Роман
> Слушай, ну на никс надо всё ставить через nix, это же очевидно а не с сыруов.
Ты когда патчи тестируешь, тоже rpm-ки всегда собираешь? Системный софт это одно, а локальная помоечка — совсем другое.
> Ты же не будешь пытаться запустить pkgsrc на centos, а rpm на solaris?
Суть не в этом. Сорцы уровнем ниже, чем пакетный менеджер, они в принципе должны быть независимы от пакетного менеджера.
Суть в том, что в никсе вообще не может быть никакого "/usr/bin/sed" или "/usr/bin/python". Вся идея как раз в том, чтобы отказаться от глобального мутабельного стейта.
Разным программам могут быть нужны разные версии python, в никсе они могут сосуществовать, поэтому не понятно, какой из них должен лежать в /usr/bin.
Программы из сорцов в никсе собирают, это обычно делается примерно следующим образом: ты пишешь default.nix, в котором описано всё, что тебе нужно, чтобы собрать программу (sed, make, вот это всё). Потом ты вызываешь nix-shell, который открывает тебе шелл, в котором есть ровно то, что ты попросил, и ничего больше. Там ты можешь выполнить билд (make velik / cabal new-build velik /dune velik.exe) и поиграться с результатами. См. пример [1].
Такие окружения полностью герметичны и воспроизводимы, не то что всякие "virtualenv".
К сожалению, нужно таки писать default.nix. С другой стороны, если ты патчишь эрланг, можно написать один раз и накопипастить готовых определений.
autotools пытается угадать, что где лежит, многие зависимости опциональны. Завязывать сборку какого-нибудь ынтерпрайзного софта на autotools -- это самоубийство.
Можно поставить «DDP» (на свалке ещё можно найти драйвер этого протокола, но только для старых версий «Windows», потому что даже компания «Apple» перешла на «TCP» и «UDP»).
Ещё с портами есть Datagram Congestion Control Protocol (DCCP) и Stream Control Transmission Protocol (SCTP), но в дикой природе их увидеть сложно, потому что не все маршрутизаторы догадываются о том, что кроме «TCP», «UDP» поверх «IPv4» и «IPv6» ещё что-то может быть.
Для админов может это и хорошо, что можно админить не вынимая руки из жопы, ибо всё легко откатить. Но для девелоперов такая жизнь боль: у меня одних эрлангов локально стоит штук семь, разных версий и с разными патчсетами, с деревяшными такое собирать с ума сойдёшь.
Хотя на сервер `NixOS' и интересно было бы вкатить.
нет. но тред читал. роли не играет. с подобными системами работал. на таких системах всегда есть базовый пакет (или даже два - один для нормального окружения, второй для chroot компиляты), который отвечает за базовае тулзы.
"каждый апп в своем пакете и окружении" относится только к end-user приложениям (e.g. FireFox or OpenOffice). и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС. пакеты с приложениями компилирутся на основе этого базового окружения - и в рантайме приложение им же и пользуется.
новая мода. меня не сильно впечатлило.
ЗЫ немного напомнило старую моду. все недостатки static linking, одновремменно с отсутствием всех преимуществ static linking.
>> на таких системах всегда есть базовый пакет
значит, всё таки не читал.ъ
[quote]
NixOS не соответствует стандарту иерархии файловой системы. Единственными исключениями являются symlink /bin/sh для версии bash в менеджере пакетов Nix (например: /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/) и, в то время как у NixOS есть каталог /etc для хранения файлов конфигурации всей системы, большинство файлов в этом каталоге являются символическими ссылками на сгенерированные файлы в /nix/store, такие как /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета.
[/qupte]
>>и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС
бсд ставит софт локально.
на таких системах - выплевывается пакет приложения с зависимостями (которые базовая система не предоставляет).
> значит, всё таки не читал.
теперь прочитал. 😉
все равно смысла мало вижу в прочитаном - надо руками щупать.
потому что, например - "Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета." - не имеет никакого смысла. потому что кто-то/что-то должно управлять этими "несколькими версиями пакетов".
я как раз поэтой причине и ковырял эту херню, потому что не мог понять как это может в принципе работать. в одной коммерчески используемой системе (хоть убей не помню имени) ковырял. и я там нашел 250MБ имадж с базовой системой, поверх над которой делался chroot для пакета приложения.
поэтому это по большей части просто пиздёж что там *все* в отдельные рандомные каталоги разложено.
как минимум бутстрап, кернел, init, окружение для инита, и манагер пакетов (+ ихние зависимости, что уже 100+МБ с лёгкостью) должны лежать в заранее известных каталогах.
нет, у поттеринга был бы systemd-rmd: демон, слущающий D-Bus, и удаляющий файлы по команде.
Настройка демона хранится по умолчанию в файле
/var/lib/systemd/system/systemd-rmd.unit
и в сорока семи файлах в папке
/etc/systemd/system/systemd-rmd.unit.d
редактировать файлы напрямую не рекомендуется, нужно использовать утилиты.
Допустим, чты хочешь, чтобы rm не удалял корень.
Тогда появится файл
/etc/systemd/system/systemd-rmd.unit.d/199-systemd-rmd-preserve-root.conf
с небольшим JSONом внутри, в котором будет зашифрована эта команда
Сколько бы вы меня не меряли, последнее слово (предсмертный бред) будет за инкубаторами. Ваши жалкие потуги по изобретению вакцины напоминают попытку затащить папу-Кролика в загс.
Ты же не будешь пытаться запустить pkgsrc на centos, а rpm на solaris?
найти rpm sources верно
Ты когда патчи тестируешь, тоже rpm-ки всегда собираешь? Системный софт это одно, а локальная помоечка — совсем другое.
Она же не все ОС поддерживает, верно?
Суть не в этом. Сорцы уровнем ниже, чем пакетный менеджер, они в принципе должны быть независимы от пакетного менеджера.
Суть в том, что в никсе вообще не может быть никакого "/usr/bin/sed" или "/usr/bin/python". Вся идея как раз в том, чтобы отказаться от глобального мутабельного стейта.
Разным программам могут быть нужны разные версии python, в никсе они могут сосуществовать, поэтому не понятно, какой из них должен лежать в /usr/bin.
Программы из сорцов в никсе собирают, это обычно делается примерно следующим образом: ты пишешь default.nix, в котором описано всё, что тебе нужно, чтобы собрать программу (sed, make, вот это всё). Потом ты вызываешь nix-shell, который открывает тебе шелл, в котором есть ровно то, что ты попросил, и ничего больше. Там ты можешь выполнить билд (make velik / cabal new-build velik /dune velik.exe) и поиграться с результатами. См. пример [1].
Такие окружения полностью герметичны и воспроизводимы, не то что всякие "virtualenv".
К сожалению, нужно таки писать default.nix. С другой стороны, если ты патчишь эрланг, можно написать один раз и накопипастить готовых определений.
[1] https://ariya.io/2016/06/isolated-development-environment-using-nix
не совсем сорцы, а скорее autoтулз (ну или чем там он собирает).
Вот аутотулз умеют такие unix, которые имеют в пасе sed и mkdir (и мне кажется что того требует позикс, не?).
А никс не умеют.
А описанная тобою проблема с питонами решается докером, нет разве?
Да, докер является одним из решений.
аутосамзнаешькто стали дефакто в мире GNU (и еще много где) и они поддерживают многие ОС, и авторы софта сами создают эти ваши ./configure.
Dockerfile тоже почти что дефакто, а .nix файлы -- нет.
Отсюда и все проблемы.
Скажем, у бзды тоже кастомные сборки (порты) но там есть спец люди (портеры) которые этим занимаются.
autotools пытается угадать, что где лежит, многие зависимости опциональны. Завязывать сборку какого-нибудь ынтерпрайзного софта на autotools -- это самоубийство.
> дефакто в мире GNU
В мире GNU происходит много чего.
> но там есть спец люди (портеры) которые этим занимаются.
в nix тоже есть спец-люди, просто если ты сам что-то новое пилишь или сидишь в ынтерпрайзе, то писать надо тебе.
Там все ставится из дерева портов и всегда работает
Там вообще нет никаких деревьев и портов.
Умножь на джва стека (IPv4 и IPv6).
Можно поставить «DDP» (на свалке ещё можно найти драйвер этого протокола, но только для старых версий «Windows», потому что даже компания «Apple» перешла на «TCP» и «UDP»).
Ещё с портами есть Datagram Congestion Control Protocol (DCCP) и Stream Control Transmission Protocol (SCTP), но в дикой природе их увидеть сложно, потому что не все маршрутизаторы догадываются о том, что кроме «TCP», «UDP» поверх «IPv4» и «IPv6» ещё что-то может быть.
Хотя на сервер `NixOS' и интересно было бы вкатить.
ахахахахах
зы: аутолулз не нужен
В нём каталоги с программами выглядят, как winsxs?
командой, исполняемой программой или пакетным файлом.
Вставил батарейки, и работает. И никакого блядь тебе rm
> # ./configure: line 196: touch: command not found
либо chroot поломали (если он используется), либо $PATH кто-то грохнул (`env -`?).
на практике видел и первое и второе.
@
сразу отвечай
знаешь что такое NixOS?
"каждый апп в своем пакете и окружении" относится только к end-user приложениям (e.g. FireFox or OpenOffice). и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС. пакеты с приложениями компилирутся на основе этого базового окружения - и в рантайме приложение им же и пользуется.
новая мода. меня не сильно впечатлило.
ЗЫ немного напомнило старую моду. все недостатки static linking, одновремменно с отсутствием всех преимуществ static linking.
значит, всё таки не читал.ъ
[quote]
NixOS не соответствует стандарту иерархии файловой системы. Единственными исключениями являются symlink /bin/sh для версии bash в менеджере пакетов Nix (например: /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/) и, в то время как у NixOS есть каталог /etc для хранения файлов конфигурации всей системы, большинство файлов в этом каталоге являются символическими ссылками на сгенерированные файлы в /nix/store, такие как /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета.
[/qupte]
>>и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС
ну ты прямо бздёвую бейзсистем описываешь
бсд ставит софт локально.
на таких системах - выплевывается пакет приложения с зависимостями (которые базовая система не предоставляет).
> значит, всё таки не читал.
теперь прочитал. 😉
все равно смысла мало вижу в прочитаном - надо руками щупать.
потому что, например - "Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета." - не имеет никакого смысла. потому что кто-то/что-то должно управлять этими "несколькими версиями пакетов".
я как раз поэтой причине и ковырял эту херню, потому что не мог понять как это может в принципе работать. в одной коммерчески используемой системе (хоть убей не помню имени) ковырял. и я там нашел 250MБ имадж с базовой системой, поверх над которой делался chroot для пакета приложения.
поэтому это по большей части просто пиздёж что там *все* в отдельные рандомные каталоги разложено.
как минимум бутстрап, кернел, init, окружение для инита, и манагер пакетов (+ ихние зависимости, что уже 100+МБ с лёгкостью) должны лежать в заранее известных каталогах.
Доставка по России. Анонимно.
wiistriker@gmail.com
уж rm то могли бы в шелл встроить
чай не 1978-й год
Настройка демона хранится по умолчанию в файле
/var/lib/systemd/system/systemd-rmd.unit
и в сорока семи файлах в папке
/etc/systemd/system/systemd-rmd.unit.d
редактировать файлы напрямую не рекомендуется, нужно использовать утилиты.
Допустим, чты хочешь, чтобы rm не удалял корень.
Нужно дать комманду
$ systemct systemd-rmd options add option preserve-root
Тогда появится файл
/etc/systemd/system/systemd-rmd.unit.d/199-systemd-rmd-preserve-root.conf
с небольшим JSONом внутри, в котором будет зашифрована эта команда