LINUX.ORG.RU

Интервью с разработчиками KolibriOS в «Компьютерре»

 ,


0

1

В 2001 году финский студент Вилле Турьянмаа написал свою операционную систему на ассемблере. В 2004 году он решил, что тридцатидвухбитные компьютеры погибли, и перешёл на разработку MenuetOS 64 шестидесятичетырёхразрядной версии своей операционной системы. Сообществу это не понравилось, и оно продолжило разработку тридцатидвухбитной версии своими силами. И когда более половины кода было изменено, проект получил название «Колибри» в честь одной из русских сборок систем.

«Компьютерра» побеседовала с двумя разработчиками KolibriOS - Дмитрием Переверзевым и Игорем Солодухой. Они рассказали о возможностях и перспективах операционной системы, написанной целиком на ассемблере.

Переверзев, кстати, отвечает на вопросы в комментариях к интервью под ником Sourcerer.

>>> Разработчики "Колибри" об ОС на ассемблере



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

да ничего ты не объяснил, кучу дуристики понапридумывал, при этом даже не удосужился дочитывать, а если дочитывал, то вникать в то, что я писал. не было у меня ни про архивы, которые надо ставить руками, ни про дубликаты библиотек в памяти, и х@#$ню про синдромы я тебе не писал. ты, встряв, даже не понял, с чего этот разговор начался. а зависимости в Linux — это болезнь, те, кому она нравится — бараны и неадекваты. гуляй.

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

> ты хочешь имхо бредовый и ненужный Семантек Десктоп или как его там, я хочу четко структурированную ФС.

суть в том, что вы оба хотите структурированную ФС, структурированную по-разному. А в дерево такая структура не помещается, хардлинки/симлинки и их обработка, то есть уже API ведут к той же «семантической ФС», и по-нормальному такое можно реализовать с тегами вместо имён файлов и категориями вместо директорий.

дальше что, кто-нибудь третий захочет ФС в стиле Plan 9 acme / rio ctl файлового интерфейса, и перепиливать заново? нафиг-нефиг.

Вместо этого, «семантическая ФС» (ну или, «логическая ФС») кажется логичным выходом.

Например, ещё в Amiga DOS были логические диски и команда ASSIGN. И поиск не в текстовом списке PATH, а в логическом диске PATH. И установка копированием, и самодостаточные либы.

mount -o bind и bind в Plan 9 — это тоже про это, да.

Или, та же приснопамятная MACOSX. Скачали софтинку в образе .dmg, дважды щёлкнули — образ смонтировался на десктопе. Перетащили из образа папку на симлинк на /Applications => софтинка установилась. Перетащили из /Applications в трешъ => деинсталлировалось. Веселуха начинается, конечно, когда софтинке нужны какие-то фреймворки и библиотеки — становится нужной мегаутилита «деинсталлятор».

Что здесь в принципе хорошо, по этим трём подходам (через образ или bind) — что такая связь не обязана поддерживаться постоянно, а может создаваться только на момент запуска.

Ну то есть, пускай будет некоторая «семантическая ФС» или «логическая ФС». Где будут пути ЧПУ (человеко-понятные УРЛы), то есть, как в Plan 9 в ctl файле в rio /acme содержится «глагол», то есть, команда API. Обращение по УРЛу выполнит команду API, лениво подмонтировав все зависимости-ресурсы. Сами УРЛы будут «логическими», не привязаны к конкретному «физическому» экземпляру ресурса.

А обслуживаться вся эта машинерия будет каким-то демоном, сервисом в /proc, или модулем ядра, или через FUSE.

Например, демон запускается, и создаёт в /proc/fs симлинк на /proc/$PID. по /proc/fs/obj/$OBJ находятся «физические» ресурсы, для них создаются симлинки на понятные имена ресурсов в /proc/fs/name/foobar . «Глаголы», то есть функции API выглядят как /proc/fs/do/pkg/foobar/get_lib/libfoo.so, которая тоже симлинк на конкретный $OBJ, конкретную версию библиотеки для этого пакета. Демон, при обращении по «Глаголу» лениво монтирует все нужные ему ресурсы, а потом также лениво (или форсированно по команде) их размонтирует.

Тогда GUI должен работать с этими «логическими» объектами и логическими ресурсами по человеко-понятному ИМЕНИ, а не месту в ФС.

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

> запускается, и создаёт в /proc/fs симлинк на /proc/$PID. по /proc/fs/obj/$OBJ находятся «физические» ресурсы, для них создаются симлинки на понятные имена ресурсов в /proc/fs/name/foobar . «Глаголы», то есть функции API выглядят как /proc/fs/do/pkg/foobar/get_lib/libfoo.so, которая тоже симлинк на конкретный $OBJ, конкретную версию библиотеки для этого пакета. Демон, при обращении по «Глаголу» лениво монтирует все нужные ему ресурсы, а потом также лениво (или форсированно по команде) их размонтирует.

то есть, прозрачно реализуются теги и категории: /proc/fs/name/LFS/filepath/foobar/libfoo.so.3.1415 и /proc/fs/name/MyPKG-FS/pkg/foobar/VERB/do/pkg/foobar/get_lib/libfoo.so которые оба есть симлинк на какой-нибудь объект-блоб /proc/fs/obj/11ac84b474635464

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

Плюс, то, что есть какой-то API для поиска всех backlinks , то есть по коду блоба — все ссылки, которые на него ссылаются (менеджер ресурсов), и какой-то API для перебора и нафигации, поиска (рефлексия по API — тоже через обращение к API по «глаголам», то есть, ЧПУ).

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

зависимости в Linux — это болезнь, те, кому она нравится — бараны и неадекваты

Еще один гуманитарий всё понял.

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

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

Хоть один свой высер сможешь аргументировать-то?

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

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

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

ни про дубликаты библиотек в памяти

Разумеется, у тебя про это не было, ведь это я тебе об этом говорю. Ты же тупой своей головушкой не понимаешь, что если, скажем, в системе один файл libgtk-3.so (4 с половиной метра, между прочим), то в ОЗУ он будет один на все gtk-шные приложения. А вот ежели у тебя у каждой программы своя копия библиотек... то каждая программа и в памяти займет столько места, сколько всё это добро вместе весит.

а зависимости в Linux — это болезнь, те, кому она нравится — бараны и неадекваты

Зависимость тут лишь у тебя — от собственной навязчивой идеи, которая у тебя вызывает припадки некотроллируемой ярости. Посмотри на себя со стороны: брызжущее слюной нечто, несвязно орущее про баранов и неадекватов и про «я так хочу», не могущее привести ни единого технического аргумента в пользу свое идеи. Ты жалок. Если у тебя нет сил или мозгов, чтобы на, внезапно, техническом форуме вести техническую дискуссию по теме, которую ты сам и задал, то избавься же от своей боли самым простым образом: заигнорь меня поскорее и дрочи дальше на свою мечту.

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

> а зависимости в Linux — это болезнь, те, кому она нравится — бараны и неадекваты.

гы-гы-гы.

Причина этой зависимости — так сделан GNU toolchain, точнее динамический линкер ldd из его состава и конкретно пакет binutils. В то время, как люди прозрачно намекают, чо «dynamic linking considered harmful», ибо реализовано это во-первых, как дыра в безопасности, во-вторых, довольно медленно и с кучей накладных расходов, которые не проявляются для хелловордов, но дают о себе знать когда приложение линкуется с 10500 динамических библиотек.

Понятно, зачем так было сделано, все эти version scripts и совместимые API. Чтобы с кучей housekeeping всё это хоть как-то работало, с учётом того, что обновления библиотек и их клиентов, программ производятся поэтапно. И что API между программами ломается не так уж часто.

С другой стороны, сейчас эта идея совсем дискредитирована. Зачем эта костыльная совместимость, и тут же опять linker version scripts?

Нужен был нормальный динамический лоадер по идее, ну например, как в Обероне при загрузке и выполнении нового модуля. И нормальная проверка «совместимого API», библиотеки и приложения.

В крайнем случае, как в тех же AMIGA или Plan 9 — линковать статически конкретную версию, только нужные функции. Ну или смотреть в сторону dietlinux и нормальных Libc, всё таки грузиться за 10 секунд другой ляликс поди и не умеет.

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

начнем с того, что я здесь не говорил «должно быть так», но «мне бы хотелось». то есть это не руководство к действию для всех и каждого, а именно моя «хотелка», как тут писали. по сути я хочу еще один уровень в структуре ФС, который ее несколько усложнит, да, но зато все станет более логичным: система сама по себе, софт, устанавливаемый пользователями, сам по себе. при таком подходе системные каталоги не будут захламляться, этот вопрос уже частично решен в BSD с ее /usr/local. софт не обязательно распространять в образах, достаточно, чтобы он ставился в свой каталог (как сейчас в /opt) и не оставлял своих соплей по всей ФС. если дать возможность пользователю писать в каталог с конфигами программ, например /programs/VLC/profiles(или config)/user1/, то можно избавиться от кучи скрытых файлов и папок в домашней папке.

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

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

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

Разумеется, у тебя про это не было, ведь это я тебе об этом говорю. Ты же тупой своей головушкой не понимаешь, что если, скажем, в системе один файл libgtk-3.so (4 с половиной метра, между прочим), то в ОЗУ он будет один на все gtk-шные приложения. А вот ежели у тебя у каждой программы своя копия библиотек... то каждая программа и в памяти займет столько места, сколько всё это добро вместе весит.

хм, как-то это в Windows работает и неплохо работает.

а зависимости в Linux — это болезнь, те, кому она нравится — бараны и неадекваты

Зависимость тут лишь у тебя

снова по делу ничего не написал.

теперь об анальной боли:

Внезапно возникшая анальная боль

высер

тупой своей головушкой

припадки некотроллируемой ярости

брызжущее слюной нечто

Ты жалок

нет сил или мозгов

дрочи

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

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

я знаю, но у них там все очень медленно происходит :(

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

> по сути я хочу еще один уровень в структуре ФС, который ее несколько усложнит, да, но зато все станет более логичным:

хочу нечто похожее. Чтобы все эти уровни ФС были равноправными, и «логический» или логичный ;-) отличался от «физического» пути в ФС только тем, что обращение к ресурсам по УРЛам == вызов функций API управления ресурсами (менеджера объектов, фабрики класса, семантической ФС), и методов объектов (=обращение к самим ресурсам).

Тогда не важно где физически оно хранится, хоть в .git/obj/SHA1id.
Важно, что есть менеджер ресурсов, который умеет по запросу по логическим именам получать физические объекты-блобы.

система сама по себе, софт, устанавливаемый пользователями, сам по себе.


ну если бы у файла были теги и категории, и часть тегов назначалась бы автоматически по правилам, а часть — назначалась пользователем в ручную, то тогда файлы были бы более понятными. Есть системные файлы, доступные по автоматическим правилам на теги/категории, и есть пользовательские, которые он как-то вручную проаннотировал. Значит, они имеют для него особый смысл и ценность.

софт не обязательно распространять в образах, достаточно, чтобы он ставился в свой каталог (как сейчас в /opt) и не оставлял своих соплей по всей ФС.


http://autopackage.org и его AppFolders?

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


ну какой-то GoboLinux получается, пополам с макосью. Там, кстати, скрытые файлы и папки есть, но они не мешаются под ногами.

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

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

>>если, скажем, в системе один файл libgtk-3.so (4 с половиной метра, между прочим), то в ОЗУ он будет один на все gtk-шные приложения. А вот ежели у тебя у каждой программы своя копия библиотек... то каждая программа и в памяти займет столько места, сколько всё это добро вместе весит.

хм, как-то это в Windows работает и неплохо работает.


плохо, плохо оно там работает. Уж на что динамический загрузчик .SO ELF-ов не идеал, но DLL-ки реализованы ещё хуже.

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

>А есть ещё что-нибудь интересное во флоппи формате? Ну, кроме qnxdemo.
Я малость пошарил, и из заслуживающего внимания нашёл, пожалуй что только paud-2.0.3.img и fbsd-flp-1.1.2.bin.

Pure64 v0.4.9 Distribution.zip
BareMetal v0.5.1 Source.zip
dietlinux-snapshot.iso


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

хочу нечто похожее. Чтобы все эти уровни ФС были равноправными, и «логический» или логичный ;-) отличался от «физического» пути в ФС только тем, что обращение к ресурсам по УРЛам == вызов функций API управления ресурсами (менеджера объектов, фабрики класса, семантической ФС), и методов объектов (=обращение к самим ресурсам). Тогда не важно где физически оно хранится, хоть в .git/obj/SHA1id.

ну это бы было совсем круто. что-то подобное пилят?

http://autopackage.org/

не открывается

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

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

/programs
/programs/VLC
/programs/VLC/bin
/programs/VLC/config
/programs/VLC/lib
/programs/VLC/man
/programs/VLC/plugins
/programs/VLC/share
ibraim
()
Ответ на: комментарий от goingUp

:) нет, у меня Kubuntu все время была, дело не в этом. дело в том, что когда пытаешься поставить в Fluxbox апплет индикатора клавиатуры из GNOME, а Synaptic тебе предлагает в зависимостях gnome-session и 350МБ для загрузки, начинаешь задумываться.

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

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

ibraim
()

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

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

Может вам еще и скриншот нотариально заверенный? Или у вас ЧЮ атрофировано и вам теги расставлять надо?

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

> снова по делу ничего не написал.

Самокритично, но верно. Ты и не можешь.

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

> :) нет, у меня Kubuntu все время была, дело не в этом. дело в том, что когда пытаешься поставить в Fluxbox апплет индикатора клавиатуры из GNOME, а Synaptic тебе предлагает в зависимостях gnome-session и 350МБ для загрузки, начинаешь задумываться.

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

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

> хм, как-то это в Windows работает и неплохо работает.

Что «неплохо работает»? Установи 2 gtk-шных приложения в винду, и у тебя неявно будет 2 копии libgtk. Установи 3 приложения — будет 3. Запусти 3 этих приложения и получи разные копии одной библиотеки в 3-х разных процессах. Чтобы была одна копия вместо трёх, нужно программы слинковать динамически, а библиотеку положить в \windows\system32.

А что касается библиотек самой системы, то винда потому и весит одна только без приложений несколько гигов, что идет со всеми версиями всех библиотек, COM-объектов и прочих компонент, которые в ней когда-либо были. Потому что есть софт, который со всем этим добром динамически слинкован. То, что однажды попало в папку \windows в релизе системы, остаётся там навечно во всех последующих релизах. Истинная помойка.

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

>смысл избавляться от конфигов в домашней папке тот же
Представь, что в системе работают несколько юзеров.
В конфиге хранятся приватные данные.
«Глобально» устанавливать/удалять программы могут только юзеры с определенными правами.

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

Админ «глобально» установил VLC, добавил несколько пользователей. Пользователи захотели запустить VLC.
Предлагаешь делать хитропопые хуки с правами при добавлении/удалении каждого пользователя?
А если админ задумал удалить VLC, что делать с конфигами пользователей?

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

> BareMetal v0.5.1 Source.zip

Любопытно, спасибо. Судя по сишной либе, похоже они более трезво смотрят на окружающую реальность. Хотя CP/M-овская команда dir в написанной с нуля системе смотрится забавно.

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

> Админ «глобально» установил VLC, добавил несколько пользователей. Пользователи захотели запустить VLC.

отлично, при первом запуске в /programs/VLC(например)/config/ создается папка с именем пользователя. он может в нее писАть.

А если админ задумал удалить VLC, что делать с конфигами пользователей?

папка /programs/VLC/config по умолчанию остается, можно сделать запрос при удалении «Удалить конфигурационные файлы?» и если ответ будет «Да», снести и ее.

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

> отлично, при первом запуске в /programs/VLC(например)/config/ создается папка с именем пользователя. он может в нее писАть.

И кто её создаст?

папка /programs/VLC/config по умолчанию остается, можно сделать запрос при удалении «Удалить конфигурационные файлы?» и если ответ будет «Да», снести и ее.

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

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

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

ИМХО, очень не хорошая идея.

Лучше договориться и выделить отдельную совместную папку вида /home/user/«all_configs» и т.п.

В вашем случае надо бэкапить весь /programs или вручную трахаться с каждой подпапкой /programs/VLC/profiles по мере необходимости. А зачем /programs бэкапить, если можно в случае чего перескачать пакет из менеджера?

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

>создается папка с именем пользователя
Т.е. имеем потенциальную дырку.
И так для каждого пользовотеля, программы?

«Удалить конфигурационные файлы?»

В системе 3 пользователя с правами рута.
Каждый 2 месяца настраивал .gtkrc.
Тут, вдруг, решили, что GTK идет лесом.
Еще раз: что делать с конфигами?

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

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

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

> Лучше договориться и выделить отдельную совместную папку вида /home/user/«all_configs» и т.п.

можно и так. в любом случае, то, что сейчас творится в /home/username/, — это ужас.

В вашем случае надо бэкапить весь /programs или вручную трахаться с каждой подпапкой /programs/VLC/profiles по мере необходимости. А зачем /programs бэкапить, если можно в случае чего перескачать пакет из менеджера?

зачем трахаться? зачем бэкапить? в подавляющем большинстве случаев я настраиваю программы из GUI, не прибегая к правке конфигов, не все ли равно, куда инфа пишется, в хомяк или в другую папку?

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

Почему файлы пользователя исчезают при удалении программы?

Потому, что это так в венде реализовано. Вот захотелось /users прибить гвоздями к диску «Цэ», так и ипитесь!

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

Я имел ввиду не «общие для всех пользователей», а «общие для нескольких программ».

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

> Потому, что это так в венде реализовано. Вот захотелось /users прибить гвоздями к диску «Цэ», так и ипитесь!

В винде есть точки монтирования во-первых. И можно при создании пользователя указать путь к его хомяку во-вторых.

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

> зачем трахаться? зачем бэкапить? в подавляющем большинстве случаев я настраиваю программы из GUI, не прибегая к правке конфигов, не все ли равно, куда инфа пишется, в хомяк или в другую папку?

Ну и настраивай все ПО заново после сбоя винта. Действительно, «зачем трахаться»? Лучше еще раз переконфигурировать Шindoшs!

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

> Т.е. имеем потенциальную дырку.

почему? доступ у пользователя user1 есть только к папке /config/user1.

В системе 3 пользователя с правами рута. Каждый 2 месяца настраивал .gtkrc. Тут, вдруг, решили, что GTK идет лесом. Еще раз: что делать с конфигами?

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

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

> почему? доступ у пользователя user1 есть только к папке /config/user1.

Еще раз. Кто создаст каталог?

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

> разница в красивой структуре файлов и бардаке, который сейчас.

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

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

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

В системе 30 пользовательских акаунтов. Админу надо удалить 4 пакета. Вопрос: сколько чекбоксов он увидит?

geekless ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.