Vlákno názorů k článku
V telefonech s Androidem brzy spustíte plnohodnotné linuxové prostředí
od Pavel Píša - Tak ono by stačilo, kdyby Google a výrobci...
-
Tak ono by stačilo, kdyby Google a výrobci telefonů spolupracovali na podpoře použitých SoC a HW s mainline komunitou, pak by mohl na telefonech běžet plnohodnotný GNU/Linux se skutečnou LIBC (GNU libc nebo Musl, pokdu to musí mít proprietary linkovatelné) a ne parodie s Bionic libc.
Pak by i ten celý Android mohl běžet v LXC nebo jiném kontejneru a začalo by to být bezpečnější a časem by se těch zbytků špatných řešení dalo zbavit úplně. Třeba Google v tom kažení systému dojdou síly a na toto přejde. Waydroid již komunita dohromady dala.
Jak je to s podporou udržovatelného jádra a grafiky pro skutečný systém na mobilních telefonech se můžete podívat na předášce Davida Heileberga na Linux na telefonu v roce 2025. Jsem s ním dohodnutý, že pokud by se nějaký student od nás z ČVUT FEL chtěl do jejich projektů zapojit, tak zajistím vypsání takové úlohy jako diplomové nebo bakalářské práce a pak její formální vedení s Davidem jako externím specialistou a oponent může být někdo z komunity postmarketOS, MESA 3D nebo Colabory, kde se David s core vývojáři zná.
Přinesu i Librem 5, jako podpory vývoje ekosystému jsem s jeho nákupem spokojený, pro reálné použití tuto první vlaštovku nedoporučuji, v té době omezený výběr SoC s otevřenou podporou GPU znamenal výběr čipu určeného do automotive bez optimalizace na spotřebu do mobilního telefonu a nemyslím, že se situaci moc podaří vývojem SW doladit. Ale dnes je otevřeným kódem podporovaných GPU (LIMA, Freedreno, IMG Tec A/B atd..) již celkem hodně, takže sám bych telefon se stejným SW (Posh) a delší výdrží na baterii jako svůj hlavní již plně užil. Jen chybí ty konfigurace displejů, kamer, GSM modemů a mnoha dalších nedokumentovaných kusů HW.
-
> pak by mohl na telefonech běžet plnohodnotný GNU/Linux se skutečnou LIBC (GNU libc nebo Musl, pokdu to musí mít proprietary linkovatelné) a ne parodie s Bionic libc.
Jak to souvisí s podporou výrobců SoC? Glibc a musl jsou userspace knihovny a nemají moc co dělat s drivery.
> Pak by i ten celý Android mohl běžet v LXC nebo jiném kontejneru
Tuším, že hlavní problém s během v kontejneru spočíval v nějakých rozšířeních kernelu jako binder. Naopak userspace knihovny mohou být v kontejnerech klidně odlišné.
> začalo by to být bezpečnější
V čem?
-
Potíž je, že ta vendor specific jádra vyžadují k běhu grafiky a dalšího věšinou binary only implementaci ovladačů grafiky která prochází bloby v jádře a v userspace a ty kusy do userspace by sice klidně šly nakompilovat nad Glibc, ale protože jsou jen v bináru proti Bionic LibC, tak vznikají pro běh Ubuntu a dalšího přímo na HW telefonu hrůzy jako Libhybris což je úplně zbytečná práce. Stejně jako komunita, když chce použít Android třeba pro řízení, tak nakonec musela ten nedotažený Bionic doplnit o to, aby měl alespoň priority inheritence atd... Je to plýtvání časem.
Bezpečnost je pak problém prosto, že ta zablobovaná jádra i userspace nejde rozumně opravovat z vývoje z mainline jádra a dalšího. Často jsou to jádra stará, se stovkami patchů, takže i pokud k části s problémem je zdrojový kód a nějak při dodržení většinou přesně shodného toolchinu s tím, který byl použitý pro jaderné binary only ovladače, tak nemáte vůbec jistotu, že úprava nebude ve skutečnosti vést ještě k vější problémům.
Takže je Andoid je dobrá cesta, jak využít práci komunity, zajistit, že výsledek je pro tu opravdu svobodnou komunitu problematicky použitelný a ti, kteří by spojenými silami navrhli něco lepšího než Android tak jsou dostatečně vytížení tím, že opravují a snaží se nějak pracovat na té hromadě forků s mnoha zbytečnými problémy. Takže pro udržení Androidu je to win situace. Pro dlouhodobý udržitelný vývoj ne.
Jinak ano, bezpečnost klasického Linuxového desktopu vychází dobře při používání jen podepsaných balíčků pod kontrolou správců distribuce. Jinak jsou osobní data v nebezpečí. Ač nemá FlatPak a podobné až tak rád, tak s nějakou kontejnerizací a portály pro přístup k souborům a komunikačním kanálům to může být cesta vpřed. Sám bych spíš než Docker like volil nějaký systém, kdy jsou knihovny z hlavního systému nějak verzované a přímo nabízené do lehkých kontejnerů s omezeným/kontrolovaným přístupem předevší na data spouštějícího uživatele. Pro binary only programy třetích stran by to mělo být pravidlo. Na druhou stranu sám bych dnes vystačil s tím, co je otevřené a v distribucích... případně si něco dopsal nebo dokompiloval na míru. Ale zavřené aplikace obchodů, bank a dalších jěště asi nějakou dobu potřeba budou. I když ono se to dnes dost přelévá do WebAssembly, kde je to odstínění od dat uživatele celkem zařízené.
