Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Společnost Red Hat oznámila vydání Red Hat Enterprise Linuxu 7.4, který přináší vedle nových vlastností a oprav chyb také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tiskni Sdílej:
Staci vyhodit/vyradit/nedelat vsechny ty optimalizace kvuli rotacnimu mediu.To jsem mel na mysli, nikoliv CoW. Mohout to byt pomerne zasadni zmeny, zasah do designu a prepis kodu.
...
V cem je kousek problem je stara implementace, ktera moc nepocitala s tak low latency storage, postupne se ZFS kod prekopava na lock-free mechanismy nebo aspon na skalovatelnejsi zamykani.
We should not just copy ZFS. ZFS is now fifteen years old and the storage landscape has changed since its design.
Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved.
9. Implementable in 1-2 years
(a) We’re already behind, waiting another 10 years isn’t an option
Zajimave. Jak se zda, btrfs je po letech stale natolik problematicky souborovy system, ze Red Hat dosel k zaveru ze potencialni problemy zakazniku, ktere by musel v ramci jejich podpory resit a pripadny risk spojeny se ztratou dat nevyvazi jeho prakticky prinos ve srovnani xfs/lvm/mdraid.
Ono to až tak úplně takhle není, i když se to jejich markeťáci pochopitelně budou snažit tvrdit nebo aspoň naznačovat, aby zákazníky odradili od SLESu.
Spíš jde o to, že u enterprise distribucí vládne filosofie "one tool per task", kterou sice osobně považuji za velmi nebezpečnou a škodlivou, ale chápu, že z obchodního hlediska smysl dává. O každou možnost volby mezi dvěma řešeními je potřeba tvrdě bojovat. Red Hat se prostě rozhodl preferovat jiné řešení a své zdroje soustředit na něj. To je celé, neznamená to automaticky, že ostatní řešení jsou a priori špatná.
Ono to až tak úplně takhle není, i když se to jejich markeťáci pochopitelně budou snažit tvrdit nebo aspoň naznačovat, aby zákazníky odradili od SLESu.Vcera jsem v rychlosti projel btrfs mailing list a podival se do git logu. Muj zaver je, ze je tam stale spousta problemu a zmen v kodu, a skutecne to nebudi dojem ze btfrs je v producknim a stabilizovanem stavu, coz je po deseti letech vyvoje celkem smutne.
Spíš jde o to, že u enterprise distribucí vládne filosofie "one tool per task", kterou sice osobně považuji za velmi nebezpečnou a škodlivou, ale chápu, že z obchodního hlediska smysl dává.One tool per task je btrfs, ktere integruje vse dohromady. Nemyslim, ze by se Red Hat dlouhodobe zbavoval takoveho reseni, pokud by mel dojem ze to nekam vede, ostatne Fedora se mnohokrat pokusela pouzit btrfs jako defaultni system a vzdy to bylo zastaveno technickymi problemy.
Vcera jsem v rychlosti projel btrfs mailing list a podival se do git logu. Muj zaver je, ze je tam stale spousta problemu a zmen v kodu, a skutecne to nebudi dojem ze btfrs je v producknim a stabilizovanem stavu, coz je po deseti letech vyvoje celkem smutne.
Především je potřeba si uvědomit, že btrfs není jeden nedělitelný monolit. Je to živý kód, kde stále přibývají nové featury, a je pochopitelné, že ty nové části jsou v méně zralém stavu než ty starší. To, že ve SLESu je podporovaný btrfs, neznamená automaticky, že jsou podporované všechny jeho featury včetně těch, ze kterých ještě kape barva.
One tool per task je btrfs, ktere integruje vse dohromady.
To není "one tool per task", to je spíš "one tool for all task" - koneckonců je to jeden z důvodů, proč osobně btrfs nijak v lásce nemám. Princip "one tool per task" spočívá v tom, že tam, kde jsou dvě řešení s podobnou funkcionalitu, se jedno vybere a druhé zahodí. Např. sendmail a postfix, syslog-ng a rsyslog apod. V tomto případě je to XFS+LVM+??? vs. btrfs.
Nemyslim, ze by se Red Hat dlouhodobe zbavoval takoveho reseni, pokud by mel dojem ze to nekam vede,
Tady máte třeba komentář Josefa Bacíka, který o tom celkem jistě ví víc než kdokoli z nás.
ostatne Fedora se mnohokrat pokusela pouzit btrfs jako defaultni system a vzdy to bylo zastaveno technickymi problemy
Do vývoje Fedory nevidím. V openSUSE je jako default už pár let a problémy samozřejmě jsou, ale co jsem vypozoroval, většina z nich není primárně způsobena btrfs jako takovým, ale nepříliš šťastným rozhodnutím defaultně všem zapnout snapper a dělat snapshoty, kdykoli by mohly být jen trochu potřeba, jako by snad všichni měli nekonečně velké disky.
Pro pořádek: nejsem žádný fanda btrfs, na svých strojích ho nikde nemám a ani nemám v plánu to v dohledné době změnit. Ale nelíbí se mi ta (bohužel očekávaná) reakce ve stylu "Red Hat od toho dává ruce pryč, to musí být naprostý shit."
Btrfs je mozna pouzitelny pro takove ty domaci hratky kde si to porno proste stahnes znovu, ale mit ho nekde na storage ke kteremu pristupuji stovky nebo tisice lidi je nerealne. Jako technologicke preview dobry, ale do produkce bych ho nedal.+1
Já ho taky nikde nemám (jak už jsem ostatně psal), ale to je hlavně proto, že jsem usoudil, že by mi to přineslo komplikace navíc, zatímco pro výhody, které bych tím získal, většinou nemám moc využití.
Námět k zamyšlení: ve SLESu je btrfs IIRC podporovaný někdy od SLE11 SP3. To mimo jiné znamená, že se musíme zabývat bugy nahlášenými zákazníky a řešení každého takového bugu znamená pro firmu nemalé náklady. Každý zákazník, který by kvůli btrfs ztratil důvěru ve SLES nebo naše produkty obecně (a ruku na srdce, horší bugy než rozbitý filesystém nebo tiše poškozená data v podstatě neexistují) znamená obrovskou ztrátu peněz. Přesto jsem zatím nezaznamenal, že management docházel k názoru, že sázka na btrfs byla omyl a že na tom proděláváme kalhoty. Nevím jak vám, ale mně z toho vychází, že to asi zase až taková katastrofa nebude. Ne že by bugy nebyly a ano, je jich víc než třeba na ext4 (s XFS bych řekl asi tak srovnatelně, ale to je jen odhad, statistiku si nevedu), ale ten obraz všeobecného zmaru a utrpení, kteří tady někteří malují, to taky není.
Je to živý kód, kde stále přibývají nové featury, a je pochopitelné, že ty nové části jsou v méně zralém stavu než ty starší.Ale co vlastne funguje? Zatim vidim spoustu spekulaci a dohadu, a lide ze zoufalstvi tvori tabulky jako zde. Odpoved od Chris Mason neprozradi nic, v podstate v tomtu duchu se opakuje jiz roky.
Tady máte třeba komentář Josefa Bacíka, který o tom celkem jistě ví víc než kdokoli z nás.To je otazka, on jiz je dlouho mimo Red Hat, ale kontakty asi mit bude. Nicmene nechce se mi verit, ze pokud by Red Hat skutecne mel zajem, nemuze si vychovat vyvojare, v podstate je to otazka penez ochotnych do toho dlouhodobe investovat.
Ale nelíbí se mi ta (bohužel očekávaná) reakce ve stylu "Red Hat od toho dává ruce pryč, to musí být naprostý shit."Takhle to postavene nebylo. Red Hat spise rika, ze ztratit nadeji, ze v dohledne dobe bude situace lepsi a hleda jine reseni. Kdyz jde o dulezita data, kazdy nastroj je shit dokud neprokaze jinak.
Ale co vlastne funguje?Co zkusit navštívit stránky projektu?
Send OK corner cases may still exist
Pokud bych tomu verilAha, čili předtím šlo o řečnickou otázku (protože lepší informace asi nedostanete a pokud byste je i dostal, věřit jim asi nebudete úplně stejně). Potom tedy pardon...
Aha, čili předtím šlo o řečnickou otázkuNe.
protože lepší informace asi nedostanete a pokud byste je i dostal, věřit jim asi nebudete úplně stejněNikoliv, jen po letech uz nemam velkou duveru v btrfs team, jejich tvrzeni o stavu projektu a v jejich schopnost problemy v dohledne dobe vyresit.
Nicmene nechce se mi verit, ze pokud by Red Hat skutecne mel zajem,A tohle Red Hat neumi. Cokoliv novyho, co chce delat, musi nakoupit z venku, interni projekty psany od nuly vevnitr jsou vetsinou naprosty fial. Red Hatu failuje jeho management struktura, nezvladnou pracovat s makacema a zustavaj jim akorat lopaty, ktery jsou ale bez napadu. Aspon soude podle toho, co se tu deje v Brne dlouhodobe .
OK, no a cim teda nahradit: