Eximius OS – mój system marzeń

Jak samo określenie zobowiązuje, jest to system zrodzony w mojej bujnej wyobraźni i póki co działający tylko na tej konkretnej i dość powiedzieć: specyficznej platformie. Jako informatyk serwisant, kiepski programista, qa tester i artysta, wydaje mi się dostrzegać kilka do tej pory nierozwiązanych problemów jakie trapią bez wyjątku wszystkie obecne systemy operacyjne. Jeśli nie szkoda ci czasu na ten przydługi i stylistycznie pełen błędów przekaz pewnej idei to zapraszam do lektury. :)

Systemy plików

Zacznijmy od systemu plików. Choć obecnie wiodące NTFS, HFS+, UFS2, EXT3/4, XFS nie są złe, to wszystkim im brakuje jednej, szalenie istotnej cechy. Mianowicie kontroli wersji plików, czyli przechowywania np. w formacie delta wszystkich kolejnych zmian licząc od czasu daty utworzenia. Tak aby użytkownik mógł w każdej chwili przywrócić poprzednią wersję, zachowując przy tym możliwość całkowitego wyłączenia tej funkcji i wyczyszczenia historii zmian (czyli de facto nałożenia wszystkich kolejnych łatek na pierwszą wersję, zastąpienie jej i usunięcie patchy). Pewne nadzieje można pokładać w BTRFS i ReFS, które niestety wciąż są w powijakach, zaś problemy licencyjne uniemożliwiają ludzką implementację ZFS po za piaskownicą rodziny BSD.

Na przenośne nośniki flash przydałby się lekki i szybki system plików, niepomiernie bardziej odporny na uszkodzenia niż FAT32 i bez jego absurdalnych (z dzisiejszego punktu widzenia) ograniczeń. Aby miało to sens, powinien być otwarty i darmowy tak żeby jego wdrożenie było jak najtańsze dla producentów telewizorów, odtwarzaczy multimedialnych, konsol, tabletów, telefonów itp. a tym samym aby miał szansę się upowszechnić.

Drzewo i ustawienia

Kolejna bolączka bez wyjątku wszystkich OS‑ów jakie kiedykolwiek stworzyła rasa ludzka, a z którymi nieraz musiał zmierzyć się tzw. power user. Oczywiście chodzi o drzewo katalogów, w Windowsie ekstremalnie nielogiczne, ale w *.nix-owych systemach wcale niewiele lepsze (oczami wyobraźni już widzę te skrzywione miny „ortodoksów” złowieszczo wypowiadających: „że jak to?” „że niby że w moim że we wypieszczonym Pingwinie nielogiczne, że tak!?”). Czy zastanawiałeś się kiedyś do czego służy każdy - dosłownie każdy - z tych folderów, co przechowuje, co je stworzyło i w jakim celu? Potrafię sobie wyobrazić, że nie tylko mało kto się nad tym kiedykolwiek zastanawiał, ale że kogokolwiek to obchodzi. I bardzo niedobrze! To właśnie między innymi dlatego przeciętny zjadacz chleba nie rozumie działania swojego systemu i zwyczajnie boi się nie tylko zmieniać cokolwiek, ale nawet zaglądać gdziekolwiek.

Powyższa rycina idealnie przedstawia to o czym pisałem, czyli CHAOS. A jak to wygląda na Linuksie? Odrobinę lepiej, ale wciąż nieidealnie (szczególnie głębiej).

Z ustawieniami systemu i programów też jest problem. Kolejny raz znęcając się nad Windowsem, wypomnę mu niezdecydowanie: "%APPDIR%" (to akurat nie jest zły pomysł i zależy od dobrej woli dewelopera), "%HOMEPATH%\<użytkownik>\AppData\", "C:\ProgramData\" i oczywiście najgorsze z możliwych miejsce, wisienka na torcie, nieśmiertelny rejestr - zbiór enigmatów. Wraz z integracją w Windows 8 nowego środowiska WinRT, być może doszły kolejne tajemnicze miejsca - tego już nie wiem.

A jak jest u pingwina? Wszystkie pliki konfiguracyjne to pliki tekstowe, zwykle bogato „okomentowane” jak również zwykle z przystępnie wymyślonymi parametrami. I byłoby już całkiem w porządku gdyby każdy programista trzymał się zasady wrzucania konfiguracji per user do "$home/.config", ale oczywiście tak nie jest i mamy kolejny... CHAOS.

W takim razie jak to powinno wyglądać wg. Przemka?

1. Zacznijmy więc od samego dołu. Tutaj rewolucji brak (może po za położeniem jąder).

/boot/
	bootloader
	kernel-4.0-build221
	kernel-4.1-build265
	kernel-4.1-build267

2. Cache, jak sama nazwa wskazuje, pełniłoby taką samą funkcję jak "/tmp" w Linuksach. Można by tam też umieścić plik wymiany jak w Windows (lub w Linux jeśli zrezygnujemy z partycji swap na rzecz pliku).

/cache

3. Home, wzorem Linuksa zawierałby wszystkie dane użytkownika i najlepiej gdyby znajdował się na innej partycji niż boot i system. Z tą jednak różnicą, że osadziłbym w środku jeszcze jeden poziom, dzieląc na katalog ze wszystkimi danymi, które użytkownik sam wgrywa, katalog z licencjami gdzie komercyjne programy generowałyby klucze aktywujące i katalog z tylko jednym folderem zarezerwowanym dla każdego programu z osobna.

Zalety takiego podziału są następujące:

• użytkownik nie miesza ustawień programów ze swoimi danymi i niczego nie trzeba przed nim ukrywać (atrybutami w systemie plików jak w Windows lub kropką jak w Linux)
• użytkownik mógłby skasować folder z ustawieniami programu aby przywrócić w ten sposób ustawienia domyślne, jednocześnie bez obawy że skasuje klucz aktywacyjny np. Photoshopa
• użytkownik w prosty sposób mógłby przenosić ustawienia programów pomiędzy komputerami
• użytkownik byłby w stanie określić miejsce gdzie program przechowuje ustawienia i jednocześnie być pewnym że tylko tam
• ułatwiałoby użytkownikowi odnalezienie ustawień programu (obowiązkowy format nazewnictwa aby żaden z deweloperów nie mógł z lenistwa się wyłamać i zepsuć idei ;))

/home/
	przemek/
		data/
			Dokumenty/
			Filmy/
			Muzyka/
			Pobrane/
			Pulpit/
			Zdjęcia/
	licenses/
		<nazwa firmy>@<nazwa programu>.lic
	settings/
		<nazwa firmy>@<nazwa programu>

4. Inspiracją do podziału systemu były pingwiny i systemy operacyjne konsol (pomijając OS X360 gdzie horror jest jeszcze większy niż na zwykłym Windows – ale tym przynajmniej z założenia nikt ma nie zaglądać do trzewi).

Folder "binaries" jak sama nazwa wskazuje, przeznaczony byłby na programy. Podoba mi się *nix'owa filozofia jeden program = jedno zadanie, więc byłoby to miejsce zamieszkałe przez takie same leśne *.elf-y jak właśnie we wszystkich Linuksach. W takim razie po co "containers"? Ponieważ nie tylko podoba mi się idea kontenerów, ale uważam to za jedyną szansę popularyzacji jakiegokolwiek systemu operacyjnego. Otóż chyba bezdyskusyjną bolączką Linuksa są zależności bibliotek i różnice w dystrybucjach, a co za tym idzie mnóstwo zmarnowanego czasu osób zajmujących się paczkowaniem. „Ale jak to? Przecież każdy deweloper może linkować statycznie!” Może, ale nikt tego nie prawie robi. Można też kompilować ze źródeł co jest w zasięgu nawet początkującego użytkownika, gdyby opakować mu to w przystępne GUI. Niestety często bywa tak, że z jakiegoś powodu skompilować się nie chce i ten etap jest już nie do przebrnięcia dla takiej osoby. I po co zresztą ją tym obarczać? Wszystkie te problemy rozwiązuje konteneryzacja. Są oczywiście spore wady tego rozwiązania, takie jak np. marnowanie miejsca czy „wersjonowanie”. Moim zdaniem, jednak zalety przyćmiewają te wady – poza tym nie twierdzę że warto „kontenerować” dosłownie wszystko. Absolutnie nie! To jest rozwiązanie dobre przede wszystkim dla komercyjnego oprogramowania, ponieważ jest tańsze w utrzymaniu i łatwiej trafić z programem do klienta jeśli ten wie, że nie będzie problemu z jego instalacją i działaniem (jak na Windows czy OS X). Pierwszy krok w tej materii poczynił Cannonical ze Snappy w Ubuntu dla zapowiadanej wersji IoT (systemów mobilnych nie biorę pod uwagę, tam w kontenerach jest kod zarządzany, rzadko natywny). Po za tym po stronie środowiska graficznego można dać użytkownikowi wybór czy w przypadku zduplikowanych bibliotek używać tych z kontenera czy z systemu. W "drivers" i "libraries" znajdowałyby się oczywiście sterowniki i biblioteki.

Do podfolderu "old" system wrzucałby stare wersje po aktualizacji, po to aby nie pozbywać się starszych wersji „na w razie czego”. Oczywiście możliwe byłoby oczyszczenie tych folderów jako jedna z opcji w panelu zarządzania system lub zastąpienie nowszych wybranymi starszymi.

W "logs" znajdowałyby się wszystkie logi systemu, w "resources" zasoby itd. W "settings" ustawienia globalne programów, czyli domyślne, które zawsze byłyby duplikowane do katalogu użytkownika przy pierwszym uruchomieniu lub w przypadku kiedy użytkownik je skasował (ewentualnie po uzyskaniu praw roota, mógłby zastąpić domyślne swoimi z profilu aby każdy użytkownik mógł je odziedziczyć).

Jak widać cała struktura jest prosta, intuicyjna i nie wymaga żadnej wiedzy do zarządzania zawartością. Podkreślam: żadnej.

/system
	binaries/
		old/
			<nazwa programu>.bin
		<nazwaprogramu>.bin
	containers/
		old/
			<nazwa firmy>@<nazwa programu i wersja>.box
		<nazwa programu>.box
	drivers/
		old/
			<nazwa firmy>@<nazwa lub identyfikator urządzenia plus wersja>.drv
		<nazwa firmy>@<nazwa lub identyfikator urządzenia plus wersja>.drv
	libraries/
		old/
			<nazwa biblioteki>.lib
		<nazwa biblioteki>.lib
	logs/
		<przykład>.log
	resources/
		fonts/
			<przykład>.otf
		icons/
			<przykład>.svg
		themes/
			<przykład>
		sounds/
			<przykład>.ogg
		wallpapers/
			<przykład>.png
	settings/
		<nazwa firmy>@<nazwa programu>/
		system/
			<przykład>.conf

Abstrakty

Jak wszystkim wiadomo katalogi nie istnieją, a pliki rozrzucone są po różnych sektorach na nośniku, niekoniecznie ze sobą sąsiadujących. Aby homo sapiens sapiens potrafił tymi danymi łatwo operować wymyślono abstrakt w postaci pliku, a zaraz za nim folderu. W dzisiejszych czasach nieśmiało dochodzą kolejne w postaci bibliotek (oczywiście nie w programistycznym tego słowa znaczeniu) implementowanych zupełnie od siebie niezależnie w różny, raz lepszy a raz gorszy sposób.

Zwykle, szczególnie na systemach mobilnych, jest to z góry wydzielony folder (o którego istnieniu użytkownik nigdy się nie dowiaduje) na np. zdjęcia i abstrakt ten służy do przymuszenia nieszczęśnika aby trzymał swoje np. zdjęcia tylko w tym jednym konkretnym miejscu. A jak to wygląda na "biurkach"? Z racji większej otwartości nie ma jednego wspólnego formatu/zasobu tylko każdy program robi to po swojemu. Jeden wszystko to co jest dodane do biblioteki z dowolnego miejsca, od razu przenosi do miejsca które wybrał owy program, inny natomiast tylko dodaje sobie w menu odnośnik z którego miejsca ma zaczytywać plik, jeszcze inny w ogóle nie przechowuje listy plików i dodatkowych meta danych, a po prostu zaczytuje dane z przypisanego miejsca.

Dlaczego by nie połączyć tych pomysłów w jeden? Dlaczego by już na etapie instalacji systemu operacyjnego nie definiować ścieżek do przechowywania zdjęć, filmów, dokumentów etc? Na Windows można przenieść np. Moje Dokumenty w inne miejsce, na Linuksie podobnie. Rzecz jednak w tym, że brakuje mechanizmu w managerach plików i dashboardach, który by po wybraniu np. "Kasia.jpg" zapisanego w Pobrane, nie tylko proponował przeniesienie go do Zdjęć, ale także dodawał do biblioteki która opisywałaby plik (cache'owane miniatury, dane z EXIF, daty utworzenia/modyfikacji, wybrany opis użytkownika, tagi etc.). Podobnie rozwiązanie jest już w OS X. Brakuje też możliwości zmiany miejsca rozpoznawanego przez system jako miejsce na wspomniane zdjęcia – czyli nie z poziomu każdej aplikacji z osobna tylko w systemie operacyjnym, z którego to programy dowiadywałyby się o położeniu tychże zdjęć.

Byłoby to w mojej ocenie nie tylko wygodniejsze, ale znacznie bardziej intuicyjne dla zwykłego użytkownika, któremu na dodatek łatwiej byłoby utrzymać porządek w swoich danych. Ubezwłasnowolnia? Przecież nikt nikogo nie zmuszałby do używania tej funkcji (definiowanie bibliotek, generowanie miniatur i przechowywanie meta danych powinno być możliwe do wyłączenia w opcjach).

Bezpieczeństwo

Jak wszystkie szanujące się OS‑y, tak mój „zrodzony z burzy” Eximius powinien posiadać system kontroli uprawnień. Akurat w tym przypadku nie ma sensu wymyślać koła na nowo i z powodzeniem można by przeszczepić to do czego przyzwyczaiły nas do tej pory NIX'y.

Wszystkie programy musiałyby posiadać cyfrowy podpis, który przy uruchomieniu winien być sprawdzany. Jeśli jest niepoprawny, nie mógłby przejść autentykacji, a tym samym nie mógłby zostać uruchomiony. Nagle rozległy się złowieszcze głosy dochodzące gdzieś z piwnicy: „Skandal! Więzienie! Precz z tym na komórki!” I wszystko się zgadza... Jednakże użytkownik mógłby być w tym momencie zapytany o zgodę (coś na wzór UAC w Windows) i w jakiś wyjątkowo sugestywny sposób poinformowany, o możliwości zgładzenia systemu przez nieznany zlepek bajtów, które właśnie próbuje ożywić. Oczywiście 99,(9)% ogniw łączących krzesło z klawiaturą czym prędzej zatwierdzi wszystkie wyskakujące komunikaty, w amoku i jednym tylko celu - „*rrrrwa! aby przestały wyskakiwać!” - więc takie aplikacje musiałyby uruchamiać się w bardzo restrykcyjnej piaskownicy (do wyłączenia w opcjach, być może coś na wzór dev mode w Chrome OS ?). Można by nawet pójść o krok dalej i wszystkie progsy zakuć i zamurować w Alcatraz jak w Qubes OS.

Pozostaje jeszcze jedna rzecz, która bardzo przypadła mi do gustu w Androidzie z Xposed Framework i modułem XPrivacy. Możliwość kontroli przez użytkownika dostępu programów do zasobów komputera. Wszyscy znamy ogniomurki/iptables, wiemy o istnieniu SELinux /AppArmor (prawda, że wszyscy? ;}), niektórzy słyszeli coś o grsecurity itp. rozwiązaniach, tylko czy na miłość boską, ktokolwiek w domu przestudiował ich dokumentacje? Składnia i ilość czynności jakie należy wykonać onieśmieli każdego, a niezmordowanego przeciętnego Kowalskiego przegoni już sama nazwa. A można prościej? A można! Suwakami w menu. Dostęp do sieci? Tak/Nie. Dostęp do Dokumentów? Tak/Nie (dla kobiet w ich specyficznym czasie: Tak/Nie/Może). Jeśli ktoś się jeszcze nie zorientował: to jest rozwiązanie dla domu, nie firmy, nie klastra serwerów liczących białka, nie do panelu sterowania głowicami jądrowymi. Ale jakże przystępne w zachowaniu prywatności przez użytkownika!

Kodowanie znaków

Obecnie mamy kilka wiodących, zależnie od regionu, ale żadne z nich nie wspiera wszystkich alfabetów jakie kiedykolwiek powstały na Ziemi. Zgadza się, bez wyjątku wszystkich. Czemu by nie opracować takiego, który pomieści wszystkie znaki? Absolutnie wszystkie od „ą‑ę”, przez egipskie hieroglify, Głagolicę, Kipu, pismo klinowe Sumerów aż po Kanji zjadaczy sushi. Jednocześnie odchudzić z niepotrzebnych i nieużywanych znaków (gwiazdki, kwadraty, ramki, bombki, brzdęki...). Jedynym przeciwwskazaniem jest zajętość - jeden znak nie zajmowałby już jednego bądź dwóch bajtów, a całe osiem.

A więc wszystkie dokumenty zajmowałyby kilkakrotnie więcej miejsca niż obecnie, zaś ich parsowanie również trwałoby znacznie dłużej. Zniknąłby jednak raz na zawsze problem związany z czcionkami i kodowaniem tekstu we wszystkich krajach na kuli ziemskiej, więc chyba warto w dobie 22 wieku odciąć się od zaszłości z czasów powstawania systemów operacyjnych?

Miłośnicy emotikonek, ASCII art i budowniczych tabelek w terminalu wytkną mi zapewne chęć pozbycia się symboli, ale zastanówmy się przez chwilę - tak wszyscy razem - czy dzisiaj naprawdę wciąż ich potrzebujemy, dlaczego w ogóle czcionki zaczęły je zawierać i z czasem dokładać kolejne.

Interfejs

Bez wątpienia jest to punkt zapalny wszystkich gustów świata. Już niejeden się przejechał na przyzwyczajeniach użytkowników i nie do końca przemyślanej ergonomii. Z miejsca na myśl przychodzą Linuksowe Gnome3, Unity i Metro/ModernUI z Windows RT/8+. Wszystkie chciały (i chyba nadal chcą) dokonać fuzji środowiska biurkowego z mobilnym. Daleki jestem od podobnych szaleńczych prób, dlatego „mój system operacyjny marzeń” to system stricte desktopowy. A skoro mój to niestraszne mi eksperymenty, szczególnie że póki co działa wyłącznie w przestrzeniach /dev/brain0 i /dev/brain1. ;)

A więc dumnie nazwany Eximius OS, mógłby pochwalić się np. takim ekranem bootowania:

Czym się różni od dziesiątek innych boot screenów? Przede wszystkim nie wyświetla pełnego boot loga, a więc już na wstępie nie przeraża Kowalskich skomplikowaniem (pierwsze wrażenie jest bardzo ważne!), jednocześnie wyświetlając procentowy postęp wraz ze szczątkowymi informacjami co aktualnie system robi. Nie jest więc też równie bezużyteczny co Plymouth lub bootscr Windowsa.

Skoro jesteśmy już przy straszeniu użytkownika, w przypadku błędu podczas bootowania można by wyświetlić coś w tym stylu:

Niekoniecznie w tym konkretnym stylu graficznym (chyba że zależy nam aby Kowalski automatycznie dostał zawału). Zamiast długich treści numerów błędów w heksach jak w starszych Windows lub podobnych guru meditation, można po prostu opisać problem pojedynczym, łatwym do zapamiętania numerem, którego znaczenia użytkownik mógłby poszukać np. na stronie producenta. Takie rozwiązanie z powodzeniem sprawdza się na konsolach (power userzy i tak przełączyli by się do powłoki tekstowej i wyświetlili boot log‑a z obelgami).

Ekran logowania – nudy, nic nowego. Po za przyciskami do OSK i graficznym terminalem:

Pulpit

Pasek z programami plus tray dalej obecny, ale zintegrowany z dockiem. Rewolucji brak, można rzec już standard. Względną nowością za to jest ich zawartość i nawigacja.

Tło pulpitu w przeciwieństwie do każdego innego jakie znamy, mogłoby być animowane. GIF? APNG? A gdzieżby tam takie średniowiecze! Krótki zapętlony film w np. UHD lub nawet specjalnie renderowane interaktywne środowisko 3D. Już dziś jest to w zasięgu naszych rąk, niestety potwornie i niepotrzebnie obciążałoby środowisko. Puśćmy jednak wodze fantazji: siadamy przy komputerze, w tle szumią morskie fale rozbijające się o falochron, latają mewy, Janusze rezerwują sobie działki… Nie, stop, wróć! Poprzestańmy na mewach, przeganianych ruchem kursora myszki i siadających na ikonkach dokumentów, które trzeba na jutro przygotować do pracy. ;)

Większość z was zapewne kojarzy dock z OS X'owym protoplastą, Cairo-Dock na pingwinach czy też RocketDock na „windach”. A gdyby tak zamienić jego funkcję ze zwykłego launchera na coś w rodzaju listy procesów? Minimalistyczny, wysuwany z dołu na żądanie.

Dashboard. Fuzja niemal wszystkich pomysłów na dotychczas odseparowane od siebie elementy pulpitu, podzielona na kategorie.

Pierwszą z niezbędnych funkcjonalności jest oczywiście wyszukiwarka i zbiór wszystkich programów w systemie - wszystkich, a więc włączając w to także programy CLI. Wciskając lewy przycisk myszy, uruchamiany byłby program, wciskając prawy, użytkownik przenoszony byłby do osobnego menu skąd dostępne byłyby dodatkowe opcje takie jak np. „usuń”, „usuń dane użytkownika”, „kontrola dostępu do zasobów”, „kontrola bibliotek” itp.

Dodatkowo dash, pełniłby funkcję „centrum powiadomień”, zawierałby nie tylko rozmowy aplikacji z użytkownikiem, ale także szeroko pojętą telemetrię (ostatnio termin ten jest nadużywany, polecam więc sprawdzić co tak naprawdę oznacza ;)). Logi systemowe? Czemu nie, co tylko programistom podpowie wyobraźnia. Coś w rodzaju fuzji Rainmeter/Conky z systemowym tray'em, którego mogłyby używać np. komunikatory (wierzę że jeszcze świat nie oszalał na punkcie Facebooka i ktoś w dalszym ciągu korzysta z XMPP+OTR, a nawet klienta e‑mail).

Manager plików. Także bez rewolucji, ale skoro już sobie namalowałem to wstawię jakbym to ja widział, podkreślam: prostą, domyślną aplikację tego typu w systemie.

Oczywiście zdaję sobie sprawę z tego, że nasze obecne biurkowe komputery są na to wszystko jeszcze niegotowe – za mało wydajne i ze zbyt wolnymi i mało pojemnymi nośnikami. Niemal wszystkie te graficzne cuda na kiju generowałyby zbyt duże straty na wydajności, a co za tym idzie pochłaniałyby zbyt wiele energii elektrycznej i generowały zbyt wiele ciepła. Pamiętajmy jednak, że to są ograniczenia ery krzemu – a ta powoli i na szczęście dobiega już końca.

Powyższa wizja jest jedynie krótkim, prostym szkicem pełnym ogólników. Jeśli dożyję, to kto wie, być może spróbuję ją realizować. Podobno wszystko zaczyna się od marzeń… W praktyce do czasu aż Ikarowi nie roztopią się skrzydła - ale to już temat na kiedy indziej.

Byłym zapomniał, na ekranie z błędem można znaleźć „ukrytą” wiadomość. Nagrodą dla spostrzegawczego będzie... uśmiech autora. :P Cóż...

- Przemysław "Berion" Boruc dla blog DobreProgramy.pl @2015-09-27