Názory k článku Linuxový desktop se zázračně nerozšířil, za vyšší čísla může chyba

Instalační závislost programů samozřejmě implementované jsou, a aplikace si mohly vzájemně přepisovat knihovny naposledy tuším ve Windows 2000. Autoři aplikace si mohou vybrat, jestli pojedou na sdílené knihovně (což je případ systémových knihoven), nebo si ji potáhnou s sebou odděleně (což se týká většinou vlastních knihoven).

Ad co se pak stane, když se v knihovně najde zranitelnost a aktualizuje se jen někde - Totéž co na Linuxu, kde je řada komerční aplikace staticky slinkované. A totéž co se na Linuxu děje u Snap apps, které si táhnou veškeré knihovny s sebou (včetně kusů GNOME), případně u Flatpaku nebo AppImage.

"Ad co se pak stane, když se v knihovně najde zranitelnost a aktualizuje se jen někde - Totéž co na Linuxu, kde je řada komerční aplikace staticky slinkované. A totéž co se na Linuxu děje u Snap apps, které si táhnou veškeré knihovny s sebou (včetně kusů GNOME), případně u Flatpaku nebo AppImage."

Pokud si nejaky projekt tahne kusy kodu staticky slinkovaneho, ktery by jinak mohl byt sdileny, prebira za tyto veci odpovednost autor. To stejny plati i vpripade, ze si projekt taha vlastni knihovny (cemuz nelze nijak branit) Jednou z vyhod ktere poskytuji balickovaci sytemy prave diky reseni zavislosti je aktualizace pro vsechny dalsi projekty, ktere jsou na nem zavisle.

Jen z cire zvedavosti, tvrdite, ze "Instalační závislost programů samozřejmě implementované jsou". Mohl by, jste prosim, zevrubne popsat jakym zpusobem jsou zavislosti ve Widlich reseny? Dovedu si to predstavit u Apps store, nebo v pripade komponent samotnych Windows. Moc by me vsak zajimalo, jak by se to u vas resilo pres klasickou widloidni instalacni proceduru (tedy ne z appstore, popripadne je instalacni procedura stejna z jakehokoliv zdroje), Uvazme -ciste hipoteticky prikald: Aplikace 'A' bude vyzadovat tez instalaci projektu 'B' a 'F'; pricemz 'F' bude vyzadovat, aby byly pritomny dale produkty 'X', 'Y', 'Z'. Produkt 'Z' pro svou instalaci vyzaduje, aby 'Y' jiz byl nainstalovan a nakonfigurovan. Dale plati, ze zaroven s produktem 'X' nesmi byt v systemu nainstalovan produkt 'W'. Predpokladejme pro nas hypoteticky priklad, ze kazdy z techto produktu jsou dilem jineho, nezavisleho subjektu.

Ty instalátory třetích stran většinou používají Windows Installed API. To jestli je nainstalovaný potřebný SW zjistí setup package buď pomocí Windows Installer API, nebo třeba z Registry. Pouze velmi neschopný autor by spoléhal na cestu. Pokud aplikace nemá vyřešené závislosti na potřebných komponentách na úrovni setupu ani Release Notes, tak ji asi psalo nějaké prase.

Hry neinstalují DirectX, ale DirectX runtime components. Ke každé verzi DirectX je více verzí runtime components. Visual C++ Runtime je podobný případ. Autor aplikace může buď přiložit merge moduly k vlastní aplikaci, nebo balíček stáhnout z webu MS (což autoři her z nějakého důvodu nedělají), případně uživateli prostě říct "smůla, nainstaluj si A a B" (což může mít smysl u serverové aplikace, ale ne u hry).

This problem occurs because security updates 2966827 and 2966828 for Microsoft Security Bulletin MS14-046 for the .NET Framework 3.5 require metadata that is added to the system only if the Microsoft .NET Framework 3.5 feature is enabled on the system. ... The issue is now resolved by update 3005628.
https://support.microsoft.com/en-gb/help/3002547

