URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 136924
[ Назад ]

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

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

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63285


Содержание

Сообщения в этом обсуждении
"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено тоже Аноним , 22-Май-25 14:54 
Чертежи воздушных замков всегда идеальны.
Но в IT идея и концепция ничего не стоят, значение имеет - реализация.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:03 
> Чертежи воздушных замков всегда идеальны.

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:09 
Именно в ИТ идея и концепция чего-то стоят. Например, дидам в башку взбрендило как-то раз: а давайте строка "0x7f.1" должна парситься так же, как "127.0.0.1"! Шальная башка дидов породила такую незатейливую идейку, а страдать всем остальным: теперь вообще каждое приложение, конвертирующее строку в IP-адрес, должно это учитывать. Хотя по факту это пригодилось лишь однажды -- в самом RFC, чтоб показать, какая пРиКоЛьНаЯ))) идея.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено тоже Аноним , 22-Май-25 16:43 
Вообще-то это как раз пример реализации.
Пацак говорит на языках, окончания которых не знает.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 16:46 
Что стандартизаторы - главные враги, давно не новость.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Илья , 22-Май-25 21:31 
>А что не так?

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 23:15 
А диды тут причем?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 10:10 
>>А что не так?
> То, что половина парсеров не поддерживает шестнадцатеричный формат.

Ничего страшного, ipv6 ты по другому и сам писать не захочешь :)


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Котофалк , 28-Май-25 09:07 
Там в стандарте говорят на ABNF по белому написано, говорят, на любом языке можно получить RFC-корректный парсер, вот так подумали диды. Альтернатива, как я понимаю" - "смузихлёбы не осилили в основном, давайте отломаем". Ну-ну...

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Илья , 01-Июн-25 09:11 
> на любом языке можно получить RFC-корректный парсер, вот так подумали диды.

Давай каждый админ перед тем как распарсить в скрипте "4 цифры через точечку" будет RFC читать?


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено OpenEcho , 23-Май-25 09:21 
> дидам в башку взбрендило как-то раз

А ты кто такой, пыжик?
Давай, колись, чем же ты такой лучше отцов и дедов? Изобретения - в студию !


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 20:45 
"В IT идея ничего не стоит" на самом деле такое предвзятое отношение к концептуализму не только в IT, такое отношение присутствует везде и всюду, многие не понимают что хорошо спроектированная и достаточно реалистично спланированная конепция порой может иметь высокий потенциал воплощения и реализации но многие привыкли к этому относиться как к чему то воздушному, я понимаю почему но не стоит отменять тот факт что выстраивание концепций своего рода отдельное направление которым порой занимаются разные люди в разных сферах, где то это находит больше смысла как например в граф дизайне (ибо легче воплотить и показать наглядно)

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено тоже Аноним , 23-Май-25 12:17 
Процесс выстраивания концепций имеет обязательный этап обстукивания их скорлупы об реальность. MVP там, то-се...
А прекрасные лозунги, еще не подкрепленные практикой реализаций и переделок - это маниловщина, и только.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Анониматор , 22-Май-25 14:55 
почему-то все их архитектурные обоснования читаются как наброс на вентилятор

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено fidoman , 22-Май-25 15:21 
Когда знаний мало, зато идей много.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:01 
> всё в /etc и /var принадлежит пользователю, а /usr - исключительно системе.

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:02 
Давно бы сделали program files, user, etc...

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:04 
> Давно бы сделали program files, user, etc...

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено НяшМяш , 22-Май-25 15:15 
Тогда уж как в макоси - /Applications, /User, /System, /Volumes и т.д.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 16:47 
Но ведь это же х*рь.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:00 
Ровно такая же произвольно выбранная, как и FHS, но у макос хотя бы человекочитаемые названия выбрали, а не этот птичий язык для экономии букв.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:26 
Что значит Волумеы в данном контексте? Тома?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:20 
>/Applications, /User, /System, /Volumes

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:15 
Заплатила деньги

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:26 
А они «юниксовую» иерархию поддерживают. Просто не завязывают свои компоненты на эту лажу прямиком из 70х. Для UNIX/POSIX сертификации в корыто наплескали чего требуется по регламенту, а для приличных людей в другом месте аккуратно всё разложено.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено ГурренЛаганн , 22-Май-25 17:15 
так GoboLinux же

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:24 
> usr от слова user? И там будет всё только системное? А логика в каком каталоге лежит?

C:\Program Files\


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:29 
Unix System Resources.
Т.е. то, что вне минимальной "базы".
Для ползователя делались и /usr/local и /opt, но этим всё неймётся.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:41 
Ой, /usr всё гораздо интересней.
https://lists.busybox.net/pipermail/busybox/2010-December/07...

You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?  
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one, which is where all the
user home directories lived (which is why the mount was called /usr).  They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and
wrote files to those new directories because their original disk was out of
space.  When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

А дальше ещё большее велосипедостроение.


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:01 
Уважаемые коллеги, анонимные эксперты, напомните какой из дистрибутивов наиболее похож на FreeBSD? Gentoo или я ошибаюсь?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:52 
> Уважаемые коллеги, анонимные эксперты, напомните какой из дистрибутивов наиболее похож
> на FreeBSD? Gentoo или я ошибаюсь?

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 16:54 
Void Linux. Он создавался как раз для откатки отдельных решений.
Gentoo похож только если вы используете сырцы. Но заниматься ЭТИМ на Фряхе... месье знает толк в извращениях!

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Афроним , 22-Май-25 17:47 
Фряха это еще и src,неужели ядро не настраивали?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:06 
первое, что делаю после установки FreeBSD - собираю свое собственное оптимизированное под мое железо ядро.
пользоваться дженериковским - обычно моветон. Можно и дженериковское, но лучше свое.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Ivan_83 , 23-Май-25 08:49 
Это хорошо когда у вас дома только один компьютер.
Когда компьютеров пачка, да ещё и железо там разное то -march=native доставляет сплошные неудобства, не давая при этом видимых результатов.

А GENERIC конфиг - да, фигня полная, как и набор халама который собирается в систему по дефолту. Как минимум OpenSSH и unbound удобнее из портов ставить.


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Афроним , 22-Май-25 17:43 
Я ошибаюсь - тоже цельная система. Вот только гламурный я ошибаюсь еще более похож на Фряху.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:51 
Даже близко не генту (у нее пакетный менеджер на питоне). Самый близкий по философии/духу/итп - это crux

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:04 
>наиболее похож на FreeBSD? Gentoo или я ошибаюсь?

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:19 
> Использование инструментария LLVM вместо GNU

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

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

Ой все!


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:01 
>> пакетам запрещено содержать какие-либо файлы за пределами каталога /usr
>Ой все!

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено fidoman , 22-Май-25 15:21 
> каждое ядро правильно синхронизировано с соответствующей корневой файловой системой

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:59 
>стоит загрузить не то ядро и всё, системе кирдык

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:32 
Они идут по стопам GoboLinux, GNU Guix System, NixoS?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 16:55 
Скорее по пути Solus и ClearLinux :D

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:53 
Очередная фантазия о будущем на публику. Причем будущее завуалированно для публики.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:01 
В будущих десктопных андроидах будет все применено.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 21:17 
Ассемблер будет забыт. Предлагаю посмотреть, что делает компилятор 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, например, будет ещё веселее?


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 21:19 
Поправка:
mov -0xc(%rbp),%ecx ; чтобы ecx было как в учебниках
mov -0x8(%rbp),%edx ; чтобы edx было как в учебниках
mov -0x4(%rbp),%eax ; чтобы eax было как в учебниках

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 22:18 
> кто скажет зачем?
> чтобы ecx было как в учебниках

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

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

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 22:25 
Если 6 параметров то будет 5 повторных перекладываний регистров. Проверти. Например, r8d в r9d.  
Порядок приема переменных в подпрограммах через регистры описывается в книгах.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 22:40 
> Если 6 параметров то будет 5 повторных перекладываний регистров. Проверти. Например, r8d в r9d.

так в чем проблема и как это относится к "что делает компилятор GCC над кодом"? Какие у него варианты без указания -O?
как это связано с тем, что "Ассемблер будет забыт"?
Порядок должен соблюдаться иначе можно словить удивительные спецэффекты при вызове функции их другого места. У компилятора есть некоторые возможности для оптимизаций, но тут их никто не запрашивал.
> Порядок приема переменных в подпрограммах через регистры описывается в книгах.

и меняется от компилятора к компилятору, от архитектуры к архитектуре… В т.ч. в некоторой степени зависит от хотелок программиста


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 02:07 
Проблема, что это неожиданно и не объяснимо (в частности Вами). Есть ABI SystemV по которому порядок передачи параметров через регистры rdi,rsi,rdx,rcx,r8,r9. Почему GCC сразу не помещает фактические параметры в нужный регистр и потом сразу извлекает в auto. Он компилирует так, чтобы первый параметр в asm вставки находился в eax, второй - в edx, третий - в ecx, и т.д.? Получаются лишние инструкции и чем больше параметров, тем больше лишних инструкций. В rust вроде нет. auto frame относительно rsp. Я пробовал с различными оптимизациями - все так же.
Ассемблер будет забыт, в смысле. а кто обращает внимание на фактический код?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 10:28 
> Почему GCC сразу не помещает фактические параметры в нужный регистр и потом сразу извлекает в auto.

Потому что не было запроса на оптимизацию (-O, -O1, -O2, …) и он сделал "в лоб" с учетом каких-нибудь особенностей древних процессоров, например где перекладывание в edi через eax требовало меньше тактов, чем напрямую из памяти.
> Получаются лишние инструкции и чем больше параметров, тем больше лишних инструкций

они всегда получаются — при чем у разных программистов разные
> Ассемблер будет забыт, в смысле. а кто обращает внимание на фактический код?

какой смысл обращать внимание на фактический код
1. до компиляции с -O2 например? Ну посмотрели мы тут на перекладывание чего-то куда-то, а с -O2 компилятор решил, что перекладывать не интересно и заинлайнил foo3
2. до запуска профилирования? Это у нас точно основное проблемное место?

> В rust вроде нет. auto frame относительно rsp. Я пробовал с различными оптимизациями - все так же.

не знаю насколько можно сравнивать тот пример, что вы привели, с тем который не привели, но a, b и c не заданы и за счет этого развлекаются что gcc, что clang.
я не умею писать на расте, не знаю, получилось ли похоже


fn foo3(a: i32, b: i32, c: i32) {
    println!("{} {} {}", a, b, c);
}

pub fn main() {
    let a: i32 = 1;
    let b: i32 = 1;
    let c: i32 = 1;
    foo3(a, b, c);
}


но без оптимизации оно там генерирует как-то так. При чем объем кода меняется от версии к версии и не всегда в меньшую сторону

example::foo3:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 240
        lea     rax, [rbp - 152]
        lea     rcx, [rbp - 12]
        lea     r8, [rbp - 8]
        lea     r9, [rbp - 4]
        mov     dword ptr [rbp - 4], edi
        mov     dword ptr [rbp - 8], esi
        mov     dword ptr [rbp - 12], edx
        mov     r10, qword ptr [rip + example::foo3::__STATIC_FMTSTR]
        mov     qword ptr [rbp - 80], r10
        mov     r10, qword ptr [rip + example::foo3::__STATIC_FMTSTR+8]
        mov     qword ptr [rbp - 72], r10
        mov     rsi, qword ptr [rbp - 80]
        mov     rdx, qword ptr [rbp - 72]
        mov     qword ptr [rbp - 152], r9
        mov     qword ptr [rbp - 144], r8
        mov     qword ptr [rbp - 136], rcx
        mov     rcx, rax
        add     rcx, 8
        mov     r8, rax
        add     r8, 16
        mov     qword ptr [rbp - 192], r8
        mov     qword ptr [rbp - 176], rcx
        mov     qword ptr [rbp - 160], rax
        mov     qword ptr [rbp - 224], rsi
        mov     qword ptr [rbp - 232], rdx
        mov     rdx, qword ptr [rip + core::fmt::num::<impl fmt::Display for i32>::fmt@GOTPCREL]
        lea     rax, [rbp - 128]
        mov     rcx, qword ptr [rbp - 176]
        mov     rcx, qword ptr [rcx]
        mov     qword ptr [rbp - 184], rcx
        mov     rcx, qword ptr [rbp - 160]
        mov     rcx, qword ptr [rcx]
        mov     qword ptr [rbp - 168], rcx
        mov     rcx, qword ptr [rbp - 192]
        mov     rcx, qword ptr [rcx]
        mov     qword ptr [rbp - 200], rcx
        mov     rsi, qword ptr [rbp - 168]
        mov     rdi, rax
        mov     qword ptr [rbp - 240], rax
        call    core::fmt::ArgumentV1::new
        mov     rdx, qword ptr [rip + core::fmt::num::<impl fmt::Display for i32>::fmt@GOTPCREL]
        mov     rax, qword ptr [rbp - 240]
        add     rax, 16
        mov     rsi, qword ptr [rbp - 184]
        mov     rdi, rax
        call    core::fmt::ArgumentV1::new
        mov     rdx, qword ptr [rip + core::fmt::num::<impl fmt::Display for i32>::fmt@GOTPCREL]
        mov     rax, qword ptr [rbp - 240]
        add     rax, 32
        mov     rsi, qword ptr [rbp - 200]
        mov     rdi, rax
        call    core::fmt::ArgumentV1::new
        lea     rdi, [rbp - 64]
        lea     rax, [rbp - 128]
        mov     qword ptr [rbp - 216], rax
        mov     qword ptr [rbp - 208], 3
        mov     rcx, qword ptr [rbp - 216]
        mov     r8, qword ptr [rbp - 208]
        mov     rsi, qword ptr [rbp - 224]
        mov     rdx, qword ptr [rbp - 232]
        call    core::fmt::Arguments::new_v1
        lea     rdi, [rbp - 64]
        call    std::io::stdio::_print@PLT
        add     rsp, 240
        pop     rbp
        ret

example::main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     dword ptr [rbp - 4], 1
        mov     dword ptr [rbp - 8], 1
        mov     dword ptr [rbp - 12], 1
        mov     edi, dword ptr [rbp - 4]
        mov     esi, dword ptr [rbp - 8]
        mov     edx, dword ptr [rbp - 12]
        call    example::foo3
        add     rsp, 16
        pop     rbp
        ret



"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 21:44 
Ладно. Пора завершать. Даже с оптимизацией есть перекладывание значений из регистра в регистр, потому что есть Два этапа - подготовка регистров для работы внутри функции и подготовка регистров для передачи параметров в соответствие с соглашением. Отрабатывают два разных куска кода компилятора. Никто так просто не объяснил.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 24-Май-25 12:18 
Ух ты! Никто мысли читать не умеет. Ну надо же!
Ну что, самоутвердиться, что ты круче писателей стандартов?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 24-Май-25 15:45 
> Даже с оптимизацией есть перекладывание значений из регистра в регистр, потому что есть Два этапа

потому что есть соглащение о вызове и добавить еще один аргумент в начало списка не смещая остальные нельзя
> подготовка регистров для работы внутри функции

нет там никакой "подготовки". Просто регистр нужен "в другом месте" и хранящееся значение куда-нибудь копируется (если оно все еще надо). В зависимости от возможностей для оптимизации и флагов компилятора это может быть сразу подходящий регистр или стек
Не все регистры равнозначны и некоторые переходят на "этап подготовки" каждые пару строк
> Отрабатывают два разных куска кода компилятора

отрабатывают 100500 разных кусков кода, при чем куску из оптимизатора безразлично, что там другой кусок хотел подготовить
> Никто так просто не объяснил.

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Tron is Whistling , 23-Май-25 08:44 
(то есть полноценно все фреймы формируются, вся обёртка, нет переименования регистров и т.п.)

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Tron is Whistling , 23-Май-25 08:43 
Добавьте хотя бы -O, потому что без -O - это "строго по стандарту".

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Tron is Whistling , 23-Май-25 08:44 
Промахнулся выше
(то есть полноценно все фреймы формируются, вся обёртка, нет переименования регистров и т.п.)

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 21:46 
Даже с оптимизацией (исключая явное inline) есть перекладывание значений из регистра в регистр, потому что есть Два этапа - подготовка регистров для работы внутри функции и подготовка регистров для передачи параметров в соответствие с соглашением. Отрабатывают два разных куска кода компилятора. Никто так просто не объяснил.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 15:53 
Годно, но опоздали на десять с гаком лет. До тотальной контейнеризации было актуально, а сейчас без разницы на чём distroless контейнеры крутить. ОС на сервере практически и так уже неизменная с минимумом настроек, и поставить её с нуля всегда быстрее, чем чинить или из бэкапа восстанавливать.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:30 
Ну всё же выбирают Alpine Linux для контейнеризации.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:06 
Только те, кому не важен перформанс и поддержка gettext с локалями, а почему-то важен размер образа на диске.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:18 
Кто-то выбирает, кому-то musl убивает производительность, а кому-то и вовсе местный аналог NSA спускает указиловку как правильно готовить клауд.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 16:29 
>отказ от встроенных изменений в пользу декларативного подхода, подобного Gentoo или Nix.

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

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:55 
Предположи, когда они захотят все переписать на Раст?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 02:18 
В торрентах тоже воспроизводимость, обрабатываются любыми языками.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:00 
За такой архитектурой будущее.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Zulu , 22-Май-25 17:49 
Когда OpenSolaris был в стадии проектирования, pkg планировался как immutable. Никаких скриптов вообще, пакет может деливернуть файл, или каталог, или ссылку, или манифест сервиса.

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 17:54 
Это откуда такая странная информация?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Минона , 22-Май-25 21:24 
Гопатыча.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Zulu , 22-Май-25 22:55 
> Это откуда такая странная информация?

