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.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Řešení tohoto přídavného, v nedávné minulosti vzniklého problému není úplně jednoduché: musíme přemýšlet, před které příkazy LC_ALL=C
napsat, protože když to napíšeme příliš často, UTF-8 se nezpracuje tak, jak se zpracovat má. Nestačí to psát jen občas – v modelovém příkladě použití pouze jednoho LC_ALL=C
vedlo pouze ke trojnásobnému zrychlení. Navíc – čekali byste, že to výrazně lépe pomůže u druhého sort
u, který zpracovával menší počet řádků než sort
první?
Na sborník řečí všech amerických prezidentů narazíme dále v tomto díle.
Zdroj: C-SPAN
Vyrobíme si tedy statistiku rozložení délek souboru ještě jednou, úplně stejnou, ale zato mnohem rychleji. Vpravo bude délka souboru, vlevo jak často se vyskytuje. Zobrazíme 20 nejčastěji se vyskytujících délek, seřazených sestupně podle toho, jak často se vyskytují. Závorky kolem exportu zamezí, aby nám nastavení LC_ALL=C
v shellu zůstalo permanentně, až do doby odhlášení se ze shellu.
$ ( export LC_ALL=C; cut -f 7 -d ' ' clean2.txt |sort -n |uniq -c | sort -nrk1 | head -n 20) 23 11009 15 12911 13 21607 12 12888 12 12867 9 1405 9 12927 9 12900 9 12897 9 12887 8 21586 8 12891 8 12858 7 12912 7 12879 7 12864 6 59 6 12906 6 12905 6 12890
Jak je možné, že délka 11009 se vyskytuje tak často – 23krát – a jiná délka 12890, která se liší o pouhých 17 procent, se vyskytuje jen šestkrát? Záhadu se nám podaří vyřešit, aniž bychom se podívali do jediného souboru – použijeme pouze informace z výpisu adresářů:
$ cut -d ' ' -f 7,11- clean2.txt | LC_ALL=C grep "^11009 " 11009 pg/1/2/7/2/12721/readme-license.txt 11009 pg/1/2/7/2/12724/readme- license.txt 11009 pg/1/2/7/2/12723/readme- license.txt 11009 pg/1/2/7/2/12720/readme- license.txt 11009 pg/1/2/7/2/12722/readme- license.txt [...] 11009 pg/1/2/7/1/12719/readme- license.txt 11009 pg/1/2/7/1/12715/readme- license.txt 11009 pg/1/2/7/1/12713/readme- license.txt 11009 pg/1/2/7/1/12711/readme- license.txt
Jsou to všechno zřejmě identické kopie nějakého licenčního textu! A co ostatní mysteriózní čísla? Délka 12911 je stejného druhu jako délka 11009. 21607 je ale už něco jiného: je to jakýsi prázdný skutečný text, který nám říká, že příslušné dílo sestává zcela z obrázků, a proto se máme podívat na HTML verzi, kde jsou tyto obrázky dostupné. To vysvětluje, proč jsou všechny tyto soubory tohoto druhu stejně dlouhé. Mysteriózní číslo 12888 přísluší k jakýmsi audio knihám nahraným jako MP3. Ostatní mysteriózní často se opakující délky si můžete prozkoumat sami, co se pod nimi skrývá.
Možná vyrobíme užitečnější statistiku, když budeme řadit podle délky souboru místo podle toho, jak často se délka souboru opakuje. Stačí změnit parametry druhého sort
u:
$ ( export LC_ALL=C; cut -f 7 -d ' ' clean2.txt |sort -n |uniq -c | sort -nk2 | head -n 20) 2 52 6 59 1 68 2 76 1 78 5 80 1 83 1 95 1 130 1 145 1 158 1 185 1 203 1 274 1 301 1 312 1 331 1 336 1 344 1 345
Na Ságu rodu Forsytů, za kterou padla Nobelova cena, dojde také.
Zdroj: Nakladatelství Omega
Dozvěděli jsme se v zásadě to, že se nic nedozvíme: každý soubor má svou vlastní délku, která se neopakuje. Co tedy seřadit soubory od těch největších? Co za zábavné čtivo v nich bude?
$ cut -d ' ' -f 7,11- clean2.txt |LC_ALL=C sort -nrk1|head -n 10 9877862 pg/5/0/5/5050/old/suall11.txt 9873495 pg/5/0/5/5050/old/suall10.txt 9840067 pg/4/9/0/4900/old/jm00v10.txt 9790441 pg/4/9/0/4900/4900.txt 9612317 pg/5/4/0/5400/old/wc63w10.txt 9540257 pg/5/4/0/5400/5400.txt 9472285 pg/3/2/5/3254/old/glent12.txt 9459826 pg/3/2/5/3254/3254.txt 9206456 pg/2/7/3/4/27348/27348.txt 9201354 pg/2/7/5/0/27509/27509.txt
Mínus za jedenáctkou je pro případ, že by jméno souboru obsahovalo mezeru, což na Unixech může. cut
by to interpretoval jako další sloupec, takto se ho dozvíme celé. Takových minových polí, kde člověk musí myslet na různé neobvyklé výjimky, je v Unixu bohužel mnoho. Je to dáno použitím in-band signallingu, tedy speciálních znaků, jako jsou mezery, uvozovky, lomítka apod., se speciálním významem. Pokud programátor nemá v daný moment dostatečnou fantazii a neuvědomí si, co všechny by mohlo způsobit problém a na co všechno musí myslet, vyprodukuje kód který bude fungovat, projde testy, ale selže v okamžiku kdy ho uživatel nakrmí souborem, jehož jméno obsahuje mezeru.
Myslíte, že se tento problém dá řešit testováním? Ale jestliže si programátor neuvědomí, že by mezera mohla způsobit problém, proč by si to měl uvědomit návrhář testu a zakomponovat ji do testu? Je návrhář testu nějaký jiný živočišný druh než programátor, který je na rozdíl od člověka s omezenou kapacitou předvídat neobvyklé problémy vševědoucí a má nekonečně velkou fantazii?
Podle mě se takový problém dá spolehlivě řešit použitím out-of-band signallingu, tedy např. binárních hlaviček s délkami při předávání příkazů. To by ale byl takový zásah do koncepce Unixu, že mi nepřijde realistický. Jako poučné varování to ale mohou vzít čtenáři, kteří navrhují nový software nebo datový formát, aby problému tohoto druhu předešli a zvážili out-of-band signaling, když to ještě jde.
Podíváme se do souborů a abychom jejich jména nemuseli opisovat, z výstupu příkazu vystřihneme druhý sloupec a předáme ho jako argument vi
na příkazovou řádku.
V souborech se pak budeme moci pohybovat pomocí :n
(následující soubor) a :N
(předchozí soubor).
vi -R $(cut -d ' ' -f 7,11- clean2.txt |LC_ALL=C sort -nrk1|cut -d ' ' -f 2- | head -n 9)
Přepínač -R
uvede vi
do režimu pro čtení, takže si literární díla omylem nezměníme. Co tyto největší soubory tedy obsahují?
Aktuální obálka World CIA Factbook
Ukončíme zkoumání délek souborů a v příštím dílu přistoupíme k jejich obsahu.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: