LINUX.ORG.RU
ФорумTalks

Если бы вам выдался шанс переписать Linux с нуля

 , ,


0

2

Не ядро Linux, а все базовые составляющие дистрибутива: ядро, системные библиотеки, систему инициализации, графическую подсистему, десктопное окруженние, звуковую систему… Что бы вы в первую очередь изменили? Именно речь о том, что затруднительно изменить в существующей системе.

Ну я бы, из того, что приходит в голову, сделал бы стабильный API для модулей ядра. Хотя бы для драйверов конкретных типов оборудования. Да, ядро должно развиваться, но не все драйверы принимают в апстрим. Даже свободные, например, драйвер для ZFS.

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


Стабилизации API и сейчас не мешает ничего, кроме бараньей упертости некоторых товарищей.

Разрешения, кстати, тоже можно реализовать хоть завтра без потери обратной совместимости.

quwy
()
Ответ на: комментарий от rupert

Предлагай варианты решения и расценки. За столько-то готов внести такие изменения, за столько-то ­— ещё и другие, за столько-то — и третьи…

Wapieth
() автор топика

Взял бы пример с FreeBSD, а еще лучше, в наш век виртуализации и быстроты процов поменял бы архитектуру ядра с монолита на микроядро, и все драйвера перевел бы в юзерспейс

linuxoidspb
()
Последнее исправление: linuxoidspb (всего исправлений: 1)
  • Более глубокая интеграция с systemd. Остальные нескучные системы инициализации - на помойку.
  • Перенёс бы графическую подсистему на уровень ядра. Иксы уже достаточно стабильны для такого, а вяленый не нужен.
  • Разделил бы либы на системные и для уровня пользователя - каждая программа была бы обязана нести с собой свой собственный набор либ. Места на дисках сейчас навалом, а динамическая линковка - зло.
  • Сомнительно, но добавил бы возможность убивать процессы в состоянии D (IO). Даже с потерей данных. Просто реально раздражает что в случае зависания таких процессов приходится отправлять в перезагрузку всю систему.
Hg194
()

на работу с камерой, микрофоном, произвольному доступу к файлам, скриншотам и т.п.

Это все произвольный доступ к файлам (:

Avial ★★★★★
()

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

Avial ★★★★★
()
Ответ на: комментарий от Hg194

Иксы уже достаточно стабильны для такого, а вяленый не нужен.

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

usi_svobodi
()

Что бы вы в первую очередь изменили?

Писал бы на С++, шаблоны, ООП и гораздо более актуальный стёк в разы ускорило бы разработку.

Ygor ★★★★★
()
Ответ на: комментарий от usi_svobodi

иксы начинают активно закапывать

Уже лет 10. А вайланд разрабатывается уже лет двадцать с около нулевыми результатами.

Ygor ★★★★★
()

Если бы вам выдался шанс переписать Linux с нуля

А в чём, собственно проблема, и почему нужен шанс? Бери да переписывай, если время и желание есть. Оно в итоге никому будет ненужно, почти наверняка. Но переписать никто не мешает.

систему инициализации, […] звуковую систему… Что бы вы в первую очередь изменили? Именно речь о том, что затруднительно изменить в существующей системе.

Если речь не просто о переписывании (что я могу и так, и что и без меня тоже сделали уже), а о том, каких изменений хотелось бы, но их трудно продвинуть, то тут очень просто: в первую очередь я бы хотел, чтобы systemd и pulseaudio никогда не существовало.

Также я бы привнёс в систему некоторые идеи из Plan9, в особенности большее развитие идеи «всё есть файл».

CrX ★★★★★
()
Ответ на: комментарий от usi_svobodi

в кедах он уже идет по умолчанию. в гноме не знаю, но вроде тоже и давно. так что не вижу нулевых результатов.

Тут в толксах обсуждалась ситуация с браузерами, когда обращения браузера к вайланду приводило к гонкам данных в вайланде.

Ygor ★★★★★
()

«Если бы вы были моей женой, я бы повесился»(С)

seiken ★★★★★
()
Ответ на: комментарий от Ygor

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

usi_svobodi
()
Последнее исправление: usi_svobodi (всего исправлений: 1)

Если бы вам выдался шанс переписать Linux с нуля

то им грех не воспользоваться

vaddd ★☆
()

Переписывать почти ничего не надо, я просто дичайше внедрял бы культуру статической линковки и/или дистрибуции, и укрупнения модулей заодно.

Лучше иметь возможность свалить сто файлов в каталог и запустить исполняемый бинарник, чем распихивать миллион файлов по дереву, лепить из этого Контейнер и запускать Через Жопу с героическими усилиями и худшим результатом.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

Формат распространения ПО и «размазанность» пакета по сей файловой системе. чтобы можно было без плясок с бубном устанавливать готовые бинарники нужной версии в любом дистрибутиве и иметь несколько версий ПО одновременно.

Принудительный запуск софта в контейнерах с контролем доступа к памяти, файлам, железу.

Разбитие системы на «base» (монтируется в ro, содержит основные системные компоненты, общие библиотеки и (опционально) графическую подсистему) можно «патчить» через оверлеи) и «user» (монтируется в rw, все пользовательские данные и ПО тут.

Кто-то скажет «looks like Vedroid» ну да типа того, только в ведроиде контроль прав приложений слабоват.

Kolins ★★★★
()
Последнее исправление: Kolins (всего исправлений: 1)

сделал бы стабильный API для модулей ядра

Он же вроде радикально не менялся с 2.6?

систему инициализации

В OpenWRT хорошая.

ядро

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

звуковую систему

Портировать из FreeBSD, когда ничего не надо настраивать, и ядерный софтовый миксер есть.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)

Stable API/ABI во все поля, переписать на**й всю графическую подсистему НЕ как в вяленде, удобная нарезка fine-grained прав для каждого приложения вплоть до «на этот урл именно тебе ходить нельзя, и в тот каталог тоже нельзя».

yu-boot ★★★★★
()

Это сложный вопрос. Так сразу и не ответишь. Ну, init бы оставил, x11, dwm... И, да, микроядро бы сделал.

sparkie ★★★★★
()

Что бы вы в первую очередь изменили?

Адаптировать все под musl, чтобы все эти программы были совместимы. Благодаря этому статическая линковка намного упростится и можно будет все основные программы просто взять и статически слинковать. Это позволит не таскать кучу динамических библиотек под каждую отдельную программу, соотвественно уменьшится потребление оперативной памяти, поскольку сейчас динамические библиотеки полностью грузятся в память вне зависимости какая часть их используется, а при статической линковке будут в бинарник вкомпилены только те части которые используются. Это все будет занимать меньше места на диске, кроме того пропадет проблема того что динамически слинкованные программы ломаются после обновления этих библиотек, например когда ломается совместимость или когда название самой библиотеки меняется, и программа просто не может подгрузить нужную библиотеку чтобы запустится. Короче это будет не такое требовательное к ресурсам решение как например в NixOS или GuixSD. Конечно это будет не без минусов, например производительность программ будет ниже, кроме того musl не такая фичастая как glibc, поэтому придется многие фичи либо резать, либо костылить.

vbcnthfkmnth123 ★★★★★
()
Последнее исправление: vbcnthfkmnth123 (всего исправлений: 3)
Ответ на: комментарий от Ygor

...на С++, шаблоны, ООП...

Только не это!

...в разы ускорило бы разработку...

Это да. Значит, писать надо не на крестах.

sparkie ★★★★★
()
Ответ на: комментарий от Kolins

