URiX — Review of Not uNix

Я Draw
В начале было «Я»

Привет!
Я часто исследую разные задачи, проблемы и вот одна из них — оказалось, что есть много много GNU дистрибутивов, но все они так или иначе работают по принципам unix, то есть как такового развития не происходит, развиваются программы, ядро, а вот структура как была x-летней давности так и осталась, в общем-то это объясняется проблемами совместимости, которые могут возникнуть в случае попытки прыжка на месте. Я решил задуматься о том какие могут быть возможности развития GNU/Linux и в то же время о вариантах объединения сообществ разных дистрибутивов, поэтому подозреваю, что есть адепты в том числе и оконных поделок, и бсделок, а для меня и не-иксы примерно все одинаковые, по крайней мере в плане распределения транзакций между кэшэмкэшами ядер процессоров, предлагаю сразу же git дружно.
Задача этого поста — привлечь внимание аудитории к проблеме, оценить степень её важности и попробовать найти более совершенное исполняемое решение, хотелось бы добрых намерений и возможной добровольной помощи в реализации.

процесс загрузки часто бывает достаточно долгим (относительно исполнения программ например) и это может быть упрощено с помощью профилей оборудования и слепков (снимков, snapshot) памяти
я однажды предлагал использовать модель simutrans x-kernel, может быть оно уже работает, а может быть когда-нибудь сделают, потому что альтернатив не так много суть в том, чтобы использовать схему транзакций и положения софтового ядра в памяти, для того чтобы распределять потоки между разными ядрами процессора, чтобы в итоге получить снижение времени их обработки используя вычислительные фабрики всех физических ядер процессора, а не только одного того, на котором исполняется текущий код.

Визуальная модель ядра RawX

конус — root hash user
куб — boot kernel
икосаэдры — первая волна сервисов ядра
сферы — вторая волна сервисов
бублики — это периферия подгружаемая сервисами от hash-root пользователя
на самом верху — прозрачный для пользователей процесс окружения
задача review of «not unix» — (понять и простить) сделать более гибкой и стабильной систему
примерно выделяется три состояния
logic-structure-data and also boot-system-user

На этапе загрузочного ядра будут загружаться начальные инструкции — cpu mem bus, чтобы первая волна сервисов могла определить базовое оборудование и подгрузить для него модули, но ещё раньше активируется первичный пользователь (root), у каждого компа должен быть свой хэш-код для этого пользователя, чтобы был собственник всех процессов и ресурсов. Для меня это важно так как сейчас любой root может просматривать файлы на не зашифрованной системе и получать доступ к любому железу. Поэтому я решил что должен быть system-root-hash user, который может проходить аутентификацию, если пользователь не игнорировал такую функцию при установке. Этот же хэш может использоваться в качестве соли для шифрования user/home, pam/ssl и поэтому pam-auth сервис также должен загружаться в первой волне вместе с базовым оборудованием, чтобы можно было провести дополнительную аутентификацию — клавиатура, видео, звук (ага, хочется голосовой аутентификации и голосовых команд), может быть хранилища данных. Я думаю всё это уже делается ядром линукса, нужно только поднять аутентификацию, чтобы затем можно было управлять ресурсами хэш-пользователем и делегировать их реальным пользователям.

Зная, что все данные будут затем перелинкованы с помощью aufs можно попробовать разделить их в более удобоваримом для компьютера виде, думаю, что не стоит все исполняемые файлы скидывать в одну директорию, так как это отнимает время при листинге, поиске и сверке файлов в этой директории, разделим их на кучи по крайней мере имеющие человеческую логику, к примеру 1,2,3-/a/b/c как например в spool/squid иерархии, но я думаю, что может быть будет лучше разделить следующим образом scripts/php.js.sh and execs/c.java.fortran texts/html.txt.pdf — то есть такая обратная сортировка по расширению файла, чтобы было легче определять интерпретатор или программу для открытия этого типа файлов интегрированно в системные процессы, чтобы в любом случае любой jpg можно было найти в data/img/jpg а любой cron script в scripts/sh. я не полностью уверен, что это обязательно должно быть именно так, просто думаю, что если все разрешения и запреты в ядре примерно одинаковы и исполняются от одного пользователя, то нужды в разделении на дополнительные папки вообще-то нет — эта логика нужна скорее для админов и программистов, а компьютеру нужна точка начала файла и в какой буфер его загружатьвыгружать, поэтому может быть просто вот такое имя 01.011.this.program.file.jpg — да, это новая /non-unix/ схема и здесь может быть также отмечен и приоритет и порядок загрузки файла ядром.
а удобная для людей форма появится только на следующем более высоком уровне, который может легко воспроизвести схему данных unix с помощью пустых жестких симлинков в squashfs

Загруженное в память исполняемое ядро, может быть хотя бы раз перекомпилировано в соответствии с теми задачами, которые оно выполняет для каждой машины, примерно как initrd.img, чтобы не нужно было обнаруживать и загружать несуществующие модули оборудования и это своеобразная заточка ядра под железо и наиболее частые задачи, т.к. такую статистику вполне можно собрать за несколько рабочих сеансов, а выхлоп будет в более тонком распределении ресурсов и простой проверке на идентичность оборудования — тогда сразу может загружаться заточенное ядро в память (слепок — snapshot) бех инициализации и прочего, на него сшиваются базовые функции загрузочного ядра и сразу после загрузки в память это ядро уже может работать.

После первой волны загрузка ядра заканчивается, а вторая вызывает расширенные сервисы системы и оборудования — сеть, x.org, cron, дополнительные устройства, файловые системы, управление для пользователей и всё остальное, что связано с базовой функциональностью системы, то есть gnome,apache,squid здесь не грузятся, а загружаются компиляторы, интерпретаторы, драйвера, шрифты, чтобы пользователь уже мог справляться со своими сервисами
на второй волне выстраивается стандартная никсовая модель /usr/lib/bin чтобы создать рабочую среду для unix/gnu программ с помощью aufs,zfs или виртуальных машин, чтобы можно было отойти от уровня абстракции rawx ядра и эмулировать через него работу gnu/linux модели для интерфейсов конечного пользователя.
на вершине работы rawx мы получаем виртуальное linux-compatible ядро, которое работает с процессами пользователя, то есть реальное ядро надёжно защищено за виртуальной прослойкой, но также это значит, что мы можем иметь столько ядер, сколько позволят ресурсы и будет держать железо, поэтому нужно заниматься распределением памяти и ресурсов цп между пользователями — это примерно как виртуальная машина, только без машины, мы обращаемся к сервисам ядра, возможно это уже реализовано в KVM, то есть мы виртуализируем не ядро и
машину, а только высокоуровневые процессы

В общем ядро загружается и перехватывает связи от разных библиотек, эмулирует окружение в каких-то странных случаях и эмулирует структуры дистрибутивов, когда это необходимо для каждого пользователя или процесса.
иногда, я представляю себе пользователей как процесс, а процессы как пользователей — такая модель может показать как нужно распределять программы между пользователями, почему один процесс не может иметь разных пользователей? Сейчас каждый пользователь запускает свою копию программы, хотя ему требуется в основном только некоторые её функции, можно разделить эту программу на базовую логику, системные библиотеки и пользовательские данные
тогда каждому не нужно будет запускать «свой» браузер — у всех пользователей запущен один процесс в котором загружена базовая логика и системные библиотеки, а все пользовательские уже загружаются в отдельное пространство памяти, намного меньшее, чем сама программа. Работа пользователей происходит только с раздельным кэшем и памятью, персональные настройки содержатся в профиле и сохраняются в слепке памяти браузера для конкретного пользователя, и когда нет активности всех пользователей этот процесс также выгружается целиком из памяти в squashfs или img.gz, то есть если процесс один раз запустился удачно и завершился тоже удачно, то этот образ процесса сохраняется и используется системой без повторной загрузки всех конфигураций, библиотек и интерпретаторов — загружается слепок (снимок) памяти этого процесса, который сразу же работает аналогично rawx ядру, а пользователи подключают свои настройки к этому процессу и работают через агентов.

P/S
Я далеко не системный программист или архитектор, асм изучал только в плане mov(ax,bx), системное администрирование — это моя слабость, я стараюсь сильно ей не увлекаться и не злоупотреблять, поэтому если есть true знания в стезях — поправьте, а если вопрос даже и не интересен и не вызывает осознанной мотивации, а только эмоциональные реакции — можно просто скипануть пост или попытаться осмыслить

encore une foi ,' )

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

Автор: oeai

Источник