Patchouli je open source implementace EMR grafického tabletu (polohovací zařízení). Projekt je hostován na GitLabu.
Český Nejvyšší soud potvrdil, že česká právní úprava plošného uchování dat o elektronické komunikaci porušuje právo Evropské unie. Pravomocným rozsudkem zamítl dovolání ministerstva průmyslu a obchodu. To se teď musí omluvit novináři Českého rozhlasu Janu Cibulkovi za zásah do práv na ochranu soukromí a osobních údajů. Ve sporu jde o povinnost provozovatelů sítí uchovávat údaje, ze kterých lze odvodit, kdo, s kým a odkud komunikoval.
Google bude vydávat zdrojové kódy Androidu pouze dvakrát ročně. Ve 2. a 4. čtvrtletí.
Bezpečnostní specialista Graham Helton z Low Orbit Security si všímá podezřelých anomálií v BGP, zaznamenaných krátce před vstupem ozbrojených sil USA na území Venezuely, které tam během bleskové speciální vojenské operace úspěšně zatkly venezuelského diktátora Madura za narkoterorismus. BGP (Border Gateway Protocol) je 'dynamický směrovací protokol, který umožňuje routerům automaticky reagovat na změny topologie počítačové sítě' a je v bezpečnostních kruzích znám jako 'notoricky nezabezpečený'.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl 3,58 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 26,32 %. Procesor AMD používá 67,43 % hráčů na Linuxu.
V Las Vegas probíhá veletrh CES (Consumer Electronics Show, Wikipedie). Firmy představují své novinky. Například LEGO představilo systém LEGO SMART Play: chytré kostky SMART Brick, dlaždičky SMART Tagy a SMART minifigurky. Kostka SMART Brick dokáže rozpoznat přítomnost SMART Tagů a SMART minifigurek, které se nacházejí v její blízkosti. Ty kostku SMART Brick aktivují a určí, co má dělat.
Vládní CERT (GovCERT.CZ) upozorňuje (𝕏) na kritickou zranitelnost v jsPDF, CVE-2025-68428. Tato zranitelnost umožňuje neautentizovaným vzdáleným útočníkům číst libovolné soubory z lokálního souborového systému serveru při použití jsPDF v prostředí Node.js. Problém vzniká kvůli nedostatečné validaci vstupu u cest k souborům předávaných několika metodám jsPDF. Útočník může zneužít tuto chybu k exfiltraci citlivých
… více »V úterý 13. ledna 2025 se v pražské kanceláři SUSE v Karlíně uskuteční 5. Mobile Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj a související infrastrukturu. Akci pořádá David Heidelberg.
… více »Už je 14 dní zbývá do začátku osmého ročníku komunitního setkání nejen českých a slovenských správců sítí CSNOG 2026. Registrace na akci je stále otevřená, ale termín uzávěrky se blíží. I proto organizátoři doporučují, aby se zájemci přihlásili brzy, nejlépe ještě tento týden.
… více »Rok 2026 sotva začal, ale už v prvním týdnu se nashromáždilo nezvykle mnoho zajímavostí, událostí a zpráv. Jedno je ale jisté - už ve středu se koná Virtuální Bastlírna - online setkání techniků, bastlířů a ajťáků, kam rozhodně doražte, ideálně s mikrofonem a kamerou a zapojte se do diskuze o zajímavých technických tématech.
Dějí se i ne zcela šťastné věci – zdražování a nedostupnost RAM a SSD, nedostatek waferů, 3€ clo na každou položku z Číny … více »
16.10.2017 23:12
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
jak Milos Zeman.
17.10.2017 00:02
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
16.10.2017 23:39
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
sda1 -----------------------+
|
btrfs --- /boot
|
sdb1 -----------------------+
sda2 --- bcache --- LUKS ---+
| |
ssd btrfs --- /
| |
sdb2 --- bcache --- LUKS ---+
Disky jsou 2x 1TB + 32GB SSD cache, vše běžné lowend připojené do SATA (to ssd má dávat 400 read/150 write MB/sec, takže na dnešní poměry nic moc), bcache jede v módu writethrough. Pocitově a podle sluchu disky méně seekují a nabíhání aplikací je svižnější. Ale není to jako mít vše rovnou na ssd, to je jiná liga. Moje idea byla, že v cache budou hlavně často používané inody, tj. často spouštěné aplikace nebo milión ini souborů KDE - to to zhruba splňuje. Při pokusu s writeback disky méně chroupaly i při zápisech, ale jak jsem psal, raději bezpečnější mód. Teď mám taky volné M.2, tak by bylo zajímavé vyzkoušet. Cache device jde odebrat a zase přidat jiné, tak až se mi dostane do ruky nějaký M.2 SSD, budu zvědavý, jaký bude rozdíl.
19.10.2017 23:56
vandrovnik | skóre: 21
20.10.2017 08:11
Max | skóre: 72
| blog: Max_Devaine
Já jsem kdysi používal zásadně reiser4, protože reiser4 natrhl prdel nejen všem ostatním filesystémům, ale i reiseru 3.6 (nebo jak se ta začleněná verze tenkrát jmenovala). Ale pak jsem toho nechal, protože
Zkrátka a dobře, začátkem roku 2010 už byla údržba reiser4 neudržitelná a navzdory jeho rekordnímu výkonu jsem se na něj vybodnul a začal jsem místo něj používat Btrfs, který je prostě v kernelu.
Co koukam na diskuse kolem btrfs tak se skoro cítim vysmátej, že se mi to vyhlo ...
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Zatímco ti, kterým zásadní převrat v oblasti filesystémů (zahájený ZFS) unikl, dál v poklidu ztrácejí svá data, ať už potichu nebo hlučně, jejich konkurence s Btrfs se tomu směje od ucha k uchu a dělá si jen tak pro legraci atomické snapshoty. Takže asi tak.
Pro osobní použití mám na všech svých strojích Btrfs cca od roku 2010.
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Není náhodou nutné CoW u databází vypnout?
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
19.10.2017 18:29
Jendа | skóre: 78
| blog: Jenda
| JO70FB
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?Je horší v tom, že nechecksumuje data. A lepší v tom, že na rozdíl od btrfs „RAIDu“ funguje i v degradovaném režimu a neobsahuje podivné bugy.
Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.
Ještě jednou: Zničí všechna data kvůli poškození dat na jednom disku.
A: A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
B: Je horší v tom, že nechecksumuje data.…
C: …Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.Řeč byla stále o tom, v čem je lepší či horší RAID v LVM.
Není náhodou nutné CoW u databází vypnout?Doporučené to je, například dokud PostgreSQL nebude umět vhodně používat API, které se skrývá za
cp --reflink a podobnou funkcionalitou. Nutné to samozřejmě není, ale může to mít negativní vliv na výkon (v případě rotujících disků; v případě SSD to není až tolik podstatné).
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
Pozor na věc, v LVM žádný použitelný RAID není. Technologie typu dmraid i (starší) mdraid vytvářejí pseudo-RAID, který (stejně jako hardwarový pseudo-RAID) nechrání proti chybám dat na jednotlivých discích. Chyby můžou vzniknout nechtěným přepsáním části disku při údržbě systému, případně jako důsledek řady různých hardwarových a softwarových chyb.
Pokud je poškozená RAID1 replika u Btrfs, filesystém to zjistí, opraví to podle funkční repliky a nikdy nevrátí špatná data. U pseudo-RAIDu dojde k tomu, že se budou náhodně vracet nesmysly, jak se z toho RAID1 pole prokládaně čtou bloky. Jednou z jedné repliky, pak zase z jiné. Takže jakmile dojde k poškození dat, dokonce ani není zaručeno, že dvě čtení téhož souboru vrátí totéž.
RAID5 v LVM (nebo ve starém mdraidu nebo i hardwarový) je ještě horším rizikem. Dokáže se prý vyrovnat s úplným selháním jednoho disku. Ano, ale jedině za předpokladu, že ten disk přestane fungovat zcela náhle a nevrací už pak žádná data, natož neplatná. Jenže co když se na jednom disku poškodí data? Znám případ, kdy došlo k přepsání části jednoho disku nulami. Části, která neobsahovala RAID5 metadata, takže metadata tam zůstala a disk se dál tvářil jako součást RAID5 pole. A pak (bohužel) nastal resilvering, který kvůli poškození jednoho disku zničil všechna (všechna!!!) data na celém poli. Tohle by se s Btrfs nikdy nestalo, protože Btrfs má checksumy. Pozná, který blok vrací nesmysly, a ať už je ten blok pro daný stripe paritní nebo datový, problém dokáže opravit (nebo prohlásit za neopravitelný, je-li to jeden disk, RAID 0 a podobně). Nebude ale vracet náhodné smetí.
Samozřejmě to není dokonalé — jistě bude v Btrfs checksumech hashovací kolize, že ano. Ale Btrfs prostě pomáhá tím, že snižuje pravděpodobnost vrácení poškozených dat filesystémem o nějakých deset desítkových řádů nebo víc. Takže z jevu, který by se ve větším (PB až EB) datovém centru stával často (kdyby tam byl klasický FS), se najednou stane cosi prakticky nemožného (při dnešních technologiích a kapacitách disků).
(Ještě je pro zajímavost dobré dodat, že i na jednom rotujícím disku je Btrfs bezpečnější než jiné filesystémy, protože může mít (atomicky udržované) repliky metadat. Poškozená data jsou sice neopravitelná, ale poškozená metadata se (automaticky) obnovit dají, pokud je druhá replika v pořádku. Pokud jde o SSD, tam se v Btrfs repliky metadat nedoporučují a implicitně jsou vypnuté, protože SSD má zpravidla ve svém řadiči deduplikační algoritmus, takže replikované bloky metadat by beztak nikdy nesplnily svůj účel (redundance) a řadič SSD by musel dělat copy-on-write ošklivosti při pozdější změně těch metadat.)
19.10.2017 18:31
Jendа | skóre: 78
| blog: Jenda
| JO70FB
a s opravdovým RAIDemOpravdový RAID se pozná podle toho, že když vypadne disk, tak nejde přimountovat read-write? Nebo podle toho, že má ve status page napsáno write hole still exists, parity not checksummed?
Ale no tak. Že by krátká paměť? Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAID (a proč to, čemu se dosud říkalo RAID, ve skutečnosti nikdy nesplnilo své sliby kolem redundance). Vše jsem už pod některými tvými výkřiky vysvětloval možná i víckrát než pětkrát. Co takhle si to zkrátka dohledat a nepapouškovat pořád dokola zavádějící otázky a jiný FUD?
Pokud je o status page: Všiml sis doufám, (1) že varování se netýká RAIDu 1, 0 a jejich kombinací a (2) že status page nemusí být aktuální? Některé z oprav, o kterých ses (na status page i jinde) jistě také dočetl — jen jsi je nějak zapomněl zmínit —, už jsou nějakou dobu v kernelu.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj? Ne, to opravdu není RAID — to je AID be R. Btrfs přesně proti tomuhle chrání, zatímco zastaralý pseudo-RAID nikoliv (a resilveringem následně zničí všechna data — i to jsem vysvětloval několikrát).
Fakt je mi záhadou, proč se snažíš všude vtěsnat kousek FUDu proti Btrfs. Takhle v debatách fungují nejrůznější popírači IPv6, popírači systemd, popírači Btrfs, příznivci parních strojů nebo koňských povozů… Asi takhle: Pokrok v oblasti filesystémů tady bude, ať se ti to líbí nebo ne.
Ale no tak. Ty jsi někdy neuvěřitelně zaťatý. To, že checksumy jsou skvělá záležitost, nikdo nezpochybňuje. A to, že btrfs je schopno identifikovat porušené disky na základě chybné sumy před tím, než se disky jako celek tváří jako nefunkční, je také vynikající. Problém je v té následné funkcionalitě. Já jsem si RAIDem na btrfs zatím nehrál i když mám btrfs na mnoha discích. Nicméně, pokud btrfs se přepne do RO režimu a neumím ho přesvědčit, aby dále fungovalo normálně, je v tom něco špatně. Je to pro mne arogance vývojářů, kteří uživatele nutí do režimu, který nechtějí.
Je to trochu podobné, jako když jsme před pár lety vedli vážnivé debaty, že df pro určování volného místa na btrfs volumu nemá smysl. Tehdy jsem argumentoval, že kapacita toho disku je něco jako měřitelný prostor v matematice. Měřitelné množiny jsou mnohdy velmi divoké, v mnohadimenzinálních prostorech (i nekonečně dimenzionálních) a jde na nich zadefinovat míra. BTRFS volume je prostor o konečném množství prvků a zadefinovat smyslupnou míru by problém být neměl. Naštěstí se hodně zlepšili a v současnosti df dostačuje pro základní představu o volném místě. A pokud někdo chce a potřebuje detail tak btrfs filesystem detail odpoví. Tady už se arogance zbavili.
Druhý případ je arogance výrobců aut, kdy auto zastaví a nejede dál, protože mu někdo nevyměnil olej nebo podobnou blbost. Tady je to obdobné. Ano standardní funkcionalita na RAIDu s vypadlým diskem je extrémně riziková, na druhou stranu pokud uživatel potřebuje dočaasný čas přežít s tímto rizikem tak systém by mu to měl umožnit. Podobně jako to, když potřebuji s autem dojet, tak mi sice může nadávat a upozorňovat mne, ale musí jet. V extrémním případě může jít o život.
20.10.2017 12:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Dejme tomu, že mně ta funkcionalita chybí, ale v PHP ji určitě dopisovat nebudu a raději zvolím jiný filesystem.Tvoje volba.
20.10.2017 10:28
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAIDAno, například by se tam nemělo stávat, že v nejběžnější konfiguraci po výpadku jednoho disku přestane jít používat. Pak to totiž není Redundant a Independent, ale jenom AD. To není FUD, to je prostě fakt a každý si to může zkusit.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj?Vzhledem k tomu, že se mi na asi 80 TB*let tohle zatím ani jednou nestalo, zatímco btrfs se mi rozsypalo několikrát, považuji za lepší používat ten „nebezpečný“ RAID. Já výhody checksumování nerozporuji, ale prostě v současném stavu není btrfs vhodný na produkci. Doporučil bych ZFS, ale tam je zase problém že zpool nejde zmenšovat a vyhazovat z něj disky.
31.10.2017 16:02
Max | skóre: 72
| blog: Max_Devaine
.. treba Oracle ( puvodni autori ) , Facebook, Google , SUSE .. same malicke firmicky co nemaji dostatek lidi
Tiskni
Sdílej:
