Пока all обсуждают что лучше - wayland или legacy под названием иксы, я бы предложил поднять другую гораздо более интересную тему: ведро линупса есть окаменевший кал мамонта. Его надо перепилить
И вот почему:
1)Возьмем отображение физических страниц памяти в виртуальные адреса. Все что там в ведре нагорожено, очень наверно хорошо - но только для случая абсолютно абстрактной программы, которая хаотически дергает сисколлы с рандомными значениями. Только на реальных программах то, работает линупс ортогонально тому, как удобно работать для современных процов.
В реальной жизни не нужно уметь mapнуть любой адрес в любой адрес. Нужно мапать сразу блобы, и в 99% случаев некритично, сколько адресного пространства потеряется из-за выравнивания. У вас много на десктопе программ, у которых по данным top виртуальной памяти по 2гига и более? А гиг? А 512 метров? я окромя ожиревших иксов и фурфокса не упомню, и то - у последнего память занимает heap, которому тоже некритично где лежать, главное лежать. а иксы... :) ну да, иксы. зачем они, когда есть wayland И современные процы позволяют это сделать. Пусть процесс содержит таблицы страниц для верхнего уровня(или среднего для x86-64) , а блобы в памяти содержат нижний уровень. Да, тогда их мапить получится лишь по адресам, кратным 4мб или 2мб. Зато форк и mmap будет мгновенным - не надо создавать на форке кучу структурок, нужных для того, чтоб следить, а кто это юзает физическую страницу, которую мы выгоняем на диск.
Мапнуть блоб к себе? Не вопрос,
memcpy(mytables+offset, blob->phys_addr_tables, sizeof(pagedescr)*((size_of_blob+big_page_size-1)/big_page_size)Надоела страница? Не вопрос,
pagedescr * tmp=pages[index].where_is_it->phys_addr_tables;
tmp[pages[index].offset]=0;И все действия такой же сложности примерно. Хелловордовой.
Далее, большинство библиотек и, ширше говоря, тулкитов, идет «паровозом». То есть Qt = {libQtCore + libQtGui + libQtXml + libQtNetwork + blablabla} Вот что мешает возложить на линкер боевую задачу - знать из конфига, какие либлиотеки меж собой дружат, и для каждой такой группы держать один блоб to rule them all? Сколько там стартует типовое кедоприложение из-за динамической линковки? 7500 времени? Причем тормозит из-за того, что по мнению ld-linux.so.2 все либлиотеки «разные», он их каждый раз как в первый раз видит, и заново создает .got для них. ну слинкуй ты их намертво в блоб и держи 1 .got на всех, тем более что он меньше будет, чем раздельный. А поскольку без запроса блоб в память не подкачивается, не потребуется городить какую-то модульность. Не нравится libFoo5 из libFoo[1-100]? Не обращайся, делов-то.
Реализация плевая, соотвествующий код сокращается до предела, но ведь мы же не можем ничего менять потомучтосовместимость. Поэтому проще заменить линупс.
2)Терминалы - зачем это в ведре? От ведра требуется лишь «передать строку» и послать сигнал. Мне казалось, ведро уже умеет это делать. Вот честно, скажите, какая повседневная программа из консоли требует себе в stdin/stdout терминал? НЯП все нормально шуруют через пайп. От пайпа терминал отличается разве что очень полезными ioctlами, без которых жизни красноглазому нет: это установить сколько бит в байте, установить скорость в битах/секунду, и прочая лабуда. Из нового есть только костыль включить/выключить утф8. Я еще понимаю, когда речь о com-портах идет. Ну оставьте эту байду в драйвере ком-порта, зачем это в tty тащить, да еще в ведро? Вынести все в libtty.so и не держать в ведре страшное legacy. Правильно Alan Cox ушел, сколько можно подпирать костылями кучу дерьма, созданную для эмуляции ламповых печатных машинок? Размер «окна», управляющие символы - все это должно делаться в userspace. Один хрен никто в чистом терминале с моргающим курсором давно не сидит. Везде xterm, gnome-terminal, konsole и т.д. и т.п. В винде под цигвином вся эта консольная лабуда работает, хотя там в ведре никаких юниксовых терминалов нет.
3)Планировщик - вот скажите мне пожалуйста, как через nice сделать так, чтоб фоновое приложение икс и его потомки в сумме жрали не меньше 18.2% процессора, но не вытесняли остальных? Задача элементарнейшая - скажите студенту: сделай мне алгоритм, который будет делать кольцевой список задач, у которых может быть такой же список подзадач, и % минимального использования проца в секунду или min((1-reserved_time)/nprocs) если не указано, получишь зачет. Студент сделает. И этот алгоритм будет работать потому что он тупой как хелловорд. Без всяких там cfs/bfs и 12309. Почему у линупса до сих пор такой сраный планировщик, что его можно разбомбить форк-бомбой и на нем под нагрузкой звук хрюкает?
