Byla vydána verze 2026 distribuce programu pro počítačovou sazbu TeX s názvem TeX Live (Wikipedie). Přehled novinek v oficiální dokumentaci.
Jihokorejská Národní daňová služba (NTS) zabavila kryptoměnu Pre-retogeum (PRTG) v hodnotě 5,6 milionu dolarů. Pochlubila se v tiskové zprávě, do které vložila fotografii zabavených USB flash disků s kryptoměnovými peněženkami spolu se souvisejícími ručně napsanými mnemotechnickými obnovovacími frázemi. Krátce na to byla kryptoměna v hodnotě 4,8 milionu dolarů odcizena. O několik hodin ale vrácena, jelikož PRTG je extrémně nelikvidní, s denním objemem obchodování kolem 332 dolarů a zalistováním na jediné burze, MEXC [Bitcoin.com].
Komunita kolem Linuxu From Scratch (LFS) vydala nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů Linux From Scratch 13.0 a Beyond Linux From Scratch 13.0. Pouze se systemd.
Byla vydána nová stabilní major verze 25.12 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Jedná se o nástupce předchozí major verze 24.10. Přehled novinek v poznámkách k vydání. Podporováno je více než 2200 zařízení.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za únor (YouTube). Odstraněn byl veškerý kód napsaný ve Swiftu. JavaScriptový engine LibJS byl reimplementován v Rustu.
Byla vydána verze 1.94.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example. Zveřejněny byly výsledky průzkumu mezi vývojáři v programovacím jazyce Rust: 2025 State of Rust Survey Results.
Google zveřejnil seznam 185 organizací přijatých do letošního Google Summer of Code (GSoC). Dle plánu se zájemci přihlašují od 16. do 31. března. Vydělat si mohou od 750 do 6600 dolarů. V Česku a na Slovensku je to 900 dolarů za malý, 1800 dolarů za střední a 3600 dolarů za velký projekt. Další informace v často kladených otázkách (FAQ). K dispozici jsou také statistiky z minulých let.
Byla vydána únorová aktualizace aneb nová verze 1.110 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.110 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Apple představil 13palcový MacBook Neo s čipem A18 Pro. V základní konfiguraci za 16 990 Kč.
Kalifornský zákon AB 1043 platný od 1. ledna 2027 vyžaduje, aby operační systémy požadovaly po uživatelích věk nebo datum narození a skrze API poskytovaly aplikacím informaci, zda je uživatel mladší 13 let, má 13 až 16 let, má 16 až 18 let nebo má alespoň 18 let. Vývojáři linuxových distribucí řeší, co s tím (Ubuntu, Fedora, …).
Super článek, měl bych jen 2 poznámky ke zmenšování:
1. To, že data z disku pomocí pvmove a vgreduce přesunu pryč z /dev/sda, ještě neznamená, že tento disk můžu za chodu z mašiny vyrvat. Pokud je to SCSI/SATA/SAS disk, pak se musí ještě udělat:
cat "scsi remove-single-device x y z w" > /proc/scsi/scsi
kde x,y,z,w je SCSI adresa disku. Tímto řeknu jádru, co se právě snažím udělat. Pokud někdo či něco zařízení používá, tento příkaz selže a disk musím v mašině nechat!
2. Ke zmenšování ext3 - pokud jsme již oddíl předtím zmenšili ale už přesně nevíme o kolik, tak je vhodné zjistit si jeho skutečnou velikost (a to né příkazem df -m). Pomůže toto:
[root@dorado /]# dumpe2fs /dev/VolGroup00/LogVol01 | head -40 | grep Block
dumpe2fs 1.39 (29-May-2006)
Block count: 2359296
Block size: 4096
Blocks per group: 32768
Kde:
Block size je velikost bloku v bytech a Block count je počet bloků které FS využívá ... takže v našem případku je velikost filesystému 2359296*4096 bytů což je přesně 9Gb. Takže mohu bezpečně udělat:
lvresize --size 9G /dev/VolGroup00/LogVol01
pvremove lze již disk fyzicky vyjmout, to rozhodně nejde. Rada ohledně zjištění přesné velikosti ext3 je velmi dobrá. Díky moc za doplnění.
heh, asi spíš echo "...." > ... zajímavý, že já v tom taky pravidelně chybuju :)
Jojo, to je ono. echo tam má bejt. Pardón.
Ahoj,
ano clanek je super. Je tam presne to co jsem vzdy potreboval a musel hledat pres Google. Pochvalen bud autor 
Me by spise zajimalo, jesli nemuze mit velikost LVM nejaky spatny vliv na rychlost disku. Mam 3.5T (v ReiserFS) a je to strasne pomale. Ale jen kdyz se poprve prihlasim (po najeti KDE) nebo pri nejakych operacich.
LVM rychlost prakticky neovlivnuje (FS vytvořený nad LVM bude stejně rychlý jako FS přímo nad klasickou partišnou).
To je pravda jen napůl - pokud nepoužíváš snapshoty, tak je to pravda. Pokud ale snapshoty používáš, tak počítej s 10-20x zpomalením diskových operací. Tohle se málo ví, tak si to lidi uvědomte.
…počítej s 10-20x zpomalením diskových operací…To se tak velke zpomaleni projevuje uz s jednim snapshotem? Prijde mi to moc, ale nevyznam se v tom a tak se ptam. Btw nekde jsem slysel, ze LVM je navrzeno jen pro jeden snapshot na LV a pri vyssim poctu snapshotu je to kvuli zpomaleni nepouzitelne, takze by teoreticky nebyl problem ziskat s dostatecnym poctem snapshotu i vetsi zpomaleni nez 20x :).
Nn, nemam to v poli. Mam 3x 1T + 1x 500G nahazene primo do VG a vytvoreny jeden LV. Kdyz potrebuji misto, koupim novy disk a jen "prifouknu" to. Netusim jestli je problem v ReiserFS, mountuji ho s noatime, notail. Ale nekdo mi kdysi rikal, ze se pry musi opatchovat kernel, pokud se pouzivaji velke disky na 2T. Tak nevim. Prijde mi to divny. Mam dost naslapany PC a dost se to vlece. Je ale pravda, ze na tom LVM jsou v podstate jen BD filmy, takze soubory od 4-30G, ale to by snad nemel byt problem...
setkal jsem se s enormnim zpomalenim pri kritickem zaplneni disku. (tj. pod 10%) ext3 byl temer nepouzitelny reiser ale take vyrazne zpomalil.
nemuze to byt timto?
No to by mohlo byt ono. Mam z 3.5T volnych asi 300-200G jen
Uz jsem si toho vsiml, kdyz mi dochazelo misto minule, pak jsem dokoupil 2T a o dost se to zrychlilo. Uz cekam na nove 2T disky od WD. Tak uvidime.
Díky za super články! Konečně jsem se dnes (na základě těhle článků) odhodlal překopat svůj domácí server na LVM a musím říct, že je to super
.
Ahoj, jake jsou moznosti obnovy dat pri surovem cteni disku sector po sectoru? Obnovit smazany soubor obecne unix filesystemy moc neumoznuji.
Tedy jde mi o situaci: clovek ktery nezalohuje - {disk s LVM} - fs ext3 - si neco smaze a chce obnovit data primo z disku.
U FAT32 a NTFS pokud hned prestane s tim diskem pracovat, tak se pres ruzne nastroje ty data daji obnovit.
Už pod prvním dílem v diskuzi proběhlo, jestli je vhodné mít v jedné VG více disků - protože při poruše jednoho disku z VG ztratíme veškerá data v této VG.
Při vytváření LV je možné specifikovat konkrétní disk, resp. PV, pomocí posledního parametru lvcreate. To jsem vyzkoušel na VG ze dvou disků a skutečně to tak funguje. Zároveň by LVM metadata měla být na všech discích (PV). Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Nenašel jsem ale možnost, jak vypsat podrobné informace o LV, kde by bylo vidět, na kterých PV její bloky leží - to je první dotaz.
Ptám se hlavně proto, že pvmove, je možné použít jen v rámci jedné VG (už proto, že názvy zařízení jsou /dev/mapper/VG-LV). Pokud bych tedy kvůli bezpečnosti dat chtěl mít pro každý disk zvláštní VG, přijdu o možnost přesunu oddílu mezi disky. Bude ale možné alespoň přidat nový disk do VG a přesunout data na něj?
jak vypsat podrobné informace o LV, kde by bylo vidět, na kterých PV její bloky leží
lvdisplay --maps
Pokud bych tedy kvůli bezpečnosti dat chtěl mít pro každý disk zvláštní VG
Proč, když píšete:
Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Díky, to jsem neznal.
Proč, když píšete:
Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Pravda, nenapsal jsem to úplně logicky. To bylo takové zamyšlení na základě diskuze pod prvním dílem článku:
musim upozornit, ze neni prilis vhodne davat vice disku do jedne VG, nebot pri rozbiti nektereho disku, jsou necitelna i data na ostatnich discich danne VG.
V diskusi se potom snad došlo k tomu, že to není pravda, ale chtěl jsem se ujistit. Myslím, že se v seriálu zatím nezmínila možnost volby PV u příkazu lvcreate, která s tím souvisí.
Už pod prvním dílem v diskuzi proběhlo, jestli je vhodné mít v jedné VG více disků - protože při poruše jednoho disku z VG ztratíme veškerá data v této VG.
Nevím k čemu se dospělo, ale rozhodně to není pravda. Když vám odejde PV, tak před inicializací VG zavoláte vgreduce --removemissing. Pochopitelně přijdete o ty LV, které byť částečně ležely na ztracených PV, ale zbytek dál normálně funguje.
Tiskni
Sdílej: