LINUX.ORG.RU
ФорумTalks

Давайте опишем сферическую свободную ОС в вакууме или какой должна быть альтернатива современному ПО?

 , , , ,


1

3

На мой взгляд:

  • Гибридное ядро. Даже по словам Э. Танненбаума, которые были сказаны 30 лет назад, написание монолитного ядра в 1991 году было «гигантским шагом назад в 1970-е годы». Современность это доказала тем, что самые функциональные OSX, IOS, и Windows - это операционные системы на гибридном ядре. Среди самых популярных ОС с допотопным монолитным ядром прижился только один Linux за счет пропаганды и за счет «манипуляций» с тивоизацией у тех же производителей Android, где тивоизация - основной способ заработка на системе. Выигрыш OSX, IOS и Windows произошел даже хотя бы потому, что там можно написать приложение, и оно через 20-30 лет будет работать, а не как в том же Android, где софт от Kitkat уже не запускается на том же Nougat, не говоря уж о Tiramisu или Snow Core, а если даже и не работает (сейчас достанут пример с принтерами) не потребует существенных трудозатрат в адаптации, как например, в Linux, где форки Gnome 3 адаптировались к GTK3+ чуть ли не годами. Ну и конечно же, никаких идиотизмов, в духе 100500 пакетных менеджеров, на которые у сторонних разработчиков малого и среднего уровня нет ни времени, ни средств.
  • Качественный и отлаженный инициализатор, и в то же время простой в устройстве, вроде LaunchD. Не нужно ни монстров, вроде Systemd, которые лезут куда не попадя, прихватывая даже функцию загрузчика на себя (systemd-boot), ни SysvInit, который понятное дело ввиду усложнения современных процессов загрузки и обретения нового функционала и свойств, выполнять современные задачи не способен. Мы же все-таки не в 90-ых годах, где хорошо, если будет в авторане какой-нибудь командный файл bin. Надо запускать целые комплексы ПО, о котором пойдет речь дальше.
  • Иксам действительно уже пора на покой, поскольку в иксах накопилось довольно много функционального хлама, который вообще никак не задействуется. Но при этом не нужно и кастрированных до маразма Wayland-ов, где даже скриншот экрана нормально сделать нельзя, и где зоопарк с дурдомом в области совместимости с видеокартами - старые видеокарты за борт, а владельцам новых, на Linux делать нечего, поскольку не игорь, ни того же профессионального ПО, вроде Photoshop под Linux по понятным причинам нет. Поэтому нужен сбалансированный графический сервер, который в то же время станет полегче по сравнению с иксами, но при этом не будет идиотизмом, вроде Wayland, где штатные и востребованные операции, будут выполняться через костыли.
  • Дисплейный менеджер сеансов понятное дело, должен быть похож на GDM3, и вообще нужен ли он - тот еще вопрос, поскольку сейчас подразумевается, что шаровое использование ЭВМ - редкий кейс. Даже в Android не прижился многопользовательский режим, поскольку смартфон создавался с прицелом на личное использование. И даже само название «Персональный компьютер» говорит об этом. Единственное, для чего в теории он может пригодится - это для выбора дескопов и сред, но их можно реализовать как через дуалбут, так и через тумблер в сеттингсах.
  • Рабочий стол - исключительно по многолетним опытным разработкам для каждого устройства, и никаких инопланетных третьих гномов на дескопе, где для открытия ПО, нужно разворачивать на весь экран лаунчер и тянуться мышью с одного конца экрана на другой или заучивать дурацкие комбинации клавиш, вместо того, чтобы воспользоваться мышью. Клавиатура для набора текста и для использования либо слишком частых и нужных комбинаций, вроде смены раскладки, где каждый раз мышкой в трей не навозишься, либо для чересчур редких, где понятное дело, реализовывать гуй - тот еще вопрос. Для всего остального - гуй. Тоже самое касается и пальцетыкальной Windows, где нужно в тот же мелкий пуск из десяточки попадать толстыми пальцами на семидюймовый экран. И естественно, никаких «галерей» и прочего сумашествия, где за юзера решают, где ему хранить фотки. Хочет хранить на SD-шке, пусть хранит. Работа с файлами и дисками должна быть каталоговая.

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

Ну а какой бы вы хотели видеть современную подлинно свободную ОС 21 века?



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

Ответ на: комментарий от eugrus

У меня абсолютно заданы раскладки (Ctrl+цифра), так что перед такими действиями руки сами включают нужную: сознание включается уже только когда нужная программа запустилась.

И еще ремарка: неужели вы думайте, что производители телевизоров - тупоголовые и безмозглые идиоты, если решили с пультов вырезать почти все кнопки, и оставить только включить, джойстик, Enter (ОК), назад, домой, список приложений? Нет, интуитивный интерфейс гораздо удобнее, нежели чем зубрежка клавиш, про которую любят рассказывать любители гнома.

ipkirill22x
() автор топика
Последнее исправление: ipkirill22x (всего исправлений: 1)
Ответ на: комментарий от unDEFER

Ну есть хорошая новость — конкурента Гипму ты по крайней мере способен написать. Тем более у тебя есть возможность смотреть на прототип, учитывать его ошибки. А какие-то компоненты просто заимствовать, GEGL тот же :)

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

Что в Gnome, что в Windows для открытия программ нужно нажать кнопку Windows Super и ввести несколько букв из названия программы - никуда тянуться мышью вообще не нужно.

В KDE, если что, то же самое.

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

Это да, конкурента Гимпу вроде потянуть можно, но фортуна как раз в этот момент сказала: «Do not overtax your powers.» :-)

У меня fortune | cowsay в .bashrc, срабатывает при каждом открывании терминала. Кто видит, всё время спрашивают: «что за собака у тебя там?»

unDEFER ★★★★★
()
Последнее исправление: unDEFER (всего исправлений: 1)
Ответ на: комментарий от prox

На современным процессорах – это не такая уж большая проблема. Люди когда-то смирились с необходимостью вызывать подпрограммы, можно смириться и с этим. Ну будет просадка 3-5%, зато можно получить большую безопасность, надежность и гибкость.

Не все так однозначно:

https://news.ycombinator.com/item?id=9871263

https://www.quora.com/How-much-slower-is-a-microkernel-based-operating-system...

IMHO было бы интересно сравнить производительность Linux vs Hurd, а также Linux vs Redox (https://www.redox-os.org).

https://doc.redox-os.org/book/ch04-15-disadvantages.html

А еще похоже для Redox пилят гипервизор, что не может не радовать:

https://www.redox-os.org/news/revirt-1/

https://www.redox-os.org/news/rsoc-2022-revirt-u-1/

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

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

Для Redox хотя бы есть SSH сервер:

https://github.com/redox-os/redox-ssh

, а для Hurd ни dropbear-bin, ни openssh, хрень какая-то :(

https://packages.debian.org/search?suite=all&arch=hurd-i386&searchon=...

А как определить, какие пакеты есть для Hurd в GUIX?

https://hpc.guix.info/browse

Есть там, например, SSH для Hurd Mach?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от Minona

На х86? Линукс победит.

Так никто и не сомневается, вопрос только, насколько? Процент разницы производительности на разных нагрузках, а то гуглится что-то из 2015:

https://www.phoronix.com/review/debian-hurd-2015/3

И ничего полезного в общем-то, хотелось бы какие-то более реальные use cases.

Linux вероятно победит по производительности любое микроядро, вопрос в %%.

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

Так ты же можешь сам на своём железе прогнать тесты фороникса.
Например так (если не критично что не hurd):
Сначала нативно на линуксе.
Потом на этом же ядре под xen-ом в режиме pvh.

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

Интересно сравнить по результатам чужого исследования с затратами одной минуты своего времени на это.

sanyo1234
()
Ответ на: комментарий от hobbit

Ситуация с unDE такая:

Текстовый редактор я написал, но придумав сложную систему отмен, я погорячился - не удобно это и на некоторых типах отмены консистенция БД периодически портится. Я это так и не доотладил, поэтому выкладывать не стал.

Да и вообще на практике мои выдумки в области интерфейсов оказалось как-то не заходят. Есть какие-то простые идеи (вроде перманентной системы отмен как в vim или гарантированный отклик на любое действие < 200 мс) которые следовало бы реализовать во всех полях, но глобально переделать интерфейс и чтобы было удобно - таких идей нет.

Пока не знаю, возможно unDE ещё во что-то переродится, но конкретных очертаний проекта нет. Пока меня заинтересовал neparsy.

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

Вообще удивляюсь, зачем новые оси типа Redox пытаются сразу же запилить для десктопа? Ведь Linux и BSD победили Windows именно на серверах, и только потом на них начал появляться конкурентноспособный desktop.

У Redox уникальные для надежных сервервов фичи типа микроядра, ядро на Rust. Почему бы им сначала не сделать суперский сервер, чтобы не транжирить свои ресурсы на десктоп и всякие программки для него? Потом получили бы финансирование и наняли недорогих кодеров для десктопа.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от ipkirill22x

зубрежка клавиш

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

yu-boot ★★★★
()
Ответ на: комментарий от unDEFER

Может им просто не интересно сервер пилить?

Так модное современное безопасное ядро - это ведь в первую очередь для сервера? Это демонстрация своих способностей в computer science.

VMWare ESXi кстати тоже микроядерный, но по слухам подвержен атаке «escape from guest» :( Еще и проприетарный :(

Надежный безопасный микроядерный open-source гипервизор вместе с ядром на Rust - это было бы действительно уникально и супер. Надо будет, народ сам портирует нормальные полноценные DE типа KDE, Trinity и т.п.

Какой смысл пилить 100500-ый никому ненужный DE с текстовыми редакторами и рисовалками пикселей на фоне всего нескольких популярных и нужных DE? Только ленивый не написал свой форк, их уже примерно столько же, сколько разных CMS для сайтеков.

Зачем распылять свои таланты на всякую ерунду типа DE второго сорта.

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

А по мне так к ядру как раз меньше всего вопросов. Работает само и позволяет процессам работать так быстро как они могут. КолибриОС в виртуалке даже на слабеньком ноутбуке работает супершустро, быстрее чем родное окружение вне виртуальной машины. Так чего ещё не хватает?

Вот к прожорливости браузеров, к скорости запуска таких приложений как Gimp и LibreOffice реально вопросы..

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

А по мне так к ядру как раз меньше всего вопросов.

Так обсуждалось же микроядро. Много ли открытых микроядерных OS, готовых к использованию?

Работает само и позволяет процессам работать так быстро как они могут. ... Так чего ещё не хватает?

Безопасности ессно.

Вот к прожорливости браузеров, к скорости запуска таких приложений как Gimp и LibreOffice реально вопросы..

Так и переделывайте тогда эти приложения, причем тут ядро и новые оси?

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

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

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

Хм, как-то странно, а что

https://packages.debian.org

показывает не все пакеты для hurd-i686 ?

https://packages.debian.org/search?suite=all&arch=hurd-i386&searchon=...

You have searched for packages that names contain openssh-server in all suites, all sections, and architecture(s) hurd-i386.

http://www.freezepage.com/1663400094ONJNTGRNIC

Загрузил образ с сайта:

https://www.debian.org/ports/hurd/hurd-install

wget https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd.img.tar.gz

Запустил, набрал: dpkg -al | grep openssh-server

он мне говорит, что все норм, установлено, и действительно демон sshd запущен ...

Разве так бывает?

А чтобы им этот свой Hurd напару с Mach не переписать на всеми любимом для переписывания ржавом языке программирования ? :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

Ого! Даже OpenRC работает в Debian GNU/Hurd, круто.

Прикольная игрушка с привычными консольными утилитами.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
  • написана не на Си. Оберон подходит в нулевом приближении, но требует допиливания.
  • гораздо проще существующих
  • с нормальной оболочкой, а не с башем (пример хорошей оболочки был хотя бы в OS/2)
den73 ★★★★★
()
Ответ на: комментарий от eugrus

Поддерживаю, с абсолютной раскладкой удобнее. Caps Lock на английскую, Shift+CapsLock на русскую.

Parthen
()

я готов вписаться, выразил все те мысли которые у меня в голове крутились уже давно! правда вот про ядро спорно. линукс же по факту уже почти гибрид.

Unixson
()
Ответ на: комментарий от Parthen

Пакетный менеджер с установкой без зависимостей.

Я вообще считаю что пакетные менеджеры должны умереть как класс. В андроиде и в systemd придумали бесшовные A/B обновления, а в MacOS придумали .app и .dmg. Можно соединить эти два подхода. Системные файлы обновлять через A/B образ, а программы юзера через банальную замену директории. Есть базовые и что главное ОДИНАКОВЫЕ библиотеки, файлы, конфиги из коробки в системе. А все что нужно для запуска сверх этого будь добр положить вместе с программой.

Это гораздо удобнее и дружелюбнее к пользователю. Плюс обратная совместимость не страдает. Шанс ненахода какой-то библиотеки в системе практически нулевой, потому что батарейки уже в комплекте

Unixson
()
Ответ на: комментарий от alex1101

а смысл? подходы то совсем разные. в одном случае ПО размазывается тонким слоем по иерархии, а в другом у тебя условно есть что-то вроде /Applications или C:\Program Files

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

а смысл?

Ну я например не хочу «как в винде» или «как в макоси». Мне проще открыть менеджер пакетов и парой кликов поставить приложение, а не искать его и ставить вручную.

в одном случае ПО размазывается тонким слоем по иерархии, а в другом у тебя условно есть что-то вроде /Applications или C:\Program Files

Это ортогональные вещи. Для винды с её C:\Program Files тоже есть пакетные менеджеры.

alex1101
()
Последнее исправление: alex1101 (всего исправлений: 1)
Ответ на: комментарий от alex1101

Это юзеру проще объяснить и если что удаление или обновление юзерского софта будет отвязано от обновления системы. Следовательно сломать систему установкой или обновлением какого-то пользовательского софта будет не возможно. Собственно как это и произошло у linus tech tips. Когда ubuntu вместо того чтобы поставить стим из-за конфликтов в зависимостях снесла к чертям пол системы.

Мне проще открыть менеджер пакетов и парой кликов поставить приложение, а не искать его и ставить вручную.

Ну так в macOS да и в винде придумали магазин приложений.

Так и еще плюс. Установка софта паралельно, и даже разных версий, без инопланетной мастурбации вроде nixOS или snap

Unixson
()
Ответ на: комментарий от alex1101

Плюс пакетный менеджер не гарантирует консистентность. У пользователей может быть что-то выпилено, что-то добавлено, что-то тупо не установлено и т.д. А так у тебя единый неделимый рутовый образ, который обновляется отдельно и юзеровый раздел где тусят его настройки, программы, фоточки с котиками и т.д. Плюс же можно будет наконец реализовать system-recovery и откат системы на завод, что с пакетным менеджером будет довольно трудно сделать.

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

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

Unixson
()
Последнее исправление: Unixson (всего исправлений: 2)
Ответ на: комментарий от Unixson

линукс же по факту уже почти гибрид.

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

ipkirill22x
() автор топика
Ответ на: комментарий от ipkirill22x

да лол, что там на андроиде это проблема андроида. а на десктопном линуксе есть dkms. поэтому можно всякие блобы ставить практически влет без особых проблем. Андроид вообще не дистрибутив линукса, так от линукса только ядро, и то ядра обратно не совместимые.

А само ядро благодаря dkms стало гибридным. Можно подгружать стороние бинарные модули. Так называемые .ko или kernel object. Никто уже не компеляет ядро

Unixson
()
Ответ на: комментарий от ipkirill22x

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

Как будто что-то плохое, а во вторых, это не проблема ядра. Я ж говорю оно и так гибридное, просто в андроиде решили не заморачиваться и OEM собирает ядро под себя. Хотя например dkms в андроиде все таки есть. Я таким макаром прокинул драйвер сенсора для одного планшета без пересборки системы.

Unixson
()
Ответ на: комментарий от Parthen

ну хорошо, только я предлагаю чтобы их было две. одна пользовательский софт обновляет, другая саму систему. магазин приложений обновляет то что ставит юзер, а система OTA A/B обновит базовый имейдж (считай /)

Unixson
()
Ответ на: комментарий от Parthen

По факту я предлагаю то что ты говоришь

Пакетный менеджер с установкой без зависимостей.

Только я пошел чуть дальше и забрал у пакетного менеждера возможность обновлять системные файлы. Хз как объяснить… Загугли как обновляется android 12, chromeOS или macOS.

Грубо говоря у тебя плеймаркет не обновляет базовую систему (ну там ядро, systemd, pulseaudio и прочую шнягу), а СИСТЕМНЫЕ обновления прилетают в виде второго образа рута который разертывается на соседний раздел и просто подменяется при следующей перезагрузке.

Приложения которые поставил юзер из плеймаркета уже обновляются уже самим плеймаркетом. A/B обновления он не запускает. Это важно

Но опять же там не все так просто. Иногда при A/B обновлениях получают не весь имейдж, а только его дельту. И вот уже ее накатывают на второй раздел. Короче если будет интересно - прогугли.

А в наших с тобой реалиях получается что условно говоря плеймаркеты (apt, rpm, pacman) обновляют не только софт который поставил юзер, но и всю систему целиком. из-за этого случаются коллизии, сломанные пакеты, неразрешимые зависимости, адъ и израиль… От этого нужно избавляться. Плюс стороннему разработчику поддерживать все это apt, rpm, и еще 100500+ различных систем просто будет не нужно.

Unixson
()
Последнее исправление: Unixson (всего исправлений: 2)
Ответ на: комментарий от Unixson

Я в целом согласен, что Линуксу позарез нужно вынести систему в отдельную иерархию и не валить всё в кучу, но:

Следовательно сломать систему установкой или обновлением какого-то пользовательского софта будет не возможно. Собственно как это и произошло у linus tech tips. Когда ubuntu вместо того чтобы поставить стим из-за конфликтов в зависимостях снесла к чертям пол системы.

это по большей части проблема deb-дистрибутивов, из-за чего я их терпеть не могу.

alex1101
()
Ответ на: комментарий от Unixson

Я тут уже предлагал примерную модель, как это можно сделать. Там система лежит в /root/pkg, а пользовательские программы ставятся в ~/Apps (без пароля рута, да), причём недостающие зависимости ставятся в каталог программы и подцепляются к программе через локальные переменные окружения.

Но у всех подобных схем есть минус: будет много дублирования библиотек и прочего. Чтобы его избежать - придётся наворачивать систему дедубликации.

alex1101
()
Последнее исправление: alex1101 (всего исправлений: 1)
Ответ на: комментарий от alex1101

На самом деле, Flatpak - это примерно то, что нужно. И изоляция искаропки, красота. Но у него есть ряд моментов, которые мне не нравятся.

alex1101
()
Ответ на: комментарий от Unixson

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

Это всё ещё идея или ты уже реализовал её?

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

Да у меня есть небольшой проектик на buildroot, я запилил A/B но мне еще нужно систему для установки приложений сделать

Unixson
()
Ответ на: комментарий от alex1101

Да в целом да, только я бы реально вместо /root/pkg просто бы хранил два раздела с основным рутом и с обновленным. А сам рут сделал ридонли. а /Applications я вынес вообще на другой раздел с правами юзера.

будет много дублирования библиотек и прочего. Чтобы его избежать - придётся наворачивать систему дедубликации.

Не придется. Нужно просто в систему добавить раздел /Library/Local. Куда софт сможет закидывать свои либы которые будут переиспользоваться. Для того чтобы вести статистику и самые часто используемые либы закидывать уже в /Library/System в следующих релизах. Но для того чтобы так делать нужно забить максимально /Library/System необходимыми библиотеками. Так например поступили в Valve с их steam runtime

Тем более в любом случае меньше 500 гигабайт винчестер сейчас трудно найти

Unixson
()
Ответ на: комментарий от alex1101

В основном на rust и python. Базовый образ собирается пока что buildroot скриптами. Скоро буду прикручивать докер чтобы было удобнее собирать.

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