Pull to refresh

URiX — Review of Not uNix

Reading time 9 min
Views 3.2K
Я Draw
В начале было «Я»
xRain Logo
Привет!
Я часто исследую разные задачи, проблемы и вот одна из них — оказалось, что есть много много GNU дистрибутивов, но все они так или иначе работают по принципам unix, то есть как такового развития не происходит, развиваются программы, ядро, а вот структура как была x-летней давности так и осталась, в общем-то это объясняется проблемами совместимости, которые могут возникнуть в случае попытки прыжка на месте. Я решил задуматься о том какие могут быть возможности развития GNU/Linux и в то же время о вариантах объединения сообществ разных дистрибутивов, поэтому подозреваю, что есть адепты в том числе и оконных поделок, и бсделок, а для меня и не-иксы примерно все одинаковые, по крайней мере в плане распределения транзакций между кэшэм\кэшами ядер процессоров, предлагаю сразу же git дружно.
Задача этого поста — привлечь внимание аудитории к проблеме, оценить степень её важности и попробовать найти более совершенное исполняемое решение, хотелось бы добрых намерений и возможной добровольной помощи в реализации.
Beware of odd words! Text below is very hard to read and understand!
Unreadable-Formation-Occurrence spotted!


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

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

конус — 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 ядру, а пользователи подключают свои настройки к этому процессу и работают через агентов.

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

Некоторые поставленные задачи будут требовать статического расположения некоторых входов\выходов ядра, чтобы другие программы могли обращаться к ним напрямую и это может быть прописано при компиляции программ, тем не менее такие библиотеки не будут слишком частыми и в целом нужно только подключать к ним агентов пользовательского уровня, допустим эти агенты будут справляться с назначением запросов и ответов — станут своеобразными интеллектуальными службами, для них нужно обеспечить высокую скорость работы, поэтому и предлагаются статические адреса памяти — буфферы-стэки для определённых библиотек, можно это сравнить с разбиением диска на различные области. После вторичной перекомпиляции ядра свободные адреса памяти будут точно известны, если задать небольшой отрезок для обмена данными между библиотеками, то теоретически это может помочь в решении некоторых задач.
Модель Х-ядра предполагает использование нескольких ядер и распределение между ними функций общего Linux-ядра, в такой модели должна быть достаточно жёсткая структура распараллеливания функций и распределения ресурсов-ядер процессор-а(-ов), а значит, необходима будет и углублённая работа с памятью, которая возможно уже создаст определённые статические точки для внутренней работы, я думаю, что нужно будет подключать библиотеки напрямую к этим точкам — компиляция будет проходить на-лету. А по факту компиляции не нужно будет происходить и не будет происходить традиционной загрузки приложения, т.к. приложение будет занимать своё прежнее место в памяти вместе со всеми необходимыми модулями из снимка памяти сохранённого в squashfs и подключаться к базовым точкам входа rawx-ядра.
Возможные проблемы будут возникать при недостатке памяти и вынужденном переносе программ из своей области в чужую, тогда необходима будет перезагрузка этих программ для перекомпиляции их squash-образа в соответствии с новой конституцией памяти, вероятно, следует ввести приоритезацию для процессов, чтобы не возникало лишних конфликтов.

вообще примерно всё уже сделано в программах параллельного вычисления, в распределённых облачных решениях, рендер-фермах oscar, openstack, moSix или даже squid, nginx+fpm то есть прямо такого велосипеда не надо делать, а всего лишь обобщить знания и применить их в новом свете.
в принципе часть проблем между сетевыми машинами можно решить с помощью squashfs модулей, как это сделано в магос, то есть передавать на клиентский хост файловую систему с необходимыми рабочими файлами, для конкретной программы, эти файлы могут там и сохраняться, но это частный случай параллелизации, в общем случае, нужен унифицированный стэк библиотек для нескольких типов программ, который пользователь будет загружать в своё локальное виртуальное ядро и получается, что это также можно решить с помощью squashfs для нескольких ядер на одном или нескольких процессорах одного компьютера.

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

encore une foi ,' )

Мой сайт не выдержит популярности, поэтому тут ссылок нет, а на гуглоплюсе я писал на английском.
В целом не уверен, что тема кого-то волнует, вопрос развития СПО глубоко безденежный.
Что-то из этого сложно понять, потому что мне кажется это не простые вещи и объяснить каждому и любому — невозможно за короткий промежуток времени, пока концентрация внимания сознания не спадёт, в среднем для новой информации — это 2-4 минуты ±2, приблизительное время популярной музыки. Можете слегка исследовать свои музыкальные предпочтения, найдите любимый трэк, посмотрите его длительность, лучше выделить ещё тот момент, который особенно нравится — это вероятный пик восприятия.
я привык к запилам по полтора часа .' )
придумывать вообще интересно, но возникают разрывы… между тем, что придумал я и тем, что знают другие люди, ведь, чтобы что-то придумать и создать нужно проанализировать достаточно много того, что уже сделано, понять ошибки, простить расхождения, определить вероятные направления — это называется интуиция, подтвердить правильность, я не могу описать все свои исходные данные, я считаю, что это и не нужно, я предложил модель, частично в комментах уже есть пруф оф концепт в виде ссылок на другие проекты, которые что-то уже реализовали похожее, я предлагаю двигаться дальше, исходя из текущих данных, я думал у меня велосипед или колесо, но оказывается это летающая тарелка '. )
Чтобы «наше СПО» было — его надо сделать.
btw 10x 4 add. +read ++understand
Tags:
Hubs:
-11
Comments 20
Comments Comments 20

Articles