Картинка с Элрондом "I was there, 3000 years ago".

см. PSARC/2008/190 и упомянутые там материалы.


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено YetAnotherOnanym , 22-Май-25 18:19 
> всё в /etc и /var принадлежит пользователю, а /usr - исключительно системе

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:52 
Ты еще забыл принцип 1с!
Класть файлы приложения туда, где их искать никто не догадается.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Минона , 22-Май-25 21:26 
В папку с БД?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Котофалк , 28-Май-25 12:09 
> Главное, чтобы не был нарушен важнейший принцип современного СПО, когда у одной
> и той же программы часть конфига живёт в /etc, часть -
> в /usr/local/etc,

Сапоги всмятку. Конфиги живут в /etc. То, что ты криво собрал ручками может класть конфиги в /usr/local/etc. Так в линуксе.
Во фряхе в /etc/ лежат конфиги из базовой, конфиги прог из пакетов - в /usr/local/etc


> часть - в /usr/share, часть - в /usr/local/share часть

(зевает)

> - в /usr/lib, часть - в /usr/local/lib,

тож самое

> часть - в /var/lib,

/var/lib во фряхе такого нет. Но в FHS оно записано как "/var/lib: Изменяемая информация о состоянии"

там нет конфигов. и если ты туда лезешь править руками, ты делаешь что-то не так.

> часть - в /var/db, часть - в ~/.appname, и чтобы в
> каждой новой версии менялись приоритеты кто кого оверрайдит.

(зевает) ~/.config пропустил.


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:29 
> ~/.appname

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 18:51 
>Формат пакетов .stone

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:15 
> зачем плодить зоопарк пакетов?

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 21:28 
Дистрибутив собирается под нужды клиента. А пакет зачем?  

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:14 
> Ikey Doherty подчёркивает, что AerynOS - это не просто "ещё один дистрибутив Linux"
> Проект опирается на опыт авторов в разработке других дистрибутивов, включая Solus и Clear Linux.

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

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:22 
> Руководитель проекта Ikey Doherty подчёркивает, что AerynOS - это не просто "ещё один дистрибутив Linux"

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

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 19:24 
Я так до сих пор и не понял, зачем весь этот овер-инжиниринг. Какие проблемы это всё решает, которые не решить другими, более традиционными средствами?

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 07:42 
Чем проект переусложнённее, тем он прогрессивнее же!

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 20:04 
Вот прочитал новость, прочитал внимательно, и...

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

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

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 21:32 
Как раз, чтобы не было УГ, надо объявить о Миссионерском или Революционном характере дистрибутива.  

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 21:47 
"Разработчики AerynOS, ранее известного как SerpentOS"

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


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 22-Май-25 22:45 
Данные о предпочтениях одного из пользователей можно считать состоянием программы при работе с этим пользователем. Где хранить и что хранить? Должен ли пользователь видеть эти данные?
Данные пользователя, обработанные программой, где хранить?  

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено waylandbeliver , 22-Май-25 22:51 
Если будут зависимости как остальных дистрах, то не взлетит.
Надо повторять модель Windows/MacOS.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено 3draven , 23-Май-25 00:42 
Вот когда ИИ заменит ОС, это будет инновация, а это все переставление кроватей на фоне всего в контейнерах, всем пофиг какой там на дне дистр давно.

"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 09:28 
>При этом система использует glibc вместо musl, что является осознанным выбором в пользу совместимости и производительности.

Крайне спорный вопрос, взять ту же поддержку локалей, которых в musl емнип до сих пор нет. Вопрос с точки зрения запуска готовых бинарников. Вопрос с точки зрения производительности


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 12:36 
> взять ту же поддержку локалей, которых в musl емнип до сих пор нет

Они сто лет как работают. Использовал Alpine Linux как десктоп ОС.


"Представлена концепция дистрибутива AerynOS с обоснованием а..."
Отправлено Аноним , 23-Май-25 13:49 
>AerynOS - это не просто "ещё один дистрибутив Linux", а платформа, фундамент

Это основа, это, так сказать, база