Byl vydán Linux Mint 22.1 s kódovým jménem Xia. Podrobnosti v přehledu novinek a poznámkách k vydání. Linux Mint 22.1 bude podporován do roku 2029.
Google Chrome 132 byl prohlášen za stabilní. Nejnovější stabilní verze 132.0.6834.83 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 16 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Byla vydána verze 11.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 11.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 3.4.0 nástroje pro inkrementální kopírování souborů rsync (Wikipedie). Přehled oprav a vylepšení v souboru NEWS. Řešeno je 6 zranitelností.
V srpnu loňského roku byla vyhlášena RP2350 Hacking Challenge aneb oficiální výzva Raspberry Pi na prolomení bezpečnosti mikrokontroléru RP2350. Povedlo se. Včera byli představeni čtyři vítězové a jejich techniky.
Na čem aktuálně pracují vývojáři open source operačního systému Haiku (Wikipedie)? Byl publikován přehled vývoje za prosinec 2024. Vypíchnuto je začlenění webového prohlížeče Iceweasel, tj. alternativního sestavení Firefoxu.
Tetris a DOOM běžící v pdf. Proč a jak v příspěvku na blogu.
Společnost Oracle představila sadu nástrojů a skriptů pro sběr a analýzu dat o stavu linuxových systémů a jejich ladění pod společným názvem Oracle Linux Enhanced Diagnostics (OLED). K dispozici pod licencí GPLv2.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzi 2.3.0. Přináší RAIDZ Expansion, Fast Dedup, Direct IO, JSON a Long names.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu lednový souhrn novinek.
U příležitosti oslav sedmi let prací na debianím balíčku vyšlo GPXSee 13.33. Nová verze přináší rychlejší vykreslování vektorových map a vylepšení/doladění nového stylu pro OpenAndroMaps/Mapsforge mapy. Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Tiskni Sdílej:
Na webu je podobných aplikací spousta, cílem je právě mít něco rychlého "lokálního". U prohlížení několika GB map si pak posílání na web nedovedu představit vůbec (co vím, tak přístup k lokálním souborům v prohlížeči spíš nefunguje, než funguje...).
Co se týče Maců, tak ty oficiální buildy se samozřejmě testují, ale jsou jenom x86-64, protože zájem uživatelů nestačí ani na nákup ARM železa... Pro ARM to nicméně balíčkují Macports, ale jak dobře jim to funguje netuším, neb to nemám na čem vyzkoušet.
umí to zobrazit openseamap?
Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.Což krom pár geeků reálně nikdo neudělá. Fajn by byl spíše (oficiální) Flatpak.
pár dní, než se objeví v jejich distribuciCož je třeba v případě Ubuntu půl roku (či dva roky u LTS).
Tak to přidej. V Ubuntu, stejně tak jako v čemkoliv jiném založeném na Debianu, je to minimálně 7 let a odpočet stále běží...
Nicméně to je volba těch lidí, co si Debian(Ubuntu) vybrali a pokud jim to tak vyhovuje, je to jejich věc. Pokud s tím mají problém, vždycky můžou zvolit nějakou moderní distribuci. Distribuce vhodné k provozování moderního desktopu mají to zpoždění v úplně jiných řádech. Představa, že celý svět bude produkovat nějaký pseudobalíčky typu Snap, Flatpak či AppImage jenom proto, že Debianistům (a jejich příbuzným) trvá "normální" distribuce SW roky, je prostě zvrácená.
Nejsou aplikace instalované z repozitářů třetích stran potenciálně rizikovější než ty typu flatpak umožňující jejich sandboxing?
Nejsou. To si myslí akorát lidé, kteří vývojářům říkají: "Já si od tebe rád zadarmo vezmu výsledek tisíců hodin tvé práce, ale stejně si myslím, že jseš zmrd a chceš mě ojebat!". Reálně jsou staticky linkované aplikace (nebo jejich hipsterské alternativy) mnohem děravější a zabugovanější, protože knihovny v nich nikdo neupdatuje.
Co je kritériem rozhodujícím o špatnosti popsaných řešení?
Velikost, rychlost a aktuálnost použitých knihoven.
Co brání autorům vydávat periodické statické buildy z prostředí postaveném na posledních verzích (budeme předpokládat těch se známými zranitelnostmi opravenými) potřebných knihoven (samozřejmě pokud to kompatibilita src dotyčného programu unese)?
Nemají na to prostředky.
Pokud koncový uživatel periodicky ověřuje existenci novější verze programu v repository, mělo by se mu tak dostat bezpečnějšího produktu. Možná dokonce v předstihu než tyto verze knihoven uvolní (případně záplaty backportuje) jeho OS distribuce a to včetně těch s rolling release.
Jistě, teoreticky taková situace může nastat. Ale prakticky (statisticky) se to neděje a těžko předpokládat, že tuto duplikaci práce distribucí najednou začnou vývojáři s nadšením dělat jenom proto, že to tobě přijde jako skvělý nápad. To že jsme se v Linuxu dostali od "statické" prehistorie k současnému stavu distribuce balíčků má své dobré důvody.