Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
Příručka Linux From Scratch pro sestavení základního linuxového systému byla aktualizována v pravidelném půlročním termínu. Vydání 13.1 shrnuje přes 40 nových verzí balíčků a několik patchů. Navazující příručka Beyond Linux From Scratch s recepty pro sestavení dalších knihoven a aplikací zatím vydána nebyla, ačkoliv vývojová verze stále dostává aktualizace. Lze je číst online nebo stáhnout v HTML či PDF.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
BetaNews představuje žebříček 10 nejlepších novinek systému Windows Server 2008 oproti předchozím Windows. Je zajímavé podívat se, co v tomto ohledu nabízí GNU/Linux.
Následující seznam bude seřazen podle toho, jak to vidí autor původního článku - nejvýznamnější novinka jako první. U každého bodu to okomentuji z pohledu uživatele GNU/Linuxu.
Bude se jednat o možnost běhu bez GUI - tedy něco, co má Linux odnepaměti a unixové systémy obecně již dávno před tím, než začal Bill Gates bastlit v garáži MS DOS 1.0. Spíš je s podivem že to trvalo tak dlouho. Na druhou stranu je vidět, že platí to, co Microsoft dlouho odmítal - tedy že admini klidně oželí žravé GUI, které na serveru stejně nemá smysl.
Bez zajímavosti není, že zatím nebude podporován .NET (přitom Mono na negrafických linuxových strojích nemá problémy). Prý později, až z toho vykuchají pevně vrostlou grafiku.
Další důkaz důležitosti příkazové řádky na serveru, která na Linuxu i jiných unixech nabízí hned celou škálu výborných shellů. Když nechám stranou problematický Windows Scripting Host, jde o první skutečně použitelný shell na Windows přímo od Microsoftu. Kdo chtěl dříve pořádnou příkazovou řádku, musel si vypomoci Cygwinem nebo MinGW.
Je to jeden z fenomenů dnešní doby. Microsoft to zatím vcelku zanedbával. Jeho Virtual PC bylo dobré maximálně za zkoušení, nedalo se srovnávat s VMWare. Ale virtualizace s hardwarovou podporou a paravirtulizace nešly s Windows dohromady. Naopak GNU/Linux disponuje již dnes výbornou podporou virtualizačních a paravirtualizačních technologií.
Podle všeho by se mělo jednat o standardizovaný způsob hlášení problémů v ovladačích a dalších součástech systému. Něco takového v Linuxu chybí a rozhodně by neškodilo o tom také uvažovat (malá poznámka: Microsoft už na to nepochybně drží patent). Ovladače zatím hlásí stylem "každý pes jiná ves", a to není zrovna dobré.
Náhodné umísťování knihoven a programů v adresním prostoru Linux podporuje už dlouho. Pravda, vždy se objevovalo mnoho odpůrců takového řešení (hlavně kvůli obtížnějšímu hledání chyb). Nicméně ta možnost tu prostě je a kdo ji chce používat, může. Nyní tedy i ve Windows.
Nový SMB protokol (kolikátý už?) prý přináší až čtyřicetinásobné zrychlení. Docela tomu věřím, pomalost SMB při komunikaci Windows-Windows (hlavně různých verzí) byla přímo pověstná. Byla docela zábava pozorovat, jak se s ním popasovával Linux. Zrychlení oproti Windows bylo velice drastické. Nový protokol přinese Linuxu samozřejmě problémy - dost dlouho nebude existovat implementace, proto z nového protokolu zatím žádné zlepšení interoperability s Windows nehrozí.
Registry bývaly po celou dobu své existence bolavou nohou Windows - a uživatelům přinášely časté bolení hlavy. Poškození bývalo běžnou věcí, stejně jako problémy s výkonem nebo se sledováním změn. Dokonce ani některé programy od Microsoftu registry raději nepoužívaly. Nově by se měl pro tyto operace používat správce transakcí, který by udržel konzistenci (transakčním způsobem práce).
No, v Linuxu nic takového není. Pro přímé řízení systému je k dispozici procfs (základní funkcionalita) a sysfs (ovladače), pro konfiguraci se používají soubory, případně nějaký jiný způsob podle konkrétní aplikace. Registrové problémy (jako třeba zmizení celého podstromu po instalaci patche do systému) tedy uživatele GNU/Linuxu nikdy netrápily. Byly a jsou sice problémy jiného druhu - s roztříštěností a nejednotností - ale to je spíš problém tvůrců aplikací.
Ještě připomenu, že využití pro registry je jen jednou z oblastí použití KTM (i když asi nejvýznamnější). Tvůrci se totiž chlubí mj. distribuovanými transakcemi s možností kooperace s MS SQL a dalšími databázemi. Tedy tohle v kernelu? No potěš koště...
Dosavadní praxe byla, že při ukončování systému měly procesy na své ukončení 20 sekund. Když čas vypršel, vyskočil dotaz na nečisté ukončení. Nyní to tak už nebude - pokud bude proces signalizovat, že se opravdu ukončuje, bude systém stále čekat na jeho ukončení.
Tahle věc nemá v GNU/Linuxu přímé srovnání. Vzhledem k tomu, jak jsou řešeny procesy a jejich ukončování, a vzhledem k různému řešení u různých distribucí, to lze opravdu těžko srovnávat. V každém případě Microsoftem použité řešení bude mít problémy s aplikacemi, které se budou jakoby ukončovat, ale ve skutečnosti budou někde uvízlé. Možná se už něco takového dostalo i do WinXP - a zřejmě od té doby mám problémy s vypínáním/restartem počítačů s Windows.
K tomu snad není co dodat. Windows byly tradičně jednouživatelským systémem, a jakékoli snahy o práci více uživatelů narážely na kupu problémů. Třeba už to teď bude lepší (dříve postupné vytváření sessions by se mělo paralelizovat). Naproti tomu Linux (a také další unixové systémy) je víceuživatelský už z principu. Současná práce většího počtu uživatelů (v konzoli i v grafice) není absolutně problém, a to ani výkonnostní. K linuxovým počítačům se běžně připojují vzdálené terminály, dokonce ani současná lokální práce uživatelů není problém (např. 4 monitory, 4 klávesnice, 4 myši). Vytváření sessions je velmi rychlé, záleží jen na tom, co všechno se případně provádí při přihlašování do desktopového prostředí.
Mělo by to fungovat tak, že když nastane problém ve filesystému, chyba se opraví za běhu (bez odstavení systému) - pouze příslušná aplikace se nějakou dobu nedostane k datům. Upřímně řečeno, nevím, že by toto v Linuxu nějaký filesystém podporoval. V zásadě by neměl být problém to napsat, ale je otázka, zda to má vůbec smysl. Poškození filesystému přímo za běhu systému je krajně vzácné (obvykle nastává při výpadku napájení) - a když nastane, tak je to buď chyba v ovladači (filesystému nebo disku), ale častěji spíš hardwarový problém. Pak je toto řešení spíš takovým strkáním hlavy do písku, které může následně přinést mnohem horší problémy.
Co si z toho vzít? Některé věci jsou docela podnětné, něčemu se člověk může jen smát, a něco je prostě důkaz o tom, že jsou některé věci poněkud jinak, než se Microsoft snažil dlouho tvrdit.
Tiskni
Sdílej:
Pak by se to ale nemělo jmenovat Windows 
Bude se jednat o možnost běhu bez GUI...Tak třeba jenom Parapetous...Pak by se to ale nemělo jmenovat Windows
"Monad napr. dovoľuje prechádzať sa po registrových kľúčoch tak, ako po adresároch."Mně ale bash prochází po
/etc/sysconfig přesně jako po adresářích... :o)
ak by sa tam objavil SW, ktory by sa ukoncoval dlhsie ako je ten timeout, tak ho to proste ukonci natvrdo - tomuto sa prave Win bude snazit predist.To budou uzivatele nadseni, az se bude pocitac restartovat pul dne, protoze se nejaka aplikace zblaznila a nechce se ukoncit. Mozna by se MS mel zamyslel na tim, co timhle 'vylepsenim' chce docilit.
. Pravda, není to úplně totéž a je to věc Gnome, ale minimálně se to z uživatelského hlediska tak tváří. Naštěstí Gnome tolik nepoužívám, abych zjistil, jestli se to tak i chová
.
). Nicméně si určitě seženu další informace, abych byl víc v obraze
.
No a mé dojmy jsou takové, že někdy v prosinci jsem cosi nainstaloval a ono to nejelo
. Aplikace blábolila cosi o chybějících klíčích v GConf. Tak jsem pátral až jsem zjistil, že jsem měl špatně udělanej balíček, který ty záznamy nevytvořil a aplikace se proto nechtěla spouštět, protože jí chyběly nějaké údaje. Chvíli jsem se hrabal v gconf-editoru, který mi náramně připomínal regedit, až jsem nakonec stáhl jiný balíček, který byl vpořádku. Tak jsem to dál neřešil... Jinak imho to, jestli aplikace pojede i bez záznamů v registrech/gconfu záleží čistě na programátorovi a na tom, jak to naprogramoval. Nebo má gconf nějaký způsob, jak od programátora odstínit rozdíl mezi chybějícím záznamem a prázdným řetězcem, resp. jak si vymyslet hodnotu, která by v tom neexistujícím klíči měla být
?
GConf i windowsové registry vznikly zřejmě za stejným účelem, ale to je asi tak všechno.ok, s tímhle názorem jsem ochoten se ztotožnit
Apple nic nezkopíroval, Apple se s Xeroxem úplně normálně dohodl (dokonce jim lidé z Xeroxu pomáhali) a zaplatil za to vlastními akciemi (skoro dvacet milionů dolarů v hodnotě ze začátku 80. let).Já to vím. O kopírování jsem hovořil v nadsázce. Je to úplně stejné, jako jsem hovořil o tom DOSu 1.0.
Pracuješ pro Microsoft?Něco tak zábavného už jsem dlouho neslyšel