MS SQL Server se samozřejmě dá odinstalovat, a dají se přidávat i odebírat nainstalované komponenty.

[LO]
"případně uživateli prostě říct "smůla, nainstaluj si A a B" (což může mít smysl u serverové aplikace, ale ne u hry)."

Coz presne v mnoha pripadech autori her delaji ;)

[j]
Ad Zavislosti na Widlich.
Ano, vypada to tak. Take si myslim, ze v podstate tohle je plne vlozeno na bedra tvurce instalace.

Ad Pokud si nejaky projekt tahne kusy kodu staticky slinkovaneho, ktery by jinak mohl byt sdileny, prebira za tyto veci odpovednost autor. To stejny plati i vpripade, ze si projekt taha vlastni knihovny (cemuz nelze nijak branit) - jj, přesně jako ve Windows.

Ad Jednou z vyhod ktere poskytuji balickovaci sytemy prave diky reseni zavislosti je aktualizace pro vsechny dalsi projekty, ktere jsou na nem zavisle - tohle máte ve Windows řešené automaticky pro systémové komponenty. A protože Windows API je daleko širší než libc :), tak pokrývá automatickou velkou většinu potřeb.

Ad jak by se to u vas resilo pres klasickou widloidni instalacni proceduru... Aplikace 'A' bude vyzadovat tez instalaci projektu 'B' a 'F'; pricemz 'F' bude vyzadovat, aby byly pritomny dale produkty 'X', 'Y', 'Z'. Produkt 'Z' pro svou instalaci vyzaduje, aby 'Y' jiz byl nainstalovan a nakonfigurovan. Dale plati, ze zaroven s produktem 'X' nesmi byt v systemu nainstalovan produkt 'W' - Funguje to podobně jako s MS komponentami (třeba .NET Frameworkem). Setup package je procedurální, takže v setupu projektu A zkontrolujete jestli je nainstalované B a F. Pokud B nebo F chybí, tak je buď můžete mít na svém vlastním instalačním médiu a spustit jejich instalaci (klidně unattanded), nebo je stáhnout z webu výrobce a spustit instalaci, nebo prostě uživatele upozornit a instalaci ukončit. B a F pak postupují stejně.
Takže pokud instalujete řekněme účetnictví které vyžaduje DB engine, můžete dát uživateli na výběr jestli použít lokální DB engine nebo se připojit k DB serveru. Pokud vybere lokální engine, můžete spustit jeho unattanded instalaci (pokud již není nainstalovaná) a poté vytvořit DB (pokud již neexistuje). Pokud se chce připojit k DB serveru, zeptáte se ho ke kterému. Samozřejmě se to celé dá provést unattended. Alternativně můžete účto prostě nainstalovat, a o DB se starat až později při jeho prvním spuštění.

Jinak instalaci na Linuxu ukazuje třeba Oracle. Myslím že je to celkem výživné. Ve zkratce: zkontrolujte velikost swapu, velikost shared memory, verzi OS včetně patchů, nainstalujte cca 20 balíčků včetně kompilátoru (na každém distru jiné), vytvořte uživatele a skupiny, nastavte parametry kernelu včetně limitů, vytvořte adresáře, nastavte prostředí pro uživatele, přimountujte instalační médium, a pak konečně spusťte wizard a projděte ho. Instalace složitějšího SW prostě není jen o dotažení pár balíčků a zkopírování pár souborů.
https://docs.oracle.com/cd/E11882_01/install.112/e24326/toc.htm

[LO]
"Ad Pokud si nejaky projekt tahne kusy kodu staticky slinkovaneho, ktery by jinak mohl byt sdileny, prebira za tyto veci odpovednost autor. To stejny plati i vpripade, ze si projekt taha vlastni knihovny (cemuz nelze nijak branit) - jj, přesně jako ve Windows."

Ne tak uplne. Nikdy nepouzivate Linux samostane, vzdy instalujete distro. Pokud projekt protlacite do offiko repositaru dister, pak vyvojari techto dister jsou jiz schopni situaci ovlivnit zadoucim smerem. At uz tak, ze k tomu donuti vyvojare, nebo instalacni balik vybuildi sami tak aby odpovidal jejich normam. Jde to i v pripade, ze projekt puvodne obsahoval vlastni buildy shared knihoven (napr). nekdy to samozrejme neni technicky uplne mozne (knihovna je autorem projektu napriklad ospekovana). Muzou pak vytvorit patch, opatchovanou knihovnu vlozit do samostaneho baliku, a s puvodnim balikem provazat pomoci zavislosti. Potom lze vyuzivat vsech vyhod balickovaciho systemu.Lze to samozrejme delat jen v pripadech kdy jsou k dispozici zdrojove kody, nebo autor spolupracuje s vyvojari distra.

"Tohle máte ve Windows řešené automaticky pro systémové komponenty. A protože Windows API je daleko širší než libc :), tak pokrývá automatickou velkou většinu potřeb"

To neni nutne vyhoda. Glibc je sice mala co do velikosti a rozsahu API, ale to je prave to co je pozadovano. Resi jen to nejnutnesi application runtime a syscally. O ostani se staraji dalsi samostane komponenty systemu. Vcetne centralizovaneho instalacniho subsystemu. To co je ve Widlich na tvrdo zadratovano do sys-molochu je v Unix systemech jako samostatny modul. Tim je dosazena stejne funkcionalita a navic bonus v tom, ze jednak neni nutne mit systemu mraky kodu, ktery treba nikdo nevyuzije, jednodusi udrzba a naprava chyb a nakonec, modularnost umoznuje zamenovat komponenty dle pozadovane funkcnosti a vykonu. Konec koncu, modularita, jednoduchost a specializace patri do filosofie Unixu jako takoveho ;)

"Funguje to podobně jako s MS komponentami (třeba .NET Frameworkem)... "
Me to tedy vychazi tak, ze kontrolu a provedeni zavislosti si musi instalator udelat sam. Jenze (vetsina) Linuxovych balikovacych systemu toto dela naprosto automaticky (i zde existuji vyjimky - napr. deb maji tez tzv "doporucene" zavislosti, jez se provedou pouze na pokyn uzivatele. Pouzivaji se na provazovani s baliky jejichz pritomnost v systemu neni nutna, ale mohou treba nejak puvodni projekt rozsirit atpd.).

Jak jsem psal v soucastech Widloidniho systemu, ci app store problem nevidim, ale jak vidno ze zadani, nikde neni psano, ze hypoteticke produkty budou pristupne v appstore, ci pristupne pres instalaci sytemu. Zdroj na webu poskytovatele je sice krasna vec, nicmene naprosto neuniverzalni (zpusoby stazeni mohou byt reseny opravdu vselijak) a navic se mohou kdykoliv bez varovani zmenit. S timhle si asi Install Shield neporadi ani s nafouknutym widloidnim API.

Navic zavislosti neresi jen instalaci samotnou, ale take navazne akce (update a nove verze, configurace, reinstall a odinstalovani) coz vam bohuzel vami popisovane reseni neuplne zavislosti nedovoli ( tedy pokud ostranite DirectX. verze blablabla, neodstranite tim dalsi produkty, ktere jsou na nem zivotne zavisle a naopak lokalni instalci muzete nainstalovat produkty, bez aniz by jste instalovaly dulezite externi komponenty). Windowsy maji jen mlhavou predstavu ktery projekt na cem vysi a po vetsinou se to tyka systemovych komponent a frameworku. Komponenty tretich stran uz systemove podchycene nejsou.

"Jinak instalaci na Linuxu ukazuje třeba Oracle. Myslím že je to celkem výživné. "
Chapu a verim, ze to musi byt pekny opruz. A nenapadlo vas, ze to spis skopalo Oracle, nez ze by to byla chyba Linuxu jako takoveho?

Ad vzdy instalujete distro. Pokud projekt protlacite do offiko repositaru dister - To se týká open source, který si autoři distra sami vyberou. Podvojné účetnictví, Skype ani (ty lepší) hry v repozitářích nenajdete. Autor pak buď musí vydat balíčky pro každé distro a každou jeho verzi (protože distra a jejich verze se liší ve všem od kernelu, přes dostupné API a jména adresářů až po GUI), nebo řešit distribuci své aplikace statickým linkováním, případně lokálními knihovnami.

Ad Glibc je sice mala co do velikosti a rozsahu API, ale to je prave to co je pozadovano. Resi jen to nejnutnesi application runtime a syscally. O ostani se staraji dalsi samostane komponenty systemu - Bohužel to vede k tomu, že se jednotlivá distra a jejich verze liší ve všem od kernelu, přes dostupné API a jména adresářů až po GUI. Jako bonus máte v systému spoustu věcí v deseti vydáních. Proč mít jedno API pro kreslení kolečka, když jich můžete mít rovnou deset :/. Proč mít jeden widget toolkit, když jich můžete mít také deset, každý s vazbou na některá API pro kreslení koleček :/. A proč k tomu celému mít jednu rozumnou dokumentaci, když může být po všech čertech, a v kvalitě od příšerné až po špatnou. Ohledně modularity: chci vidět, jak vyměníte třeba Qt a nahradíte ho pomocí něčeho jiného. Ve skutečnosti je aplikační ekosystém závislý na velkém procentu těch rendering enginů a toolkitů, takže je musíte mít na stroji všechny. Nejen že to zvyšuje attack surface, ale navíc pak každá aplikace vypadá jinak, a dokonce se i různě rendrují fonty.

Ad kontrolu a provedeni zavislosti si musi instalator udelat sam - no tak někdo to udělat musí :). Nebo na Linuxu balíčkovací systém nějak magicky sám zjistí, že aplikace má závislost?

Ad app store problem nevidim, ale jak vidno ze zadani, nikde neni psano, ze hypoteticke produkty budou pristupne v appstore - samozřejmě, a stejně není nikde psáno, že hypotetické produkty budou dostupné v repozitáři.

Ad Zdroj na webu poskytovatele je sice krasna vec, nicmene naprosto neuniverzalni (zpusoby stazeni mohou byt reseny opravdu vselijak) a navic se mohou kdykoliv bez varovani zmenit - To záleží na dohodě s autorem aplikace. Někteří autoři vám dají redistributable, který můžete zahrnout do svého package. Další vám můžou dát URL, kde bude aplikace ke stažení.

Ad zavislosti neresi jen instalaci samotnou, ale take navazne akce (update a nove verze, configurace, reinstall a odinstalovani) coz vam bohuzel vami popisovane reseni neuplne zavislosti nedovoli - od toho jsou Patch Packages, přípona .msp. Ty mohou opět například upgradovat jinou aplikaci.

Ad pokud ostranite DirectX. verze blablabla, neodstranite tim dalsi produkty, ktere jsou na nem zivotne zavisle - Ten samý problém máte přece i na Linuxu. Když odstraníte řekněme glibc-headers-2.3.4, tak se neodstraní Oracle RDBMS, který je na tom balíčku závislý. A když odstraníte Oracle RDBMS, tak se neodstraní glibc-headers-2.3.4, ani pokud je to jediná aplikace, která ten balíček používala.

Ad nenapadlo vas, ze to spis skopalo Oracle, nez ze by to byla chyba Linuxu - nenapadlo vás, že Oracle asi nechce psát 18 instalátorů jen pro Linux, které navíc stejně neřeší kontrolu kernelových parametrů, vytvoření uživatelů, nastavení prostředí atd.? Oracle napíše jeden instalátor, který nakrmí daty potřebnými pro instalaci na Windows, Linuxu, Solarisu, AIXu a HP-UXu. Je samozřejmě smutné, že neexistuje nic jako "balíček pro UNIX" nebo alespoň "balíček pro Linux", a místo toho pro jednu platformu UNIX potřebujete 22 různých balíčků. Ale když to tak je, tak to Oracle musí řešit nějak obecněji.

Dekuji za vysvetleni.

Podle toho co pisete je to presne jak se dalo cekat. Widle zavislosti (slespon v te forme, jak je chapeme na Linuxu) implementovany nemaji, a nebo jen urcite aspekty tohoto mechanizmu (pres msp). Je to i logicke, protoze v minulosti (do otevreni apps store) nebyl tento mechanizmus nijak moc potrebny a ani vicemene ve vetsi mire pouzitelny. Jako zdroje softwaru slouzily (a v podstate dodnes slouzi) uzivatelum volne lozene instalatory (msi), ktere nebylo mozne nijak staticky provazat, ani s nimi nijak kalkulovat a tim padem neni mozno komplexne spravovat sofwarove vybaveni na stroji, tak jak to delaji balickovaci systemi na Linuxovych distribucich.

A k vasim dotazum.

"Nebo na Linuxu balíčkovací systém nějak magicky sám zjistí, že aplikace má závislost?" Ne. Zavislosti urcuje tvurce instacniho baliku na zaklade pozadavku daneho projektu/produktu. Nicmene jejich provadeni, kontrola a dalsi operace nad temito atributy baliku provadi vzdy a vyhradne balikovaci system. Baliky jsou v podstate "mrtve" archivy dat. I kdyz mohou obsahovat scripty urcitych instalacnich procedur, i ty jsou spousteny a kontrolovany (ci dokonce rovnou vykonavany) balikovacim systemem.

"samozřejmě, a stejně není nikde psáno, že hypotetické produkty budou dostupné v repozitáři." Ano, neni to zaruceno, i kdyz je tam velka pravdepodobnost. V pripade, ze balik neni v repositari balickovaci system bud instalaci neprovede, a nebo ano, ale vede jej jako poruseny. Take o tom da vedet uzivateli hned pri instalaci a tim padem se na ni da reagovat jeste pred spustenim samotne aplikace. To je velky rozdil oproti Widlim, kdy se tuto skutecnost vetsinou dozvite az po spusteni programu.

" Když odstraníte řekněme glibc-headers-2.3.4, tak se neodstraní Oracle RDBMS, který je na tom balíčku závislý. "
Pokud je na dany projekt na hlavickovych souborech Glibc opravdu zavisli (a neni to jen doporucena zavislost - coz je velmi pravdepodobne.) pak si budte jist, ze po odinstalovani tohoto baliku vyleti jen to hvyzdne. Predpokladem je, ze Oracle RDBMS je instalovana take pres balickovaci system. Samozrejme, ze na rozdil od situace na Widlich budete o teto situaci informovan a pozadan o potvrzeni teto operace.

"To záleží na dohodě s autorem aplikace. Někteří autoři vám dají redistributable, který můžete zahrnout do svého package. Další vám můžou dát URL, kde bude aplikace ke stažení."
Porad to neresi situaci, kdy poskytovatel daneho produktu se rozhodne formu poskytovani zmenit. Neni ve vasich silach jej nutit, aby kvuli nejakem projektu daval nejaky staly spusob poskytovani sveho produktu. Respektive, pokud vas projekt bude vyzadovat produkty dalsich dvaceti subjektu, jiste je vsechny budete kontaktovat a se vsemi se budete dohadovat o tom jak maji TRVALE poskytovat svuj produkt :-D

K Vasi zmatenosti dost prispiva i to, ze mate tendenci neustale Linux vnimat jako fixni moloch, jak to znate z Widli. To je ovsem chyba, ktera vede k mnoha zavaznym omylum ve Vasem dalsim chapani Linuxu. Treba otazka modularity.

Modularitu nelze chapat tak, ze lze vymenit cokoliv a kdekoliv a zacokoli. Spis jako moznost vyuzivat volby. Naprikald tezko donutim KDE aby plne bezelo pod GTK. To da rozum. Nicmene nejsem nucen vubec pouzivat ani Qt ani cokoliv co na nem zavisi. Mohu pouzivat aplikace stavene na GTK, ci nemusim vyuzivat GUI vubec a pracovat v prikazovem radku. Nebo mohu tyto moznosti libovolne kombinovat a mit ve svem systemu nainstalovano jen to co potrebuji (k tomu patri i zavislost). Stejne tak to plati i pro dalsi casti syatemu. Takove moznosti na Widlich nemate. Spoustu subsystemu mate natvrdo zadratovanych v systemu a nadelate s tim vpodstate hodne malo ci spise nic.

Co se tyce Renderingu, jste mimo uplne. Stejne jako Widle, i Linuxove distribuce poskytuji jednotne API pro rendering a to vcetne fontu. Widle pouze poskytuji navic i rendering defaultniho GUI. Jestli je to dobre nebo ne, jest otazkou jinou. Kazdopadne, rendering knkretnich prvku v konkretnim frameworku je ciste veci tvurce daneho produktu. Jestlize se rozhodne mit design wydgetu a pismo ala Sun OS, tak ma na obou platfomach moznosti jak toho dosahnout a taky to tak bude vypadat. To ze se toho na Widlich az v takove mire nevyuziva, je zas veci uplne na jinou diskuzi.

K Oracle: Obavam se ze to je spis o neschopnosti, nez problemu udrzovat projekt pro vice platforem. I reseni instlacniho procesu pro Linux obecne existuji. Dokonce i genericke, ktere Vam vyprodukuji baliky na konkretni distra (alespon mainstreamova). Ale to je uz na jinou diskuzi :)

Z uživatelského hlediska spravujete SW na stroji tak že instalujete a případně deinstalujete aplikace. Uvědomte si, že na Linuxu máte v podstatě distro se vším SW z repozitáře jako jeden velký kompaktní balík, ze kterého si nainstalujete vybrané komponenty, a závislosti řešíte jen v rámci tohoto balíku. Ve Windows jsou aplikace externí a šířené nezávisle na OS, takže to prostě má jiné implikace. Na Linuxu samozřejmě také existují aplikace které nejsou součástí distra, ale balíčky jsou určené pro konkrétní verzi konkrétního distra, a funguje to tak "skvěle", že se postupně přechází na model nezávislých sandboxovaných aplikací, tak jako ve Windows. A protože je to Linux, tak máte flatpak, AppImage a snap (plus samozřejmě Autopackage, Listaller, Zero Install, ROX a hromadu dalších). Jak linuxové. Vtipné ale je, že si aplikace do toho sandboxu tahají například celý GTK+ nebo Qt runtime, každá svůj. V podstatě vyjma X11 a libc má každá aplikace vlastní kopii celého API, protože neexistuje žádné společné a zaručené API pro každé distro.

Ad Zavislosti urcuje tvurce instacniho baliku na zaklade pozadavku daneho projektu/produktu - Takže přesně jako ve Windows.

Ad jejich provadeni, kontrola a dalsi operace nad temito atributy baliku provadi vzdy a vyhradne balikovaci system - Pokud se aplikace instaluje balíčkovacím systémem. Ve Windows je to podobné, .msi balíčky instaluje Windows Installer service. Pokud máte executable místo .msi balíčku, tak je to zpravidla selfextractor, ve kterém je ten .msi balíček a případný externí obsah.

Ad Baliky jsou v podstate "mrtve" archivy dat. I kdyz mohou obsahovat scripty urcitych instalacnich procedur, i ty jsou spousteny a kontrolovany (ci dokonce rovnou vykonavany) balikovacim systemem - Opět velmi podobné.

Ad V pripade, ze balik neni v repositari balickovaci system bud instalaci neprovede, a nebo ano, ale vede jej jako poruseny. Take o tom da vedet uzivateli hned pri instalaci... - Jinými slovy jako ve Windows. A pokud si vývojář závislost nanastaví, tak aplikace spadne při spuštění, což je opět stejné.

Ad Pokud je [Oracle] na hlavickovych souborech Glibc opravdu zavisli... po odinstalovani tohoto baliku vyleti jen to hvyzdne. Predpokladem je, ze Oracle RDBMS je instalovana take pres balickovaci system. - Jenže Oracle, Lotus Domino/Notes, SAP a dlouhá řada dalších aplikací se neinstaluje přes balíčkovací systém.

Ad to neresi situaci, kdy poskytovatel daneho produktu se rozhodne formu poskytovani zmenit - To je ale totéž jako na Linuxu. Když se autor aplikace nebo knihovny rozhodne je neposkytovat, tak budete mít nejstarší verzi kterou poskytl, a tím to končí.

Ad Modularitu nelze chapat tak, ze lze vymenit cokoliv a kdekoliv a zacokoli. Spis jako moznost vyuzivat volby. Naprikald tezko donutim KDE aby plne bezelo pod GTK. To da rozum. Nicmene nejsem nucen vubec pouzivat ani Qt ani cokoliv co na nem zavisi. - A jakou má přidanou volby když máte dvacet widget toolkitů, které většinou vypadají jako retro z osmdesátých let? Nebo když máte dvacet API pro kreslení kolečka? Nebo když zamykání souborů liší mezi jednotlivými Unixy, verzemi daného OS, mezi FS a mezi lokálním a síťovým přístupem? Přitom libc i s frameworky nad ní je pořád proti Windows velmi chudé API. Připomíná mi to situaci kdy byste považoval za výhodu mít doma dvacet typů zásuvek s odlišnou voltáží, frekvencí a konektory, protože je super, že si můžete vybrat a nikdo vás do ničeho nenutí. Naopak: výhodou je mít jednu platformu, která má rozumné API s dostatečně širokým záběrem, a teprve speciality si každý může řešit jak chce. Buďme rádi že autoři původního Unixu udělali alespoň funkce pro přístup k souborům, protože kdyby to bylo na komunitě, tak těch pár desítek FS, které na Linuxu máte, bude sice dělat skoro totéž, ale mít každý vlastní API.

Ad Takove moznosti na Widlich nemate. Spoustu subsystemu mate natvrdo zadratovanych v systemu a nadelate s tim vpodstate hodne malo ci spise nic. - To není tak úplně pravda. Windows se dají používat na čemkoliv od IoT krabiček, přes telefony, tablety, notebooky a desktopy až po mission critical servery. Pokud chcete ořezané windows, koukněte se na Windows IoT, Windows Server Core nebo Windows Server Nano.

Ad Linuxove distribuce poskytuji jednotne API pro rendering a to vcetne fontu - Mohl byh se zeptat jaká konkrétní API to tedy jsou? A kde najdu dokumentaci API distra?

Ad Oracle; je spis o neschopnosti, nez problemu udrzovat projekt pro vice platforem; reseni instlacniho procesu pro Linux obecne existuji. Dokonce i genericke, ktere Vam vyprodukuji baliky na konkretni distra - Bohužel balíčkovací systémy neřeší ověření nastavení kernelu, vytvoření app adresářů, uživatelů, nastavení permissions, nastavení prostředí, a hlavně výběr komponent a zadání nastavení. Zkuste si ten Oracle installer někdy projít, abyste viděl, kolik věcí se tam dá vybrat. Jak byste tohle udělal s balíčkovacím systémem?

se postupně přechází na model nezávislých sandboxovaných aplikací, tak jako ve Windows
Ony jsou jednotlivé aplikace ve Windows sandboxované? Jak jste na to přišel?

UWP aplikace jsou sandboxované. Samozřejmě se dají sandboxovat i Win32 aplikace.