Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Ale na druhou stranu, kdyz nekoho nerozhodi stacktrace v logu pri kopirovani dat...Asi tak. Absolutně nepochopim, jak může někdo neironicky / na svoje reálný data používat filesystem, který vykazuje takovouhle nestabilitu a asi zřejmě špatnou testovanost. No ale můj problém to není a kdo chce kam, pomožme mu tam... Nicméně zápisek je pro mě přínosem v tom, že je fajn vědět, že btrfs je stále ještě v takovémhle stavu, takže díky za to...
Btrfs tehdy snad ani neexistoval.Mluvíš z hladu. Viz níže. Jinak "warning" není chyba. Pokud tuhle nuanci nechápeš, nechápu pro změnu já, co děláš v tomhle oboru.
Tam error znamena ztratu datAno, jsou souborové systémy u kterých to platí beze zbytku a pokud je Btrfs v single mode, tak rovněž. Jenomže chyba, která vede ke ztrátě dat obvykle s warningem vůbec nesouvisí. Warning je warning. Nic víc, nic míň.
Warning je warning. Nic víc, nic míň.To není pravda; není warning jako warning. Ta hláška v dmesg a ten trace je AFAIK následek makra
WARN_ON()
. Čiliže to je něco jako jemnější varianta assertu, kdy něco je špatně, ale není to tak hrozný, aby kvůli tomu musel nastal panic a vzít s sebou celý systém. Nicméně slouží to na verifikaci invariantů (minimálně takový je účel), proto to taky bleje stack trace a další informace, aby se to dalo debugovat. Pokud btrfs narzí na chybu, měl by ji detekovat a nějakým vhodným způsobem sdělit uživateli. Pokud to v kódu naráží na WARN_ON()
a ty musíš procházet zdrojáky jádra nebo někde jinde podrobně zkoumat, co se děje, tak je IMO něco špatně.
Souhlasim s tebou, že ten warning trace nemusí nutně být a asi není symptomem nějakého iminentního fatálního selhání, nicméně z mého pohledu ten trace i to popisováné chování a jak jsi zjišťoval, co je teda vlastně špatně, ukazuje na špatnou kvalitu toho kódu a/nebo nedostatečné testování.
Diskove oddily davaji smysl vzdycky, protoze to jak funguji veci bez diskovych oddilu nikdo netestuje.To je pravda. A nejen v případě oddílů, ale i všech voleb filesystému obecně. Pokud něco není buď default nebo popsáno jako doporučená konfigurace pro nějaký konrétní typ nasazení, není moc pravděpodobné, že by to někdo před vámi nějak vážně zkoušel, natož testoval. Nicméně použití btrfs na dedikovaném blokovém zařízení bez oddílů není ten případ, protože btrfs v sobě zahrnuje jak volume management tak filesystém. Na druhou stranu existuje několik důvodů proč dávat brfs na oddíl: pokud chci mít na disku oddíl s jiným filesystémem (např. kvůli bootu nebo swapu), případně pokud chci btrfs šifrovat (pak se musí dát na LUKS volume). Pokud chápu zápisek dobře, tak chyba byla naopak v tom, že se btrfs na dedikovaném zařízení dal na oddíl místo na celý disk.
512e (emulated) 512n (native) 4Kn (4096 native)Zdar Max
Tiskni
Sdílej: