LINUX.ORG.RU

Моё видение важных фич, в настоящее время отсутствующих в экосистеме СПО

 , , ,


1

2

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

Интероперабельность по файловым системам между разными ОС

Реализация полной поддержки ext4 для ядер FreeBSD, NetBSD и ReactOS/NT.

Реализация полной поддержки UFS/FFS для ядер Linux и ReactOS/NT.

Реорганизация исходного кода glibc и вынос оттуда логики сервисов в демоны

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

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

Это позволит собирать программы полностью статически, при этом гибко используя любые фичи ОС, предоставленные этим модульным механизмом. (А на него много чего завязано, от резолвинга DNS, до перечисления юзеров в системе.) А также улучшит интероперабельность между дистрибутивами.

Это позволит также использовать полный набор фич, предоставленных механизм Name Service Switch, для приложений, которые вообще не используют glibc.

Универсальный формат бинарника для запуска на разных ОС и универсальное ABI, отвязанное от конкретного ядра

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

Однако этот проект имеет недостатки:

  • Для главной разработчицы всё это какая-то игрушка, разработка ведётся без конкретных целей и задач. Иными словами, я такой разработчице не доверяю. Нужен кто-то более серьёзный, если закладываться на проект как на важный инфраструктурный элемент.
  • Проект ставит целью сборку только полностью статических бинарников, таким образом ABI в них отсутствует. Хотелось бы видеть ОС-независимую реализацию модульной экосистемы, с возможностью грузить *.so точно так же, как это делается в обычных ОС.

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

Я полагаю, в 2024-м вполне осмысленно ставить такого рода задачу, а не складывать все яйца в одну корзину и не закладываться на одно единственное ядро.

Применение pacman и makepkg для дистрибутивов с фиксированным релиз-циклом

Из всего зоопарка пакетных менеджеров, по моему опыту самым беспроблемным в эксплуатации является pacman и лёгким для создания пакетов. Хотелось бы видеть на нём действительно разные ОС с разным подходом к релиз циклу, а не просто респины Арча.

Было бы интересно увидеть мета-дистрибутив, который объединяет все перечисленные наработки, предоставляя возможность использовать ядра Linux/FreeBSD/NetBSD и при этом имея прикладное ABI, отвязанное от ABI ядра.

★★

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

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

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

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

Пока что нет острой необходимости, и как следствие мне лень. Если бы кто-то уже работал в этом направлении, я бы наверное присоединился пул-реквестами.

wandrien ★★
() автор топика

glibc … механизм Name Service Switch

Это сделано специально, чтобы не использовалась статическая линковка. Вылечить это можно только полным форком всего проекта GNU. Заодно и Autotools замените, как вы хотите.

Shushundr ★★★
()

Интересный тред.

Оновная проблема вот в чём

Рака не интересует, что делает лебедь и щука.
Щуку не интересует, что делает рак и лебедь.
Лебедя не интересует, что делает рак и щука.

Forum0888
()

Моё видение влажных фич

Вот так я изначально прочитал. ☺

Реализация полной поддержки ext4 для ядер FreeBSD, NetBSD и ReactOS/NT.

Как пользователь FreeBSD я не вижу пользы от "чуждой" файловой системы по ряду причин:

  1. Во FreeBSD используется несколько иной ACL, не совместимый с тем, который в Linux;
  2. Для тех, кто использует linuxulator (я в их число не вхожу), код из Linux может быть опасен (всё тот же бэкдор в xz-utils, например), если они надумают смонтировать Ext4 в боевую систему.

Реализация полной поддержки UFS/FFS для ядер Linux и ReactOS/NT.

См. п.1 выше.

Универсальный формат бинарника для запуска на разных ОС и универсальное ABI, отвязанное от конкретного ядра

Ты точно хочешь портировать вредоносный xz-utils на *BSD! Пшёл отсюда, вредитель! Не видать тебе миска рис и кошкожена! ☺

mord0d ★★★★★
()

Проще быть там где все работает. Линукс умеет в ntfs и прочее. Glibc не единственная - есть musl который делает поменьше компоненты и памяти жрется меньше. Опять же это линукс. Старые ядра бсд нет смысла пулять везде где можно. Проще установить 9front и запускать линуксовые программы отьуда, но с драйвера и там беда, а потому линукс интереснее. Копошение с pacman-ом ненужно так как мета дистрибутив должен уметь собирать из исходников потому что разные процессоры имеют разные наборы инструкций. Применение одного типа бинарника бесполезно из-за жора места на диске. Жесткие диски не в моде. Проще сделать пакетный менеджер под разные ядра. Универсализацию пилили в Plan9, но без браузера там делать особо нечего. А вот прицепить ядро линукс возможно. Но мало кому нравится rio. А потому опять больше линукса ненужно ничего. Wine и так запускает почти все. Протон стимовский с играми справляется и на прикладном уровне этого достаточно.

anonymous
()

Реализация полной поддержки ext4 для ядер FreeBSD, NetBSD и ReactOS/NT.

Реализация полной поддержки UFS/FFS для ядер Linux и ReactOS/NT.

А нафига это всё? Ext4 под венду и так портирована. Под *BSD её не очень хотят без полного запиливания с нуля, потому что лицензия. Ну и я сомневаюсь, что кто-то захочет *BSD грузить с ext4.

С UFS/FFS под Linux интереснее, потому что если мне память не изменяет, UFS под разными BSD не слишком совместимы друг с другом, потому что там вагон расширений.

Есть одна универсальная файловая система, которая работает и под Linux, и под FreeBSD, и даже под вендой. Называется… ZFS!

В копилку, лялексу нужен адекватный IPC. А не DBus.

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

Лет 5 уже на салфетках рисую черновики своего ололо-проекта на пхп, и дальше салфеток он не сдвигается. А ты просишь окунуться в кровавый ад файловых систем. Ненене, спасибо.

anonymous
()

Чтобы что?

Про glibc ещё как-то аргументировано, но не понятно насколько проблемы с переносимостью между дистрами связаны именно с плагинам glibc.

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

На ловца и зверь бежит

Божечки, чо я нашел, копаясь в репозитории пакетов NetBSD:

https://www.defora.org/

Multi-purpose Operating System

Kernel-independent, networked and secure infrastructure

  1. Innovative foundation

The main goal is to provide ubiquitous, secure and transparent access to one’s resources. This is not limited to data, with the possibility to resume applications running remotely.

  1. Cross-platform framework

The system features a POSIX-compliant environment, and is already able to function on top of most Linux, *BSD or Solaris-based systems. Developed with simplicity and efficiency in mind, it is suitable for modern embedded platforms as well.

  1. Desktop environment

The project is also focused on usability, coherence and integration, and therefore featuring a number of desktop applications. Although already intended to be useful on current systems, they eventually benefit from DeforaOS’ own set of features.

  1. Cutting-edge platform for today’s needs

This experimental project has the ambition to address a number of recurring issues with contemporary Operating Systems, with the re-design of most of their components.

Additionally, even though the system is kernel-agnostic at the moment, a dedicated micro-kernel may also be useful at some later stage.

Судя по гитхабу, оно шевелится: https://github.com/DeforaOS

Вот это я понимаю годные вещества. Уважуха. Это вам не KDE с qt5 на qt6 переписывать.

wandrien ★★
() автор топика

Забавно, что наиболее осмысленный и имеющий отношение к реальности пост сделан первого апреля. В течение года какой только фигни не писали, что в «этих наших линуксах» «не так».

С тем, что именно эти вещи самые важные, я лично согласиться не могу. Да и идея с демоном для glibc странная. Но высказанное по крайней мере не вызывает фейспалмов, каковые обычно бывают от постов подобного жанра.

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

Да и идея с демоном для glibc странная.

Почему?

Нас же не удивляет, что X11, Wayland, DBus, PA и еще много чего имеют протокол общения серверной и клиентской части через сокет.

Вот в этой штуке:

$  cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

нет ничего приципиально иного, что требовало бы прогрузки в адресное пространство процесса.

Сильная и немотивированная связность по so вместо использования IPC — это почти всегда плохо.

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

Сама по себе идея интересная, но на мой взгляд, этому не место в стандартной библиотеке языка. Да и не glibc единым жив опенсорс, есть ещё musl как минимум, плюс другие, менее популярные реализации. Уж скорее этому в ядре место, нежели в libc.

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

Дело в том, что в стандартной библиотеке присутствуют соответствующие API. Чтобы эти API реализовать, есть только 3 варианта:

  • Захадкодить всё как musl и старых Unix.
  • (Первый этап инкапсуляции) Вынести в so файлы и приложить к ним конфиг, как в glibc и в Соляре.
  • (Второй этап инкапсуляции) Определить протокол, в который будут транслироваться эти API, и забыть о деталях реализации в рамках libc вообще.
wandrien ★★
() автор топика
Ответ на: комментарий от CrX

К сожалению, платформа Linux растёт из GNU, а GNU, скажем честно, это плохая архитектура.

Это «хакерская» перепись на скорую руку коммерческих Unix из 80-х и начала 90-х. Временами в качестве кода — вплоть о ужасной.

Конкретно, в реализации nsswitch ничего ужасного нет. Однако когда в Ultrix сделали что-то типа современного nsswitch, это тогда было прорывом.

А когда GNU копирует идею и 30 лет тащит её, не замечая проблем сильной связности — вот это проблема подхода к разработке.

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

в экосистеме СПО

У этого СПА нет экосистемы, а есть бардак.

Реализация полной поддержки ext4 для ядер FreeBSD, NetBSD и ReactOS/NT.

Зачем? Если заставить Мерседес ставить то же самое что ставит БМВ - какой резон тогда выбирать Мерседес или БМВ? Если NT станет поддерживать ext4 - это даст ей +1% преимуществ.

Реорганизация исходного кода glibc и вынос оттуда логики сервисов в демоны

А вот это правильно. По-хорошему любой мало-мальски фреймворк или сервис обязан иметь свое API на сокете или порту, через который его можно будет дергать, без привязки к ЯП. Это приведет к увеличению числа программистов для системы, и уберет зоопарк модулей.

Универсальный формат бинарника для запуска на разных ОС

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

Применение pacman и makepkg для дистрибутивов с фиксированным релиз-циклом

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

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

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

Бинаря от Васи Пупкина?

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

Бинаря от Васи Пупкина?

Ну если Вася Пупкин напишет программу и скомпилит ее - то почему бы и нет?

https://vlc.com/windows/vlc.exe

https://vlc.com/unix/vlc.elf

https://vlc.com/source/vlc.tar.gz

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

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

Дзя Тан из xz передаёт привет. Ничему вас история не учит.

Я не совсем понял о чем ты и чему должна научить история.

Я говорю о создании единого репозитория. Это ничем не отличается от убунтового, дебианового, pip и так далее. Просто другой адрес, больше размер, меньше фрагментация.

windows10 ★★★★★
()

самым беспроблемным в эксплуатации является pacman и лёгким для создания пакетов.

Есть ли у него набор готовых «макросов», например, как в rpm, для выполнения типовых задач?

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

Сборщики OpenSSL из Debian тоже передают привет - https://lists.debian.org/debian-security-announce/2008/msg00152.html

А сборка программ не их разработчиками порождает дублирующую работу сборки под Arch/RH/Debian/Ubuntu/etc.

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

ы?

Здесь нет противоречий.

Когда у тебя один исполняемый файл подвязанный только на архитектуру процессора - отпадает смысл иметь отдельный репозиторий на каждый пердеж. Можно иметь просто repo.linux.org и с него скачивать.

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

windows10 ★★★★★
()

Было бы интересно увидеть мета-дистрибутив, который объединяет все перечисленные наработки, предоставляя возможность использовать ядра Linux/FreeBSD/NetBSD и при этом имея прикладное ABI, отвязанное от ABI ядра.

Предлагаю посмотреть на это с другой точки зрения: https://wiki.freebsd.org/LinuxKPI.

UPD: мой посыл в том, что не придумывать себе задачу, а делать то, что нужно ещё вчера.

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

Линукс даже сам с собой не совместим по драйверам. Убегающая мишень.

Это не значит, что не надо делать.

Фряха всё больше превращается в дистрибутив линукса.

Железа много, программистов мало. Это один из способов поддерживать как можно больший охват малыми силами.

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

Железа много, программистов мало.

Даже если рассматривать самую базовую часть линукса - ядро и зависимые от него библиотеки,такие как glibc - то на написание этого ушло пару десятков лет. И то не все серьезные вопросы решены (графическая подсистема как пример).

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

watchcat382
()

Реализация полной поддержки ext4

И в обратную сторону нормальную поддержку NTFS, плиз. Вместо двух одинаково глючных реализаций сейчас. Больше вымораживают даже не мелкие глючки при интенсивной записи, это можно пережить, а что после захода в шинду потом замучаешься чтобы виндовый диск ПРОСТО б..дь подхватился в линуксе.

yu-boot ★★★★
()

FreeBSD, NetBSD и ReactOS/NT

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

UFS/FFS

зачем оно нужно, какие задачи решает? Я вот понимаю зачем нужно ext4, btrfs, exfat, ntfs, даже hadoop понятно для чего нужен, а тут что за зверь?

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

Сишку вообще надо медленно выносить из ОС. В большей части мест где она сейчас используется она не нужна. Даже c# через дотнет в линуксе и тот более хорошо смотрится чем сишка где-то в 80% текущего кода, но да глибси надо переписывать, там всё плохо

ABI

Не получится, с ним не просто так проблемы.

peregrine ★★★★★
()

pacman
Хотелось бы видеть на нём действительно разные ОС

Немного не в тему. Существует скрипт pacapt, позволяющий в разных дистрах запускать привычную команду pacman.

В теории, неплоха идея запускать на LiveCD разных дистров, чтобы не запоминать все эти apt, yum, dnf и т.д., и ключики к ним. Но на практике, слишком много ручных действий требуется. Конечно, если уметь в скоропечатание, то… )

krasnh ★★★
()