Разбитие системы на «base» (монтируется в ro, содержит основные системные компоненты, общие библиотеки и (опционально) графическую подсистему) можно «патчить» через оверлеи) и «user» (монтируется в rw, все пользовательские данные и ПО тут.

Совсем скоро в федоре!

whbex ★★
()

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

В андроиде это реализовано через 1000500 юзеров с политиками SELinux.
Лучше делать как в одной известной (тут) OS - AMFI.kext, Sandbox.kext. Собственно, там оно уже давно работает без каких-либо проблем.

whbex ★★
()
Ответ на: комментарий от whbex

Совсем скоро в федоре!

да уже и в бубунте пытались и nixos есть который в абсолют эту идею возвел и coreos и много чего еще, но как-то не приживается

Kolins ★★★★
()

системные библиотеки

Более менее стабильный API хотя бы для некоторых важных библиотек + возможность хранения нескольких версий одной либы.

графическую подсистему

Переписать или выкинуть Xorg, отсутствие НОРМАЛЬНОЙ поддержки двух+ мониторов в 2024 - моветон. Необходимость пердолить конфиг или отключать композитор, а потом всё равно страдать от багов с VRR/рефрешрейтом/скейлингом - ненормально.
В Wayland - переписать Mutter так, чтобы он научился в SSD - то, что они предлагают в качестве альтернативы (libdecor) - хрень без документации. В wlroots осилили, в KWin тоже, в чём проблема гномеров-то. Понятно, что всё закостылили, но если делать клиент с нуля без тулкитов - будет больно. Очень. Ну и доделать уже client reconnect.

whbex ★★
()

1. Stable API/ABI is not nonsense. 2. Stable & extendable API/ABI for GUI.

thunar ★★★★★
()

Я бы запретил использовать питон. Под страхом смертной казни.

И оставил бы для системного софта только c/c++/asm

Chord ★★★★
()
Ответ на: комментарий от dataman

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

thesis ★★★★★
()
Ответ на: комментарий от Ygor

вайланд разрабатывается уже лет двадцать с около нулевыми результатами.

Вообще, в распространённости этого мнения виноваты гнумеры, у них под вяленым работает примерно ничего. Плазма на интеле работает из коробки на удивление хорошо.

HE_KOT
()

линукс опенсорсен. почему рассуждение ведётся в формате «если бы выдался шанс»? возьмите и перепишите.

flant ★★★
()
Ответ на: комментарий от Chord

Я бы запретил использовать питон

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

ты фанат антиутопий?

flant ★★★
()

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

Чтобы программу можно было просто взять и запустить.

Без пердолинга с зависимостями, репозитариями, libc не той системы, ядро не той версии.

Xintrea ★★★★★
()
Ответ на: комментарий от flant

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

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

thesis ★★★★★
()

Очевидно лицензировать всё это под гпл3.

ya-betmen ★★★★★
()

Что значит шанс переписать? Тебе кто-то доступ к исходникам закрыл? Иди на свой диван и пиши. Шанс договориться с остальными умножить на шанс пройти ревью умножить на шанс разобраться в тоннах говна умножить на шанс не выгореть в угли после всего = ноль целых хрен десятых. Теоретик млять.

Lordwind ★★★★★
()
Ответ на: комментарий от flant

Например система управления пакетами - вполне себе системное ПО, в том же генту написано на питоне.

Chord ★★★★
()

Cделал возможность отдельным разработчика, зарабатывать $$$ на своем коде. Это во-первых. Потом, внедрил как можно больше фитч из Freebsd. Убрал зависимости от С. Придумал какую-нибудъ специальную «прокладку» для сборки и разветывания ПО в виртуальном окружение, а-дя chroot, только чтобы постоянно и без геммоя была. Потом занялся - основной проблемой доставкой софта для конечного пользователя. Придумал совершенно что-то новое, часть взял от dpkg часть от pkg, но это было совершенно иное. Главная его фишка заключалось, что любой пакет можно было собрать где угодно и на что угодно, и опакетить его хоть в deb,хоть rpm, но было сделано на модульном уровне без постоянного роста зависимостей. Потом придумал какой-нибудъ специальный api к вышеназванному и сделал по-иному, чтобы можно было рулить системой на декларируемом уровне.

nager
()

Если бы вам выдался шанс переписать Linux с нуля

Я вам по секрету открою страшную тайну (ТОЛЬКО НИКОМУ НЕ ГОВОРИТЕ): такой шанс есть у каждого. Надо иметь просто умственный уровень ну чуть-чуть выше среднего и что куда важнее – охрененную мотивацию. То есть надо быть очень сильно упоротым в хорошем смысле. Всё остальное можно купить, прочитать, изучить и попробовать. Сейчас писать ОС с нуля гораздо легче, чем в 1990 году.

Тем более, ты не ядро хочешь менять, а что-то вокруг ядра. Ну и на здоровье.

не все драйверы принимают в апстрим. Даже свободные, например, драйвер для ZFS.

Там с лицензией кое-какие непонятки, я ведь правильно понимаю?

сделал бы стабильный API для модулей ядра. Хотя бы для драйверов конкретных типов оборудования.

Пиши, предлагай в апстрим, все будут только за.

Соблазни соседку, тёщу, тестя – только не сиди!

hobbit ★★★★★
()

… Что бы вы в первую очередь изменили? Именно речь о том, что затруднительно изменить в существующей системе.

Таких переписывальщиков операционок уже пруд-пруди: «Сбер ОС», «Файр ОС», «Андроид» и т.д. Пройдет время и имен этих повторятелей никто даже не вспомнит.

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

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

Enthusiast ★★★
()
Ответ на: комментарий от Enthusiast

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

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

Другой вопрос, что вылезти из этого говна, не сломав все и не начав заново, тоже нереально )

vaddd ★☆
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)