Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Na MojeFedora.cz byl vydán třídílný seriál na téma Docker ve Fedoře: Začínáme s Dockerem na Fedoře, Stavíme svůj první Docker kontejner a Docker obrazy nejen pro Fedoru.
Tiskni Sdílej:
Sračky vevnitř jsou jiný problém, který s dockerem nemá mnoho společného. Problém je, že docker neškáluje.
Nahoře se je dotaz, jak se aktualizují knihovny uvnitř kontejneru. Odpověď je, že se sestaví nový obraz z opravených knihoven. Problém je, že takový obraz může mít stovky megabajtů, které se musí při instalaci přenést na každý stroj. Docker sice umí přenášet rozdíly mezi obrazy, ale jen po linii dědičnosti obrazů. Jenže systémové knihovny jsou obvykle schovány v dalekém předku, takže to nemá smysl.
Jiný přístup je v existujícím obraze zaktualizovat jednu knihovnu a rozdistribuovat nový obraz jako poděděný rozdíl. Tohle škáluje při instalaci, ale ne při samotné aktualizaci. Pokud totiž takových obrazů pro různé produkty máte na starost stovky, tak přestává být možné udržet si přehled, který jste už aktualizoval, který ne a který aktualizaci nepotřebuje. Takže jste nakonec tam, kde jste byl před tím s klasickou distribucí s balíčky.
To že docker pužívají hostingy jako "vps", to že docker na produkci instalují programátoři, to že většina balíčků ve veřejném hub jsou sračky napsané zase jen programátory je realita, z které ale také nejsem nadšeny.Ta snaha navazet se do programatoru je komicka. Z dobreho programatora se znalosti systemu je jednoduzsi udelat administratora nez naopak, a tim se nezastavam lidi kteri nekam placnou ubastleny docker a pak se vykaslou na udrzbu.
Pokud programátor zná linux, žádný problém, potkal jsem ale desítky programátorů a opravdu znalost linuxu není častá ;)Totez plati od adminech. Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.
Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.:D
To, co se běžně prezentuje jako kontejnery, ano. Docker umí údajně využít i unionfs a to už by mohlo být zajímavější - spousta knihoven by se dala "zabalíčkovat" do menšího množství vysokorúrovňových obrazů, nad kterými by se stavěly samotné aplikační kontejnery. V případě bezpečnostního problému by se prostě vytvořil nový image opravené knihovny.
Kromě nevýhody drobné ztráty místa na disku to má nespornou výhodu - vyšší vrstvy můžete "přesunout" na fixnutou verzi až budete chtít, ne s dalším restartem služby nebo stroje. Nad tímhle zajásá každý, kdo musí udržovat closed-source kritické firemní aplikace, které psala banda neandrtálců a které se podaří nastartovat až na 3. pokus a s tou správnou verzí libm.
Kontejnery mají smysl hlavně u služeb, které mají více daemonů, stavových souborů či socketů někde ve /var
- dají se schovat do jednoho kontejneru se snadným on/off vypínačem, který nejenže "čistě" zabije všechny související procesy, ale odmountuje všechny mountpointy, uvolní sdílené IPC prostředky, apod.
A co teprve použití takovýchto kontejnerů s btrfs snapshoty -- je libo bezstavové služby?
Nevýhoda? Někdo by musel udržovat vrstvené obrazy podobně jako distribuce udržují balíčky a to se nikomu nechce. Je daleko jednodušší do kontejneru nacpat celou distribuci a v ní spustit jednu službu.