Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).
V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.
Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.
Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu březnový souhrn novinek. Vypíchnout lze, že pracují na virtuálním asistentu PineVox a zatím bezejmenných sluchátkách na lícní kosti (bone conduction).
Hyprland, kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, je již dva roky starý. Při té příležitosti byla vydána verze 0.37.0 (a záhy opravná 0.37.1 řešící chybu ve vykreslování oken). Nově závisí na knihovně hyprcursor, která poskytuje škálovatelné kurzory myši.
Byla vydána verze 0.12.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 76 vývojářů. Přibylo 853 nových balíčků. Jejich aktuální počet je 4 599. Aktualizována byla také dokumentace.
Tiskni Sdílej:
Jinak GNU Guix je kromě mnoha dalších vysoce atraktivních vlastností poměrně výjimečný mj. i tím, že umožňuje jakýkoliv balíček nainstalovat v různých verzích paralelně a pro každé spuštění (či obecně použití daných dat, protože nemusí jít pouze o spustitelné aplikace) lze zvolit verze, ze kterých se má sestavit prostředí běhu. Tohle neuvěřitelným způsobem zjednodušuje ohromné množství práce IT člověka (testování, systémově nezávislá kompilace, debugování, porovnávání několika běžících verzí naráz, atd. - dále ve spojení s bit-perfect sestaveními podepsanými klíči lze instalovat tisíce balíků v podstatě v rámci sekund a ne hodin čekání na různá sestavení apod.) a mnohdy i koncového uživatele (transakční update, zkoušení starých/nových verzí, preview/"nakouknutí" do budoucnosti, jednorázové překlenutí nějakého problému užitím jiné verze, atd.).+1
Tohle mít v ruce před 10 lety, tak blbiny jako Docker buď nevzniknou a nebo budou okrajovou záležitostí.Částečně to souvisí, ale víc za rozšíření Dockeru IMHO může neschopnost/neochota autorů/výrobců softwaru dodat standardní balíčky (byť třeba jen pro jednu vybranou distribuci) a použitelnou dokumentaci. Což je podle mého věc, která by měla být dostupná i v případě, že se software distribuuje přes Docker nebo třeba binární obraz disku VM (QEMU-KVM, VirtualBox, Xen atd.). A taky za to může marketing – když řekneš průměrnému manažerovi, že bychom měli dělat RPM nebo DEB, tak nebude vědět, o čem mluvíš – kdežto když řekneš, že bychom měli jít do Dockeru, tak sice taky reálně neví, o čem mluvíš, ale už o tom někdy slyšel nebo četl.
Ju, ale to bychom zde nesměli mít plebs vychvalující balíčkovací systémy vedoucích Linuxových a BSD distribucí, které jsou IMHO již minimálně 15 let zářnou ukázkou, jak se balíčkování nemá dělat.Hodně přeháníš. Balíčkovací systémy jako RPM a DEB vznikaly v době, kdy většina lidí neměla internet, alternativou balíčku bylo
./configure && make && make install
a (o dost později) windowsáři si stahovali zavirované exáče z pochybných webů (což většina dělá dodnes). Klasický balíčkovací systém byl oproti tomu až mimozemsky vyspělá technologie, o mnoho řádů výš než cokoli jiného. Tyhle systémy se udržely dodnes a stále jsou velmi užitečné.
Je ale pravda, že možnost instalace více verzí jednoho balíčku a uživatelské instalace by to posunuly ještě o kus dál. To je evoluce. Otázka je, co s tím, jestli by Debian, Ubuntu, Fedora, Suse… měli přejít na nový formát balíčků nebo vylepšit ten svůj. Pokud by existoval nějaký nástroj na automatizovanou konverzi zdrojových DEB a RPM tak by to nemuselo být tak hrozné, ale bylo by potřeba upravit i všechny ty procesy kolem. Nebo nechat klasické distribuce žít jejich vlastním životem a „kanibalizovat“ jejich balíčky – převést je do nového formátu a začlenit do GuixSD.
Pokud by existoval nějaký nástroj na automatizovanou konverzi zdrojových DEB a RPM tak by to nemuselo být tak hrozné,Tak tohle už 5 let máme např. ve formě Effing package management. Jinak co se změny týče, tak prvním (zřejmě nejbolestivějším) krokem bude celosvětové sjednocení verzování - ale i na tom se urputně pracuje. Až pak se opatrně můžeme začít ptát distribučních kanálů, zdali by nechtěli v horizontu 5-10 let pomaloučku přejít na smysluplné (a libovolně rozšiřitelné pro jakékoliv potřeby) verzování při změně jejich release/build/distribution řetězce. Docker a vůbec "kontejnerizace" právě tento problém vyřešili poměrně radikálním způsobem - přeskočíme kompletně všechno a prohlásíme se za krále, který vše obalí do jednotlivých "panství" a řekne, že pak všechno funguje. Ale ouha, ono to není tak jednoduché, a tak se neobaluje do panství, nýbrž každá chaloupka zvlášť a jsme znovu tam, kde jsme byli, avšak s další částečně zbytečnou abstrakční vrstou navíc a tedy zvýšenou komplexitou, náklady, rizikem atd. Naštěstí některá "panství" (kontejnery použité na správných místech) skutečně existují, takže alespoň částečný úspěch se rozhodně nezapře.
Ale ouha, ono to není tak jednoduché, a tak se neobaluje do panství, nýbrž každá chaloupka zvlášť a jsme znovu tam, kde jsme byli, avšak s další částečně zbytečnou abstrakční vrstou navíc a tedy zvýšenou komplexitou, náklady, rizikem atd.To mi připomíná svět Windows, kde se servery vytváří naprosto prasecky a živelně, protože aplikace nejsou dostatečně oddělené, běží většinou pod uživatelem
system
a různě si přepisují data a knihovny. Provozovat víc aplikací je peklo a nikdo do toho rizika nechce jít (co kdyby se to rozbilo?), tak se radši pro každou aplikaci nainstaluje nový server (což náramně vyhovuje Microsoftu, protože inkasuje za každou licenci). O tohle ve svém operačním systému a světě zrovna nestojím.
Naštěstí některá "panství" (kontejnery použité na správných místech) skutečně existují, takže alespoň částečný úspěch se rozhodně nezapře.Za důležité považuji důslednější oddělení aplikací na desktopu. Zatímco serverové služby běží každá pod svým uživatelem a nemůžou si jen tak navzájem požírat data (i když i tam je co vylepšovat, ale není to tak akutní). Na desktopu běží všechny aplikace pod daným uživatelem, se stejnými právy a přístupem ke všem zdrojům daného uživatele. Tohle je potřeba oddělit – aby aplikace, které ke své činnosti nepotřebují síť nemohly po síti komunikovat, aby většina aplikací nemohla číst soukromé klíče uživatele, aby hudební přehrávač nemohl číst fotky a poštu uživatele, aby grafický editor nemohl do e-mailu, hudby, konfigurace www prohlížeče, aby uživatel mohl mít víc spolehlivě oddělených profilů prohlížeče (např. jeden pro internetové bankovnictví, jeden na běžnou činnost, jeden vývojářský/testovací s všemožnými doplňky)… zároveň spolu aplikace musí umět komunikovat přes nějaká API/sběrnici (např. když chci poslat obrázek e-mailem), musí to být pod kontrolou uživatele (správce nebo distributor zvolí nějaké výchozí nastavení, ale uživatel musí mít možnost si určit např. přísnější pravidla pro některé aplikace nebo naopak něco povolit – někdo chce, aby mu hudební přehrávač stahoval obaly CD z internetu, někdo chce mít radši přehrávač zcela offline bez jakékoli interakce s okolím) a celé to musí být podporované grafickým subsystémem, ať už nějaký firewall na úrovni X serveru nebo něco modernějšího jako Wayland.