The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлена концепция дистрибутива AerynOS с обоснованием архитектурных решений

22.05.2025 13:47

Разработчики AerynOS, ранее известного как SerpentOS, опубликовали развёрнутую статью, в которой раскрываются детали концепции и технической реализации проекта с обоснованием принятых архитектурных решений. Руководитель проекта Ikey Doherty подчёркивает, что AerynOS - это не просто "ещё один дистрибутив Linux", а платформа, фундамент и набор инструментов, созданные в соответствии с чётким видением.

Основная идея проекта сформулирована в виде вопроса: "Что, если операционная система будет вести себя как современная инфраструктура?". AerynOS представлен как ответ на этот вопрос - система, построенная с нуля, а не следующая традиционной модели встроенных мутаций внутри дистрибутива. Проект опирается на опыт авторов в разработке других дистрибутивов, включая Solus и Clear Linux.

Среди ключевых технических решений AerynOS можно выделить:

  • Использование инструментария LLVM вместо GNU, с применением libc++ и compiler-rt по умолчанию. Разработчики объясняют это решение не просто предпочтением LLVM, а стратегическим выбором для использования более качественной диагностики, обеспечения корректности и переносимости пакетов. При этом система использует glibc вместо musl, что является осознанным выбором в пользу совместимости и производительности.

    Как указано в статье: "Преимущество glibc над musl в производительности хорошо задокументировано, особенно для вычислительно-интенсивных рабочих нагрузок и приложений, требующих оптимальной производительности многопоточности". Создатели подчёркивают, что их цель - построить работоспособную, пригодную для использования систему для множества сценариев применения.

  • Концепция "statelessness" (без сохранения состояния) - пакетам запрещено содержать какие-либо файлы за пределами каталога /usr. Как поясняют разработчики, этот подход заставляет обеспечивать разумные значения по умолчанию на всех уровнях и устраняет "ужасные конфликты трёхстороннего слияния при обновлении пакетов". Конфликтов нет, потому что всё в /etc и /var принадлежит пользователю, а /usr - исключительно системе. Концепция была разработана во времена Clear Linux и Solus, а в AerynOS она получила дальнейшее развитие.
  • Атомарные обновления - каждая транзакция moss является атомарной. Система быстро создаёт новое дерево /usr с использованием жёстких ссылок из дедуплицированного кэша. После успешного создания и подготовки новое дерево атомарно подменяется. Фактически подготовленная транзакция обменивается с реальным каталогом /usr с использованием renameat2 с флагом RENAME_EXCHANGE. Обновление либо выполняется полностью, либо не выполняется вообще, без промежуточных состояний.
  • Управление загрузкой на основе проектов blsforme и disks-rs. Особенность подхода в том, что система динамически формирует параметры для командной строки ядра, считывая суперблоки устройств корневой файловой системы, поэтому в AerynOS нет конфигурационного файла, содержащего параметр "root=". Более того, идентификатор транзакции moss кодируется в командной строке ядра и обрабатывается во время ранней загрузки в initramfs. "Если говорить коротко, это означает, что каждое ядро правильно синхронизировано с соответствующей корневой файловой системой, и откат является дешёвым, простым и доступным прямо из меню загрузки", - поясняют разработчики. Ещё одно преимущество - отсутствие /etc/default/grub, а если ESP будет стёрт, moss может восстановить его с нуля.
  • Формат пакетов .stone - собственный бинарный формат пакетов с версионно-агностическим заголовком для обеспечения будущих изменений. Каждый пакет .stone содержит четыре конкретных типа данных (payload), каждый из которых может развиваться независимо благодаря версионированию:
    • Контентная нагрузка (Content payload) - последовательный блок дедуплицированных данных, то есть само содержимое файлов пакета.
    • Индексная нагрузка (Index payload) - содержит смещения для контентной нагрузки, проиндексированные по хешу XXH128 содержимого (планируется переход на Blake3). Это позволяет эффективно находить и извлекать данные.
    • Нагрузка макета (Layout payload) - описывает предполагаемый макет файловой системы при применении пакета, то есть куда и какие файлы должны быть установлены.
    • Метаданные (Metadata payload) - последовательность строго типизированных, помеченных записей метаданных, таких как имя пакета, предоставляемые возможности и т.д.

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

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

Ещё одно интересное пояснение касается неизменяемости (immutability). Создатели отмечают, что часто AerynOS описывают как неизменяемую ОС, но "это не совсем верно". Хотя каждая транзакция приводит к новому дереву /usr и локальные изменения не сохраняются, система не является неизменяемой в смысле доступа только для чтения. В будущем планируется реализация истинной неизменяемости системы без необходимости перезагрузки с использованием erofs и overlayfs.

В настоящее время AerynOS активно развивается, уже выпускает ISO-образы с окружением GNOME, пригоден для игр (поддержка драйверов NVIDIA, Steam, Flatpak), имеет реальных пользователей, отмечающих стабильность и инновационность системы. По словам разработчиков, проект находится в стадии альфа-версии и не лишён проблем, но уже представляет собой целостную систему, которая "просто работает".

  1. Главная ссылка к новости (https://aerynos.com/blog/2025/...)
  2. OpenNews: Опубликован AerynOS 2025.03, первый выпуск после переименования Serpent OS
  3. OpenNews: Дистрибутив Serpent OS переименован в AerynOS
  4. OpenNews: Дистрибутив Solus 5 будет построен на технологиях SerpentOS
  5. OpenNews: Serpent OS переходит на применение языков Rust, TypeScript и Go в инструментарии и инфраструктуре
  6. OpenNews: Дистрибутив Serpent OS перешёл на стадию альфа-тестирвания
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/63285-aerynos
Ключевые слова: aerynos, serpentos
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, тоже Аноним (ok), 14:54, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Чертежи воздушных замков всегда идеальны.
    Но в IT идея и концепция ничего не стоят, значение имеет - реализация.
     
     
  • 2.10, Аноним (10), 15:03, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Чертежи воздушных замков всегда идеальны.

    Как говорится, красиво было на бумаге, но забыли про овраги...

     
  • 2.17, Аноним (17), 15:09, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Именно в ИТ идея и концепция чего-то стоят. Например, дидам в башку взбрендило как-то раз: а давайте строка "0x7f.1" должна парситься так же, как "127.0.0.1"! Шальная башка дидов породила такую незатейливую идейку, а страдать всем остальным: теперь вообще каждое приложение, конвертирующее строку в IP-адрес, должно это учитывать. Хотя по факту это пригодилось лишь однажды -- в самом RFC, чтоб показать, какая пРиКоЛьНаЯ))) идея.
     
     
  • 3.33, тоже Аноним (ok), 16:43, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то это как раз пример реализации.
    Пацак говорит на языках, окончания которых не знает.
     
  • 3.34, Аноним (34), 16:46, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что стандартизаторы - главные враги, давно не новость.
     
  • 3.58, Аноним (58), 18:30, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А что не так? Может ты просто веб-амкака или раста-писака?

    0x7f - это 127 в hex.
    1 - это 1 в hex.

    127.0.0.1 == 127.1 == 0x7f.1

    нули между ненулевыми октетами опущены для кратности, прям как в ipv6.

    О! Я понял! Дидам не только это в башку взбрендило, а еще что строка "0xc0.0xa8.1" должна парситься так же, как "192.168.0.1"

     
     
  • 4.69, Аноним (69), 19:15, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > 0x7f - это 127 в hex

    Думаешь, для меня это было секретом? Речь про валидирование и парсинг строки. Он неоправданно сложен для задачи вида "считать четыре байта из human-friendly строкового представления". И валидация везде реализована частично. Видал требование писать данные строго по паспорту, в том числе капсом, если в паспорте капс? Потому что учреждениям нет времени сидеть различать ИГОРЬ от Игорь от игорь от Игоречек от Игорямба, хотя это по сути "одно и то же имя", по твоей логике. Но с точки зрения strcmp это разные имена.

     
     
  • 5.73, Аноним (58), 19:22, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Речь про валидирование и парсинг строки

    Только в случае с 0x7f.1 или остальные 4 млрд комбинаций тоже?

     
  • 5.77, Аноним (58), 19:28, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Речь шла про то, что какие-то мифические диды придумали, что именно "0x7f.1" должна парситься как "127.0.0.1". А теперь пошли какие-то паспорты, капсы, ИГОРИ, strcmp().
     
  • 5.92, Аноним (92), 22:16, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    0x7f легко конвертируется в бинарное (физически существующее) представление.
    0x7f.1 это 1 хост в сети 0x7f. Что сложного и нелогичного?
    Вам трудно парсить с помощью Union (объединение) в Си?
     
  • 4.78, anonymous (??), 19:51, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > строка "0xc0.0xa8.1" должна парситься так же, как "192.168.0.1"

    А почему не 192.0.168.1

    Идея пропускать нулевые актеты - очень нездравая и способствует возникновению ошибок

     
  • 4.87, Илья (??), 21:31, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >А что не так?

    То, что половина парсеров не поддерживает шестнадцатеричный формат.

     
     
  • 5.94, Аноним (92), 22:19, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Скоро и двоичное отменят? Абстрагируемся полностью от реальности.
     
  • 3.79, Аноним (79), 19:53, 22/05/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.81, Аноним (81), 20:45, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    "В IT идея ничего не стоит" на самом деле такое предвзятое отношение к концептуализму не только в IT, такое отношение присутствует везде и всюду, многие не понимают что хорошо спроектированная и достаточно реалистично спланированная конепция порой может иметь высокий потенциал воплощения и реализации но многие привыкли к этому относиться как к чему то воздушному, я понимаю почему но не стоит отменять тот факт что выстраивание концепций своего рода отдельное направление которым порой занимаются разные люди в разных сферах, где то это находит больше смысла как например в граф дизайне (ибо легче воплотить и показать наглядно)
     

  • 1.2, Анониматор (?), 14:55, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    почему-то все их архитектурные обоснования читаются как наброс на вентилятор
     
     
  • 2.21, fidoman (ok), 15:21, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Когда знаний мало, зато идей много.
     

  • 1.4, Аноним (4), 15:01, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > всё в /etc и /var принадлежит пользователю, а /usr - исключительно системе.

    usr от слова user? И там будет всё только системное? А логика в каком каталоге лежит?

     
     
  • 2.7, Аноним (7), 15:02, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Давно бы сделали program files, user, etc...
     
     
  • 3.12, Аноним (10), 15:04, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Давно бы сделали program files, user, etc...

    Так сделали уж давно. Корпорация майкрософт. Правда, их посетила ровно та же проблема - и определиться где и что хранить? Вот так сразу? Ага, сейчас, поэтому переделывали раз наверное пять суммарно.

     
  • 3.18, НяшМяш (ok), 15:15, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Тогда уж как в макоси - /Applications, /User, /System, /Volumes и т.д.
     
     
  • 4.35, Аноним (34), 16:47, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но ведь это же х*рь.
     
     
  • 5.38, Аноним (38), 17:00, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ровно такая же произвольно выбранная, как и FHS, но у макос хотя бы человекочитаемые названия выбрали, а не этот птичий язык для экономии букв.
     
  • 4.44, Аноним (44), 17:26, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит Волумеы в данном контексте? Тома?
     
  • 4.56, Аноним (56), 18:20, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >/Applications, /User, /System, /Volumes

    Интересно, как с этим вот МакОСь получила сертификат UNIX (TM) ?

     
     
  • 5.71, Аноним (71), 19:15, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Заплатила деньги
     
  • 5.76, Аноним (38), 19:26, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А они «юниксовую» иерархию поддерживают. Просто не завязывают свои компоненты на эту лажу прямиком из 70х. Для UNIX/POSIX сертификации в корыто наплескали чего требуется по регламенту, а для приличных людей в другом месте аккуратно всё разложено.
     
  • 3.42, ГурренЛаганн (?), 17:15, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    так GoboLinux же
     
  • 2.43, Аноним (43), 17:24, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > usr от слова user? И там будет всё только системное? А логика в каком каталоге лежит?

    C:\Program Files\

     
  • 2.45, Аноним (45), 17:29, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Unix System Resources.
    Т.е. то, что вне минимальной "базы".
    Для ползователя делались и /usr/local и /opt, но этим всё неймётся.
     
     
  • 3.59, Аноним (59), 18:41, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ой, usr всё гораздо интересней https lists busybox net pipermail busybox 201... большой текст свёрнут, показать
     

  • 1.6, Аноним (7), 15:01, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уважаемые коллеги, анонимные эксперты, напомните какой из дистрибутивов наиболее похож на FreeBSD? Gentoo или я ошибаюсь?
     
     
  • 2.27, Аноним (27), 15:52, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Уважаемые коллеги, анонимные эксперты, напомните какой из дистрибутивов наиболее похож
    > на FreeBSD? Gentoo или я ошибаюсь?

    Системой управления пакетами - да.

     
  • 2.36, Аноним (36), 16:54, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Void Linux. Он создавался как раз для откатки отдельных решений.
    Gentoo похож только если вы используете сырцы. Но заниматься ЭТИМ на Фряхе... месье знает толк в извращениях!
     
     
  • 3.49, Афроним (?), 17:47, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Фряха это еще и src,неужели ядро не настраивали?
     
  • 3.67, Аноним (67), 19:06, 22/05/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.48, Афроним (?), 17:43, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я ошибаюсь - тоже цельная система. Вот только гламурный я ошибаюсь еще более похож на Фряху.
     
  • 2.60, Аноним (58), 18:51, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Даже близко не генту (у нее пакетный менеджер на питоне). Самый близкий по философии/духу/итп - это crux
     
  • 2.66, Аноним (67), 19:04, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >наиболее похож на FreeBSD? Gentoo или я ошибаюсь?

    Скорее NetBSD.
    Естественно, если мы подразумеваем пакетный менедже pkg_ng, а не систему портов.

     

  • 1.19, Аноним (19), 15:19, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Использование инструментария LLVM вместо GNU

    Странно но ладно.

    > пакетам запрещено содержать какие-либо файлы за пределами каталога /usr

    Ой все!

     
     
  • 2.65, Аноним (67), 19:01, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> пакетам запрещено содержать какие-либо файлы за пределами каталога /usr
    >Ой все!

    Ну ты же понимаешь, что наконец то кто-то им показал FreeBSD.

     

  • 1.20, fidoman (ok), 15:21, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > каждое ядро правильно синхронизировано с соответствующей корневой файловой системой

    что там синхронизировать кроме /lib/modules? Которое и так распедалено в соответствии с версией ядра.
    Или там такая макаронина, что стоит загрузить не то ядро и всё, системе кирдык?

     
     
  • 2.64, Аноним (67), 18:59, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >стоит загрузить не то ядро и всё, системе кирдык

    ты смотришь прям в суть.
    Теперь понимаешь, почему они занялись своей оптимизацией?

     

  • 1.24, Аноним (-), 15:32, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Они идут по стопам GoboLinux, GNU Guix System, NixoS?
     
     
  • 2.37, Аноним (36), 16:55, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее по пути Solus и ClearLinux :D
     

  • 1.28, Аноним (92), 15:53, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очередная фантазия о будущем на публику. Причем будущее завуалированно для публики.
     
     
  • 2.40, Аноним (40), 17:01, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В будущих десктопных андроидах будет все применено.
     
     
  • 3.82, Аноним (92), 21:17, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ассемблер будет забыт. Предлагаю посмотреть, что делает компилятор GCC над кодом.
    void foo3(int a, int b, int c){
      printf("%d %d %d",a,b,c);
      return;
    }
    int main(){
      int a,b,c;
      foo3(a,b,c);
    }
    main перед вызовом foo3:
    mov -0xc(%rbp),%edx ; c
    mov -0x8(%rbp),%ecx ; b
    mov -0x4(%rbp),%eax ; a
    mov %ecx,%esi ; кто скажет зачем?
    mov %eax,%edi ; кто скажет зачем?
    call xx ; call foo3

    Далее в foo3:
    mov %edi,0x4(%rbp) ; a to auto frame
    mov %esi,0x8(%rbp) ; b to auto frame
    mov %edx,0xc(%rbp) ; c to auto frame
    mov -0xc(%rbp),%ecx ; чтобы ecx было как в учебниках
    mov -0xc(%rbp),%edx ; чтобы edx было как в учебниках
    mov -0xc(%rbp),%eax ; чтобы eax было как в учебниках

    Если параметров будет 6, например, будет ещё веселее?

     
     
  • 4.83, Аноним (92), 21:19, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Поправка:
    mov -0xc(%rbp),%ecx ; чтобы ecx было как в учебниках
    mov -0x8(%rbp),%edx ; чтобы edx было как в учебниках
    mov -0x4(%rbp),%eax ; чтобы eax было как в учебниках
     
  • 4.93, Аноним (93), 22:18, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > кто скажет зачем?
    > чтобы ecx было как в учебниках

    параметры передаются через rdi, rsi, rdx и rcx. Вроде такое соглашение о вызове на x86_64 в 64-битном режиме.
    По этой же причине в foo3 компилятор перекладывает все параметры чтобы освободить rdi для указателя на шаблон
    > Если параметров будет 6, например, будет ещё веселее?

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

    причина упоминания учебников не понятна — раз от компилятора не запросили оптимизацию, то он ее и не делал

     
     
  • 5.95, Аноним (92), 22:25, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если 6 параметров то будет 5 повторных перекладываний регистров. Проверти. Например, r8d в r9d.  
    Порядок приема переменных в подпрограммах через регистры описывается в книгах.
     
     
  • 6.96, Аноним (93), 22:40, 22/05/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.29, Аноним (38), 15:53, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Годно, но опоздали на десять с гаком лет. До тотальной контейнеризации было актуально, а сейчас без разницы на чём distroless контейнеры крутить. ОС на сервере практически и так уже неизменная с минимумом настроек, и поставить её с нуля всегда быстрее, чем чинить или из бэкапа восстанавливать.
     
     
  • 2.46, Аноним (44), 17:30, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну всё же выбирают Alpine Linux для контейнеризации.
     
     
  • 3.53, Аноним (53), 18:06, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Только те, кому не важен перформанс и поддержка gettext с локалями, а почему-то важен размер образа на диске.
     
  • 3.72, Аноним (38), 19:18, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто-то выбирает, кому-то musl убивает производительность, а кому-то и вовсе местный аналог NSA спускает указиловку как правильно готовить клауд.
     

  • 1.31, инновации в орнитологических хозяйствах (?), 16:24, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну, наконец-то чёткое видение и современная инфраструктура. Этого очень сильно не хватало все эти десятилетия. Но теперь дело сдвинется с мёртвой точки. Процесс запустится. Закрутятся колёсики в колёсиках. А там недалеко уже и до Победы.
     
  • 1.32, Аноним (32), 16:29, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >отказ от встроенных изменений в пользу декларативного подхода, подобного Gentoo или Nix.

    Ахах, я ждал, когда они это поймут. На это ушел год. Хорошо, что поняли. Ждём, что года через 2 поймут, что иммутабельность и возпроизводимость невозможно (математически) обеспечить на императивном ЯП и перейдут на хацкель или nix.

    Тугодумы, конечно, но учатся.

     
     
  • 2.63, Аноним (67), 18:55, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Предположи, когда они захотят все переписать на Раст?
     

  • 1.39, Аноним (40), 17:00, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    За такой архитектурой будущее.
     
  • 1.50, Zulu (?), 17:49, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда OpenSolaris был в стадии проектирования, pkg планировался как immutable. Никаких скриптов вообще, пакет может деливернуть файл, или каталог, или ссылку, или манифест сервиса.

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

     
     
  • 2.52, Аноним (32), 17:54, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это откуда такая странная информация?
     
     
  • 3.84, Минона (ok), 21:24, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Гопатыча.
     

  • 1.55, YetAnotherOnanym (ok), 18:19, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > всё в /etc и /var принадлежит пользователю, а /usr - исключительно системе

    Главное, чтобы не был нарушен важнейший принцип современного СПО, когда у одной и той же программы часть конфига живёт в /etc, часть - в /usr/local/etc, часть - в /usr/share, часть - в /usr/local/share часть - в /usr/lib, часть - в /usr/local/lib, часть - в /var/lib, часть - в /var/db, часть - в ~/.appname, и чтобы в каждой новой версии менялись приоритеты кто кого оверрайдит.

     
     
  • 2.62, Аноним (67), 18:52, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты еще забыл принцип 1с!
    Класть файлы приложения туда, где их искать никто не догадается.
     
     
  • 3.85, Минона (ok), 21:26, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В папку с БД?
     

  • 1.57, Аноним (56), 18:29, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ~/.appname

    ~/.config/appname по современному феншую

     
  • 1.61, Аноним (67), 18:51, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Формат пакетов .stone

    а чем их существующие форматы пакетов не устраивают?
    тем что написаны не ими?
    зачем плодить зоопарк пакетов?

     
     
  • 2.70, Аноним (70), 19:15, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > зачем плодить зоопарк пакетов?

    Т.е плодение зоопарка дистров у вас вопросов не вызывает?

     
     
  • 3.86, Аноним (92), 21:28, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Дистрибутив собирается под нужды клиента. А пакет зачем?  
     

  • 1.68, Аноним (70), 19:14, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Ikey Doherty подчёркивает, что AerynOS - это не просто "ещё один дистрибутив Linux"
    > Проект опирается на опыт авторов в разработке других дистрибутивов, включая Solus и Clear Linux.

    Ну да, это не просто еще один дистрибутив, это уже третий "не просто еще один дистрибутив"!

    И на полном же серьезе это пишут...

     
  • 1.74, Аноним (70), 19:22, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Руководитель проекта Ikey Doherty подчёркивает, что AerynOS - это не просто "ещё один дистрибутив Linux"

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

    Не просто "еще один дистрибутив", ага...

     
  • 1.75, Аноним (75), 19:24, 22/05/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     
  • 1.80, Аноним (80), 20:04, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вот прочитал новость, прочитал внимательно, и...

    И не обнаружил ничего нового и киллерфичастого кроме разве что симптомов NiH-синдрома и какого-то устойчивого желания от зуда: А давайте сделаем не так как принято, чисто потому что плохо делать так как принято, а у нас лучше, потому что не так, как принято!

    Из этого потока сознания я делаю вывод, что это очередное УГ, просто "чтобы было"!

    На этом фоне не только местами полезный NixOS выглядит весьма себе действительно крутой полезной идеей в некоторых своих аспектах, но и шизанутый GoboLinux имеет больше смысла существовать.

     
     
  • 2.88, Аноним (92), 21:32, 22/05/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз, чтобы не было УГ, надо объявить о Миссионерском или Революционном характере дистрибутива.  
     

  • 1.89, Аноним (92), 21:47, 22/05/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Разработчики AerynOS, ранее известного как SerpentOS"

    А почему переименовались? Стало стыдно за фантазии или кредиторы догоняют?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру