Здравей,
Плануваш ли разширяване на проекта и добавяне на повече функционалност/възможности или по-скоро това ще да е форк, а проекта ще си остане minimal?

Поздрави!

[Отговори на този коментар]

Към: Планове
От: Иван Давидов <davidov__dot__i< at >gmail__dot__com>
На: 14-09-2015@19:19 GMT+2
Оценка: 2/Информиращ

Здравей!

Без да се обвързвам със срокове, ето какви са бъдещите творчески планове за проекта:

1) Мигриране от glibc към musl (или друга читава C библиотека). Това ще реши проблема с
неработещия DNS. Това е задача номер едно и е с най-висок приоритет.

2) След това пътят е както при другите live операционни системи - генериране на squashfs
файлова структура и прехвърляне на реалния init процес върху тази структура. В момента
системата не излиза от рамките на initramfs структурата, а целта на упражнението тук е с
помощта на *switch_root* да прехвърлим управлението върху реалната squashfs структура.

3) След това вече е по-лесно - какъвто софтуер се сложи в squashfs файловата структура,
това и ще има на разположение след boot-ване.

Всичко това отдавна е измислено и направено. Точно поради тази причина не си давам много
зор, защото ако направя всичко това, значи просто преоткривам топлата вода. Абсолютно
всички съвременни live системи минават по този път, а по-старите вместо squashfs mount-
ват директно boot media-та. Проблемът е в рамките на initramfs да се открие кое е
устройството, което държи boot media-та, тъй като тази информация *не е* налична по време
на стартирането. Има решение - претърсват се всички mountable устройства, опитваме се да
ги монтираме и търсим нещо специфично, примерно конкретен файл, наличен само в нашата
система.

После проблемът с персистирането на данните от live сесията - почти никой вече не ползва
CD, а squashfs архивите не могат да се променят току така. Затова за любителите на USB
flash хората са измислили Unionfs и AuFS с overlay на няколко файлови структури. И това
вече е измислено, направено е и е налично в много live дисрибуции.

Всеки може да се опита да подобри проекта и да го придвижи в посоката, която желае. Това
е силата на open source - аз имам една визия за развитието на проекта, но утре някой може
да вземе сорсовете и да задвижи нещата в друга посока. Или пък да направи това, което аз
искам да направя, само че по-скоро от мен. Примерно някой студент с повече свободно
време, на който най-големите му проблеми са дали утре ще вземе даден изпит или няма да го
вземе. :)

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

[Отговори на този коментар]

---

Към: Към: Планове
От: go_fire <g__dot__aleksandrov (a) mail__dot__bg>
На: 30-09-2015@9:18 GMT+2
Оценка: 1/Неутрален

Много изчерпателно Иване, поне аз благодаря за разясненията!

• Интересно защо бягаш от glibc? Дори Дебиан се върнаха на него, след като и eglibc свиха знамената. Т'ва musl доколкото помня поддържа малко платформи;

• Каква е причината да мислиш за замяна на BusyBox? Ще правиш версия с Андроид?

• Защо ще ползваш squashfs/unionfs/aufs , след като вече в ядрото си има щатен механизъм? По-зрял е може би?

• Мислил ли си за версия с μLinux? Тази ниша е практически празна. Има само едно дистро, май aLinux се казва и то е с бая стари компоненти. А това е най-лесният път да пренасяме наши програми за онази среда.

Покрай инж. Тони Тошев съм почитател на минималистичните дистрибуции (но за работен плот) и от там изпитвам известна заинтересованост към преименуваният ти проект. Той и мисията си смени де. Особено това за бизибокса ми стана много интересно, защото от него не се отказал дори Tiny, който е еталона за свръхзвукова скорост. Явно не това е мотива.

Пожелавам ти все повече и повече време да имаш за любимото отроче и хоби, без това да накърни доходите ти!

[Отговори на този коментар]

---

Към: Към: Към: Планове
От: Иван Давидов <davidov __точка__ i< at >gmail __точка__ com>
На: 1-10-2015@16:27 GMT+2
Оценка: 2/Информиращ

Бягам от glibc, защото на практика не работи в минималистични и/или embedded системи. Създава много главоболия. Има един куп изписани статии от къде идват архитектурните проблеми там. Накратко - големи хакове са, за да накараш статичното линкване да работи както трябва и да нямаш никакви зависимости към други библиотеки. Иначе си работи прекрасно, когато говорим за пълноценни линукс дистрибуции, спор няма!

В текущите сорсове в GitHub имам успешен експеримент с musl вместо glibc и неработещият DNS вече работи. Проблемът с musl е, че това се пада cross-compiling и изпитвам известни затруднения да накарам musl да използва kernel хедърите, които свалям автоматично. Засега musl разчита на хедърите, които са инсталирани на host операционната система, което не е добър вариант за билдване. Работи си прекрасно, но не е хубаво да е така, защото същите хедъри може да са инсталирани на друго място в някоя друга host среда. И отделно, че хедърите на host системата може да се окажат несъвместими с kernel-а, който се опитваме да билднем. Накратко - и сега работи, но има какво да се доизпипа.

Замяната на BusyBox е само експеримент. Реших да пробвам до колко лесно или трудно ще се получи и дали си заслужава усилията. Е, получи се, но с BusyBox получаваме повече и занапред ще продължа да ползвам него.

За squash и другите неща - не съм влизал в дълбочина каква поддръжка има в ядрото, ще чета и ще гледам, когато му дойде времето.

[Отговори на този коментар]