Do prodeje jde tichá bezdrátová herní myš Logitech PRO X2 SUPERSTRIKE s analogovými spínači s haptickou odezvou (HITS, Haptic Inductive Trigger System). Cena je 4 459 Kč.
Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
Jak je vidět, když nahradím oba disky většími, kapacita poolu se zvýší. Umí tohle váš volume manager?
Proč by neměl umět? Třeba LVM v Linuxu to sice nedělá jedním krokem (je třeba vgextend na pridani noveho disku do VG, pvmove na presun dat ze stareho, a vgreduce na odstraneni stareho disku z VG), ale samozrejme to umi. To je prece zakladni vlastnost kazdeho volume manageru.
Ted se ale divam, ze LVM umi i pvresize, pokud se zmeni velikost diskove oblasti za behu (napriklad ze oblast sama je na nejakem HW diskovem poli).
-Yenya, http://www.fi.muni.cz/~kas/blog/
Ovsem k tomu, abyste toho mohl vyuzit, potrebujete aby i filesystem podporoval growfs. To nastesti vetsina filesystemu dneska uz umi, ale na zfs se mi libi, ze to vubec nemusim delat. ZFS zacne misto pridane do poolu pouzivat automaticky s tim, jak pribyva dat na filesystemu.
Osobne bych (na rozdil od autora clanku) pri popisu ZFS volume manager vubec nezminoval, protoze jakekoliv srovnani dost kulha. ZFS je zkratka filesystem, ktery je navrzen tak, aby mohl ukladat data na vice disku zaroven a umel pri tom zajistit pozadovanou redundanci dat.
V cem neni odladeny tak jako ext3 (a podpurne technologie jako LVM ci swraid)? Napriklad v tom, ze nemusim mit zahadne poruseni ext3 na lvm, i kdyz je dany desktop vypinan pouze ciste, a cekat mnoho minut na to, az dobehne fsck?
Stalo by za to jeste zminit, jak vypada bootovani ze ZFS rootu a jaky dopad to ma na syntaxi zaznamu v GRUBu. Dalsi podle me nesamozrejma vec, ktera by urcite stala za par slov je vzhled zaznamu ve fstab + jestli nastroje na praci s disky, ktere ocekavaji devicefile jsou schopne pracovat i se ZFS, nebo potrebuji prepsat.
Kdyz uz byla rec o vnitrnostech, stalo by za to naznacit moznosti ladeni a prochazeni datovymi strukturami ZFS - mnozstvi urovni abstrakce, slozitost datovych struktur, vnitrni komprese, pocet dereferenci, ktere vedou od cesty+jmena souboru k obsahu souboru.
Jako predposledni vec bych rad videl pametovou narocnost a rychlost ZFS na kancelarskem desktopu/notebooku/netbooku - tedy tam, kde je nejpravdepodobnejsi, ze nekdo bude OpenSolaris zkouset nainstalovat. Treba uz nekdo zkusil zmerit rychlost bootu, rychlost kopirovani/mazani hromady malych souboru a tak?
Mam pocit, ze zbavit se problemu s volume managery coby duvod vzniku ZFS je eufemismus pro funkcni neuplnost LVM a licencni poplatky za Veritas Volume Manager.
Nakonec bych poprosil o min eskamotersky/meganadseny ton clanku, takhle to vyzniva spis jako pokus o propasovani PR clanku o vyvojove verzi komercniho UNIXu do webu zamereneho na Linux. Kazda technologie ma svoje vyhody i nevyhody - at komercni, tak svobodna a prehnane nadseni muze s sebou nest jednostrannost...
Tak jak tak ale dekuju za odborny technologicky clanek (byt z hlediska Linuxu offtopic)!
1) To je hodne subjektivni - moje kriterium pro offtopic je "nemuzu si to plnohodnotne nainstalovat k sobe na pocitac s Linuxem".
2) Kachna i husa maji zobak a kridla, nejsou to slepice a presto jsou to ptaci. Tohle neni argument, sorry. 
Zkusim byt konkretnejsi (byt Linuxocentricky):
PR clanek:
ucelem je propagovat znacku/produkt, nikoliv podat objektivni a ucelene informace, typicky popisuje jen klady a aporum setaktne vyhyba, pokud nekdo poukazuje na neobjektivnost, je ostrakizovan zastupci znacky
vyvojova verze:
existuje jina verze, ktera se bezne nasazuje v produkci, zatimco tahle verze je prozatim na hrani - casem se z tehle verze stane neco, co se bude nasazovat v produkci
komercni UNIX:
puvodne uzavrene jadro i userland, casem cast userlandu nahrazovana GNU nastroji, ale prednost je stale davana zpetne kompatibilite pred jednoduchosti a modernosti, vyvoj, architekturu a zasadni rozhodnuti ridi jedina firma, ktera ma z daneho UNIXu zisky, firma se snazi vymezovat produkt oproti Linuxu jako neco pokrocilejsiho (Linux na hrani a do male firmy, UNIX do datacentra) a snazi se, aby technologie v produktu zustaly a nebyly re-implementovany v Linuxu, kde by firma ztratila kontrolu nad vyvojem
3) Cetls Art of UNIX programming? Monolit neni UNIXovy - UNIXova cesta je spousta malych jednoucelovych a opakovatelne pouzitelnych komponent - KISS. Usnadnuje to ladeni, udrzbu, modernizaci (nahradit komponentu je snazsi), kombinaci s produkty tretich stran (tohle je pro komercni technologii vetsinou nezadouci), umoznuje to snadne prispivani do projektu nezavislymi vyvojari (snadne pochopeni kodu). Diskuse niz presne tohle ukazuje...
4) Tak proc na tenhle bod reagujes, kdyz nemas odpoved?
5) To neni odpoved, jen mlzeni - totez, co bod 4)
6) Totez co bod 4)
Uz se k tvym reakcim nebudu vracet, protoze me flames fakt nezajimaji. Muj komentar smeroval na autora clanku, ne na bojovnika za svatou pravdu...
ad 3) To, co píšete, obecně skutečně platí. Je ale otázkou, kde je nejlepší místo pro to, kde vést dělící čáru mezi jednotlivými komponentami. Mám pocit, že rozdělovat zrovna volume manager a filesystem není dobrý nápad z následujících důvodů:
a) Ukazuje se, že při tomto rozdělení je třeba, aby se podobné úkoly dělaly dvakrát. Jednou ve volume manageru a jednou ve filesystému. Např. pro zajištění rychlé resynchronizace mirroru se používá DRL (dirty region logging). Ten se musí někam ukládat, stejně jako konfigurace volume manageru - typicky někam na mirrorovaný disk. Takže už Vám na disku vzniká ne zcela jednoduchá struktura. Navíc musíte řešit její updatování tak, aby bylo pokud možno atomické (odolné proti tomu, když Vám server spadne právě při změně konfigurace volume manageru), správně verzované (aby se nepoužila zastaralá konfigurace např. z odpojené poloviny mirroru). Přitom podobné problémy řešíte ještě jednou v rámci filesystému.
b) Pokud chcete mít možnost odebírat z volume manageru disky, musíte být schopen filesystému nějak sdělit, která data má odmigrovat a kam. V takovém případě ztratíte jednoduchost rozhraní + filesystém musí rozumět tomu, že prostor pod ním tvoří jednotlivé disky. Tedy dostal jste se k integrovanému řešení.
c) V případě, že filesytem neví o tom, že běží nad více disky, nemáte ani možnost optimalizovat výkon použitím více různých druhů disků pro různé struktury filesystému.
Např. Oracle taky spíše doporučuje používat ASM (automatic storage management), který má přehled o fyzických discích, než umístit všechny datové soubory na jeden volume volume manageru. (Uvědomuju si, že tady jsem hodně zjednodušil a že plánovat storage pro databáze je fakt věda.)
Dovolím si přirovnání z oblasti dopravy: Kdysi se používaly autobusy, které se skládaly z tažného autobusu a vlečňáku, připojeného pomocí dobře definovaného rozhraní (oje) k tažnému autobusu. Jednalo se o jednoduché, řešení a komponenta vlečňáku byla snadno nahraditelná např. traktorem. A přesto dnes všichni považují integrované řešení (autobus s kloubem) za výrazně lepší a výhodnější
Myslím, že podobný osud čeká i oddělený volume manager.
Diky za odezvu, zkusim odpovedet.
Testy pametove narocnosti a vykonu se delaji pomerne spatne, protoze OpenSolaris neumi fungovat na jinem fs nez ZFS, a tradicniho Solarisu by to sice slo, ale slo by spis o porovnani OpenSolarisu a Solarisu. Porovnani s Linuxem je spis porovnani celeho systemu nez porovnani fs. Dobre zpracovane porovnani souborovych systemu najdete tady: http://bulk.fefe.de/lk2006/ (a u poznamek autora se pravdepodobne pobavite), ale sam na to nemam hardware ani prostredky, a testovanim jen na nejake platforme se toho clovek moc nedozvi.
Na podrobnosti o vnitrnostech bohuzel nezbylo misto.
Pokud jde o nadseny ton, o dva clanky zpatky mi bylo vycitano ze se moc opiram do Sunu, a ted tohle. Bojim se, ze se nezavdecim vsem ;)
Dik za rozumny pristup!
Ad odkaz: dik, to je hodne zajimavej benchmark!
Ad nadsenej ton: slo mi spis o to, aby se pohromade objevily pro i proti - anebo byl clanek oznacenej jako reklama. Vsem se urcite neda zavdecit, ale napr. par linku na dalsi informace by urcite neskodilo...
No, pravdou je, ze nevhody ZFS moc nevidim. Ta vlastnost ze nemuzu odebrat zarizeni z raid 0 je neuveritelne otravna, a muzete se snadno dostat do stavu kdy vas ceka uz jen tar, zpool destroy, zpool create, untar, ale pokud na to myslite tak se s tim da zit. Nepritomnost uzivatelskych kvot je dana strukturou -- ta cast fs ktera alokuje misto na data a tedy se stara o to jestli jeste jde zapisovat je hodne hluboko pod posixovou vrstvou a nema o nejakych uzivatelich ani potuchy. Navic, kombinace snapshotu a kvot je mala nocni mura, protoze bud se snapshoty do kvot nepocitaji, a pak ta kvota moc nemuze, nebo se pocitaji a uzivatel ji muze zabrat tim ze meni jeden svuj maly soubor, a najednou nema misto (coz je nemile zvlast kdyz jsou snapshoty nastavene adminem a uzivatel s tim nic neudela). Taky delat klasicky quotacheck na nekolika terabajtovem fs nen moc dobry napad. A ZFS sice moc nefunguje pod linuxem, ale podpora ve FreeBSD a MacOSu ho dela kompatibilnejsi nez kdejaky dalsi souborovy system.
S benchmarky je to obecne nepekne. Aby takovy benchmark vyhovel vetsine uzivatelu, musel by se zabyvat jak malymi SSD pro mininotebooky (a resit jak se fs chova kdyz je skoro plny, jak se chova na SSD a jak se chova kdyz misto dojde uplne), tak desktopovymi disky, tak pro servery resit jak se FS + volume manager (neni-li zabudovany jako do ZFS a brtfs) chovaji na raidu 1, raidu 10, raidu 5, a jak velky vliv ma cachovani, nebo jak se na nem chovaji databaze. Krom toho je problem s testovacimi nastroji, protoze spousta benchmarku je optimalizovana pro jedenu platformu, a muzete se snadno dostat do situace kdyz delate ekvivalent testotvani vykonu souboroveho serveru bez pouzivani sendfile() nebo ekvivalentu, coz je k nicemu, protoze spousta serverovych aplikaci ma specialni optimalizace pro ten ktery operacni system.
Tohle vsechno sezere velke mnozstvi casu (treba desitky hodin) a je tedy otazka kdo to zaplati. Redakcim casopisu se za par grafu asi nebude chtit platit nejake velke castky, a pokud benchmark plati nejaka firma, je otazka jak z toho profituje a jestli nechce nejak priohnout vysledky. Mozna tak akademicka sfera a udelat si z toho bakalarku nebo diplomku (za kterou sice penize nejsou, ale clovek ji musi udelat tak jako tak), ale spousta lidi uz ma po skole, a i kdyby ne tak spousta oponentu a komisi se na zaverecne prace typu reserse diva skrz prsty protoze "prece nevytvari nic noveho".
tak je mozne pouzivat v ZFS aj raw device podobne ako pri swape na ZFS,.
co sa tyka clustrov a volume managerov v solarise, tak to vie aj SVM, aj ZFS. Je pravda ze Veritas ma svoje vyhody, mno myslim, ze tie pri porovnani zo ZFS padaju (aj ked vo veritase je mozno povedat na ktorych fyzickych diskoch v groupe sa bude volume nachadzat , co tusim ZFS nevie ).
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz