1. bash / Говнокод #25222

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    [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 @Роман

    Запостил: CHayT, 25 Декабря 2018

    Комментарии (39) RSS

    • seo: NixOS is too good for this world, too pure
      Ответить
      • В "Windows" нет никаких "autotools", "opam" и "cabal" и нет никакой компиляции. Именно поэтому я за "Windows".
        Ответить
      • Слушай, ну на никс надо всё ставить через nix, это же очевидно а не с сыруов.

        Ты же не будешь пытаться запустить pkgsrc на centos, а rpm на solaris?
        Ответить
        • Я пытался запустить «rpm» на «Debian». А что делать, если программу удалось скачать только в «rpm»? Правда, уже не помню, что из этого вышло.
          Ответить
        • > Слушай, ну на никс надо всё ставить через nix, это же очевидно а не с сыруов.
          Ты когда патчи тестируешь, тоже rpm-ки всегда собираешь? Системный софт это одно, а локальная помоечка — совсем другое.
          Ответить
          • ну тогда надо признать что аутолулз не поддерживает твою OS

            Она же не все ОС поддерживает, верно?
            Ответить
        • > Ты же не будешь пытаться запустить 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. С другой стороны, если ты патчишь эрланг, можно написать один раз и накопипастить готовых определений.

          [1] https://ariya.io/2016/06/isolated-development-environment-using-nix
          Ответить
          • >>Сорцы уровнем ниже,
            не совсем сорцы, а скорее autoтулз (ну или чем там он собирает).

            Вот аутотулз умеют такие unix, которые имеют в пасе sed и mkdir (и мне кажется что того требует позикс, не?).

            А никс не умеют.

            А описанная тобою проблема с питонами решается докером, нет разве?
            Ответить
            • > решается докером

              Да, докер является одним из решений.
              Ответить
              • Полагаю что проблема вот в чем: нужно решение де-факто для декларирования нужного окружения, и тогда весь софт будет его поддерживать

                аутосамзнаешькто стали дефакто в мире GNU (и еще много где) и они поддерживают многие ОС, и авторы софта сами создают эти ваши ./configure.

                Dockerfile тоже почти что дефакто, а .nix файлы -- нет.

                Отсюда и все проблемы.

                Скажем, у бзды тоже кастомные сборки (порты) но там есть спец люди (портеры) которые этим занимаются.
                Ответить
                • Идеология разная.

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

                  > дефакто в мире GNU

                  В мире GNU происходит много чего.
                  https://www.gnu.org/software/guix/


                  > но там есть спец люди (портеры) которые этим занимаются.

                  в nix тоже есть спец-люди, просто если ты сам что-то новое пилишь или сидишь в ынтерпрайзе, то писать надо тебе.
                  Ответить
    • Именно поэтому я против ОС.
      Ответить
      • То ли дело программы, запускающиеся сразу из загрузочного сектора или из прошивки ПЗУ.
        Ответить
        • Есть еще промежужужуточные варианты, такие как "BTX client" на "FreeBSD" или "Boot application" в "Windows"
          Ответить
    • Именно поэтому я за 『Gentoo』.
      Ответить
      • Именно поэтому я за 『BSD』.
        Там все ставится из дерева портов и всегда работает
        Ответить
        • Именно поэтому я за 『Windows』.
          Там вообще нет никаких деревьев и портов.
          Ответить
          • Портов в «Windows» как минимум 131070 штук (65535 у «UDP» и 65535 у «TCP»). А деревьев — до 26 штук (по максимальному числу томов).
            Ответить
            • а еще USB порты, COM, LPT, Completion порты, и даже эндпоинты
              Ответить
            • Правильное примечание про «как минимум».

              Умножь на джва стека (IPv4 и IPv6).

              Можно поставить «DDP» (на свалке ещё можно найти драйвер этого протокола, но только для старых версий «Windows», потому что даже компания «Apple» перешла на «TCP» и «UDP»).

              Ещё с портами есть Datagram Congestion Control Protocol (DCCP) и Stream Control Transmission Protocol (SCTP), но в дикой природе их увидеть сложно, потому что не все маршрутизаторы догадываются о том, что кроме «TCP», «UDP» поверх «IPv4» и «IPv6» ещё что-то может быть.
              Ответить
    • А ты что думал, для всего теперь деривейшены писать надо.
      Ответить
      • А если создать директорию /bin и посимлинкать в неё все программы?
        Ответить
      • Для админов может это и хорошо, что можно админить не вынимая руки из жопы, ибо всё легко откатить. Но для девелоперов такая жизнь боль: у меня одних эрлангов локально стоит штук семь, разных версий и с разными патчсетами, с деревяшными такое собирать с ума сойдёшь.
        Хотя на сервер `NixOS' и интересно было бы вкатить.
        Ответить
    • В нём, как в Винде, каждая программа хранится в своём каталоге? А чтобы можно было запустить, не указывая путь, раздувается PATH?
      Ответить
    • >>mkdir not found
      ахахахахах

      зы: аутолулз не нужен
      Ответить
      • Прочитал про эту фигню...
        /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/

        В нём каталоги с программами выглядят, как winsxs?
        Ответить
      • "rm" не является внутренней или внешней
        командой, исполняемой программой или пакетным файлом.
        Ответить
        • Вот по этому я за `busybox'
          Ответить
          • Вот именно как раз поэтому я против компутеров.
            Ответить
            • я тоже по этому за brick game.
              Вставил батарейки, и работает. И никакого блядь тебе rm
              Ответить
    • > # ./configure: line 195: rm: command not found
      > # ./configure: line 196: touch: command not found

      либо chroot поломали (если он используется), либо $PATH кто-то грохнул (`env -`?).

      на практике видел и первое и второе.
      Ответить
      • тред не читай
        @
        сразу отвечай

        знаешь что такое 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+МБ с лёгкостью) должны лежать в заранее известных каталогах.
              Ответить

    Добавить комментарий