Vlákno názorů k článku Btrfs v praktických ukázkách od Honza - Trochu mi není jasné, jak je to s...
-
Honza (neregistrovaný)
Trochu mi není jasné, jak je to s tou kompresí. Nemělo by to být naopak? Pochopil jsem to tak, že pokud SSD s automatickou kompresí naplním třeba textovými soubory (uvažujme kompresní poměr 1:10), disk sice fyzicky zapíše jen desetinu dat, ale bude se tvářit jako plný, zatímco při použití btrfs se zapnutou kompresí budou tato data zkomprimována jednou filesystémem na desetinu prostoru a poté ještě jednou samotným diskem, na kterém bude obsazeno 10% místa.
Pak mi ale nedává smysl ten poslední odstavec, který tvrdí opak. Jak to tedy doopravdy je?
-
Lael Ophir (neregistrovaný)
Ono je to asi napsané trochu nešťastně. Mějme
1. 250GB SSD disk bez HW komprese,
2. 250GB SSD disk s HW kompresí,
a na něm
A. 250GB FS bez komprese,
B. 250GB FS s kompresí.Ve všech případech na FS zapíšeme 250GB textů. Pro jednoduchost předpokládáme kompresi na 10% původní velikosti a zanedbáváme velikost struktur FS.
1A - FS zaplníte
1B - zaplníte na FS jen 25GB, takže máte 225GB volného místa
2A - disk zdánlivě zaplníte, ale SSD bude mít interně jen 10% bloků obsazených, což mu pomáhá prodloužit životnost
2B - zaplníte na FS jen 25GB, zbyde 225GB volného místa, ale HW komprese na SSD disku bude neúčinná, a životnost disku tedy nijak neprodlouží.BTW na NTFS je komprese dostupná minimálně od NT 3.51, což je cca 20 let. Souboru stačí nastavit flag (v UI, na command line nebo v kódu), a NTFS jeho bloky transparentně zkomprimuje. Když tak označíte adresář, příznak dědí všechny nově zakládané soubory. Samozřejmě to má i mouchy: pokud komprimujete již existující soubory, zvyšujete tím fragmentaci FS. Podobně to může zvyšovat fragmentaci při modifikaci souborů. A samozřejmě to sežere kus CPU, i když ne až tak moc.
A víte, že NTFS umí podobným způsobem mimo jiné transparentní šifrování, tuším od NT 4.0? Na Linuxu by to chtělo jeden dobře napsaný a na features bohatý FS. Ne jeden rok extX, další rok rfs, pak btrfs... Navrhnout s rozmyslem a vizí budoucnosti kvalitní FS, dobře ho napsat (včetně nástrojů a dokumentace), důkladně otestovat, a pak podle potřeby rozšiřovat. -
Lael Ophir (neregistrovaný)
Máte nějakou konkrétnější informaci o té údajně přehnané fragmentaci u NTFS? Nikdy jsem se s takovým problémem nesetkal, přesto že se soubory pracuji velmi intenzivně. Alokátor NTFS mi přijde dobře odladěný. Pochopitelně při kompresi existujících souborů musí dojít ke zvýšení fragmentace; u btrfs ale vidím jen možnost komprimovat při ukládání (a ještě jen pokud je zapnuto CoW), a nikoliv dodatečně.
Fragmentace existuje u každého běžně použitelného FS, a zvyšuje se se zaplněním disku. Možnost defragmentovat na pozadí je proto důležitá. Na Unixech se tradičně defragmentovalo zálohováním na pásku, vytvořením čistého FS a následným restorem. Online defrag API od MS mi přijde výrazně lepší. Nakonec proto se časem online defrag - byť s velikým čsovým odstupem - naučily i xfs a btrfs.
-
tomo_tn (neregistrovaný)
Otierat si hubu o fragmentaciu/ defragmentaciu xfs je dost mimo. Xfs mal nastroj na defragmentaciu na pozadi uz na Irixe 6.5.x (xfs_fsr) a na rozdiel od MS defragu sledoval zmeny na FS a reagoval na ne. Ak vznikol v dobe zavedenia FS (1994) tak to bolo o rok pred win95.
Viac rozlicnych FS je fajn - aspon pre ludi co sa stretli z viac druhmi pocitacov.
NTFS niej zly ale istotne by som ho vyznamne nevyzdvihoval - hlavne nie na linux like strankach.
-
Lael Ophir (neregistrovaný)
Co máte na mysli tou reakcí na změny FS? Defrag ve Windows XP na změny FS samozřejmě reaguje. NTFS bylo uvedené v roce 1993 s Windows NT 3.1, a kompresi má od roku 1995 (NT 3.51). XFS bylo uvedeno v roce 1993; rok přidání komprese nevím, ale zato vím, že linuxová verze je vykuchaná.
Pokud se bavíme o technických otázkách a nikoliv idologii, je NTFS ukázkou, jak se má psát FS. Jde o dobře navržený FS, který MS neuváděl bez tools :), má spoustu features a vynikající zpětnou kompatibilitu. Nějak mi uniká výhoda toho mít jeden FS bez komprese, další bez žurnálu, jiný bez komprese i žurnálu, a další co umí šifrování nebo online defrag. Není lepší koncentrovat úsilí a napsat jeden FS opravdu dobře?
-
student (neregistrovaný)
Myslim si, ze nie je mozne napisat univerzalny FS naozaj dobre. NTFS je pomerne schopny FS, ale napriklad k flashovym diskom sa nechova az tak dobre ako YAFFS.
Na jednoduchsie zariadenia sa zase viac hodi FAT - prinajhorsom si staci na zaciatok disku napisat "nejake data" (oznacit subor cez celu particiu) a ostatne si moze vyrobca zariadenia pouzivat ako 1 velky subor bez starosti o detaily.A este - co znamena "opravdu dobre"? Totiz, v mnohych pripadoch ide o vyber z alternativ, pricom niektore tvorcov ani nemusia napadnut. Napriklad mne sa pacia wandering logs z Reiser4 - plne zurnalovanie bez zbytocneho dvojiteho zapisu. Inym by sa pacila deduplikacia, dalsim checksumming, block suballocation, spatna kompatibilita, plna podpora snapshotov, rychlost pri lubovolnom nasadeni, podpora pre transakcie; potom su aj ludia, ktori sa nepozeraju na filesystem, ale na autora (ci ma poruchu osobnosti a zavrazdil manzelku) atd.
Tazko sa da vyhoviet tomuto vsetkemu - uz len preto, ze niektore vlastnosti idu proti sebe.
Celkovo ak tooly nie su v drvivej vacsine pripadov treba, tak nevidim vyznam v tom, ze by ich niekto robil.
-
Lael Ophir (neregistrovaný)
Některé věci opravdu jdou proti sobě. Například těžko mít FS s triviální implementací v půl kB kódu, který na druhé straně umí kompresi, žurnálování a online defrag :). Nicméně spoustu věcí lze udělat v jednom FS, a to bez újmy na kvalitě. Zpětnou kompatibilitu může mít jakýkoliv FS, pokud ho dobře navrhnete (v NTFS jsou všechno soubory, včetně MFT). Deduplikaci můžete implementovat jako filter driver nad FS. Transakce můžete realizovat na vyžádání: aplikace si vyžádá transakci, provede změny na jednom či více souborech, a pak provede commit. Je to beze ztráty výkonu pro ostatní aplikace. Kompresi a šifrování můžete dělat přes flag, stejně jako třeba suid-bit (naatavíte flag, na pozadí se komprese a/nebo šifrování). Atd, atd.
Když myslíte při designu na budoucí features a rozšiřitelnost, lze toho udělat spoustu (byť samozřejmě ne všechno). Jenže takový návrh chce zkušenosti, chce nějaké úsilí, a opravdu není možné vývoj začínat psaním kódu :). A pochopitelně taková práce chce tým, nikoliv sólistu, byť sebelepšího.
-
prudic (neregistrovaný)
U vsech pocitacu s windows jsem zacal mit problemy s defragmentaci zhruba pul roku od instalace. Mluvim o windows 98, XP a Vista. 7 mam teprve mesic, takze nemuzu porovnavat. U visty mi hodne vadi ta defragmentace na pozadi, protoze uplne odrovna vykon notebooku. Zato u linuxu s ext3 nebo ext4 jsem na problemy s defragmentaci nikdy nenarazil a to mi obvykle vydrzi podstatne dele.
Napr. ted mam nainstalovane windows xp + visualstudio a par dalsich veci na 30GB oddilu. Nikdy na disku nebylo vic nez 12GB dat. System jsem nainstaloval a od te doby uz na nem jenom pracuju. A presto po trech mesicich uz je vic nez polovina souboru fragmentovanych. To mi jako dobry alokator rozhodne nepripada, kdyz mel vzdy k dispozici vic nez polovinu disku a stejne si neporadi.
-
Lael Ophir (neregistrovaný)
Windows používají FS celkem indenzivně, na rozdíl od Linuxu. Například MSIE má v Temporary Internet Files jednotlivé soubory, kdežto Firefox má jeden velký soubor, se kterým si hraje uvnitř. Windows pořizují zálohy stavu stroje pomocí System Restore, a při instalaci Service Packu se přebuší skoro všechny binárky systému.
Samotný počet fragmentovaných souborů nehraje až takovou roli. Například soubory System Restore a backupy po instalaci Service Packů jsou komprimované, a tedy fragmentované. Jejich fragmentace ale ničemu nevadí, protože je nejspíš nikdy nepoužijete (a pokud ano, tak bude jejich fragmentace tím nejmenším problémem, který v tu chvíli máte). Navíc pokud je soubor fragmentovaný po částech větších než cca 64MB, jeho defragmentace stojí spoustu I/O, a výsledek operace na výkon FS je nulový.Defrag na pozadí mi práci na poči nikdy (na Vistě a výše) znatelně nezpomaloval, tedy na desktopu. U notebooku výrazně doporučuji SSD disk, v případě finanční nouze vysokootáčkový HDD. Určitě nikdy neberte 1.8" HDD - jsou to ultra-pomalé shity, a z čekání na systém vám vypadají vlasy. A samozřejmě čím více RAM, tím méně diskových operací, takže 8GB RAM je pro pracovní notebook minimum.
-
prudic (neregistrovaný)
Ja si nehodlam kupovat rychlejsi pocitac jenom kvuli tomu aby mi tam sel OS. V te ukazkove konfiguraci jsem mel system restore vypnute, swap vypnuty, backupy mazu (krome toho jsem instaloval z media s SP3) a MSIE nepouzivam. A na stejnem pocitaci mam linux, takze jasne vidim, ze propad vykonu neni nulovy.
-
Lael Ophir (neregistrovaný)
Samotný OS problém s pomalými disky samozřejmě nemá. Problém nastává, když k disku intenzivně přistupují aplikace, nebo když se swapuje.
Propad výkonu není nulový při čem? Při defragmentaci na pozadí? To asi těžko srovnávat, když na Linuxu defrag na pozadí nejspíš nemáte.
-
Lael Ophir (neregistrovaný)
Nepotřebuje defragmentaci? Fakt? A proč minimálně ext4, xfs, rfs a btrfs tu defragmentaci nabízejí? Protože je to zbytečné?
Optimalizaci ukládání můžete dělat jak chcete, ale fragmentaci se stejně nevyhnete. A za jistých okolností prostě začně mít vliv na výkon. Starší linuxové FS vycházely z tradičních unixových FS, které se defragmentovaly stylem backup-mkfs-restore; proto neuměly defrag.
-
Sten (neregistrovaný)
U ext4 a xfs protože za určitých, poměrně výjimečných okolností (90+% disku zaplněno) k větší fragmentaci může dojít. Ale fragmentaci takovou, jakou jsem viděl ve Windows (70 % souborů fragmentovaných na disku používajících 10 % místa), jsem zatím v Linuxu s výjimkou logovacích souborových systémů, kde je to jaksi by design, neviděl.
btrfs fragmentuje kvůli COW o dost více a proto má autodefrag.
-
Trident (neregistrovaný)
NTFS je celkem schopny system od te doby co ma zurnal. Rozhodne bych ho nesrovnaval s klasickymi unixovymi UFS chudaky.
A hlavne na SAN je mi fragmentace celkem volna. Naopak je neprijemne pokud nejake outsourcovane opici poleno z HP pusti defragmentaci, protoze se domniva ze jde o lokalni systemovy disk. Pak se onen thin provisioned lun na sance pekne nafoukne na plnou velikost.
I kdyz oni windowsy tahle diskova reseni nemaji vubec rady. Odpadnou nektere SANkove disky a jedine na co clovek cuci je kurzor.Kdyz uz nemam schopny fs, tak mam schopny volume manager ktery mi muze delat thin provisioning, replikaci,deduplikaci,snapshoty,kompresi,redundanci etc... Pokud mam vetsi mnozstvi takto hloupych fs jez by bylo vhodne konsolidovat(neplati to vzdy), tak si poridim sanku s hromadou licenci ktera mi tyto ficurky dela taky.
BTW:ZFS um celkem vetsinu veci co potrebuju a je produkcne odzkouseny. No jeste neumeji prelejvat data ve stripu a odpojeni disku pokud je v nem misto.
...a nebo mam pomateneho designera co kombinuje vsechny tri prvky.
-
Trident (neregistrovaný)
Proc je implementace komprese na FS spatna? Mame tu aplikace ktere komprese vylozene nakopla. Virtualne zrychlila IO operace. Databazisti nam sysadminum libaji nohy a prinaseji obeti k podzemnimu bunkru jen diky nahozeni jednoho parametru.
CPU jsou vykonna a porad cekaji na IO. Tak proc nevyuzit jejich vykonu ke zvyseni propustnosti? -
Sten (neregistrovaný)
Zrovna u databáze je komprese dost problematická, protože na datech s náhodnými zápisy už z principu funguje nejhůře a strašně fragmentuje (změněná data najednou mohou být delší než původní); naštěstí btrfs je celkem inteligentní a databáze většinou odhalí a nekomprimuje.
Jinak souhlasím, že třeba pro /usr je to skvělá věc, protože většinu času stejně CPU nic nedělá a jenom čeká na disk a kompresí se celý systém i výrazně zrychlí.
-
Trident (neregistrovaný)
To si optimalizuje databaze a posleze filesystem. Oboje jsou na sebe certifikovane a presne nastaveni typu komprese je i v best practises. Databaze samozrejme umi i kompresi vlastni. Musim se na to databazistu pozeptat jake maji zkusenosti.
Kompresi nejlepe vyuzijeme v pripade kdy k diskum je z nejakeho duvodu omezene vlakno.
Jedna se o neprilis velke databaze v radu stovek GB az desitek TB.Databaze ve kterych se data toci rychle jsou stejne inmemory (dneska neni problem 1-2TB RAM) s lokalnimi ssd disky. Nejvetsi problem je s replikaci, protoze to proste pro danou aplikaci bezne hiendove zelezo nestiha.
Ale to uz neni muj problem. -
student (neregistrovaný)
Kompresia ma viac much - vlastne sa divim, ze ju niekto pouziva. Vela miesta beru typicky uz aj tak (stratovo) skomprimovane videa a obrazky, co sa uz nenarocnou bezstratovou kompresiou nevylepsi.
Ak je to naviac tak, ze sa nemozu pouzit blok / cluster viackrat (tj. bez niecoho ako je tail-packing), tak si velmi nepomozem, kedze male textove subory budu stale zaberat minimalnu alokacnu jednotku. To si mam kvoli 100MB rozumne komprimovatelnych suborov spustat kompresiu a spomalit tak vsetko? Alebo nebodaj rucne hladat taketo subory a naklikavat, ze ich chcem komprimovat?
BTW mna uz davno presvedcil "oblubeny" drvspace.bin, ktory sa mi vzdy "nasackoval" do low memory a potom som nemohol tak lahko spustat setup z CD. A ako bonus nemoznost citania takejto diskety tam, kde to zlo nebolo (zvlast, ked to tam niekedy zatrhol nejaky zaciatocnik a potom sa divil, co je ten jeden jeho subor na diskete).
-
phejl (neregistrovaný)
>Vela miesta beru typicky uz aj tak (stratovo) >skomprimovane videa a obrazky, co sa uz nenarocnou >bezstratovou kompresiou nevylepsi.
Ano ale pokud nepouzijete compress-force tak ty se compressovat nebudou. Jinak receno FS zjisti ze compression ratio je prilis maly a vzda to.>Ak je to naviac tak, ze sa nemozu pouzit blok / cluster >viackrat (tj. bez niecoho ako je tail-packing), tak si >velmi nepomozem, kedze male textove subory budu stale >zaberat minimalnu alokacnu jednotku.
Jenze btrfs provadi packing maly souboru do 3916 bytu v ramci metadat. S tim ze vbudoucnu je mozne dodelat i tail-packing.Na posledni cast asi nema cenu reagovat. Btrfs funguje uplne jinak. Spousta lidi si mysli, ze (jako kdysi v dosu) se musi celej disk komprimovat a kdyz to chci vypnout tak zas dekomprimovat. Uvedomte si ze vse probiha na urovni FS, ne nad nim. Takze klidne muzu FS pripojit s kompresi a pak bez ni. Vysledek je ten, ze bloky zapsane behem pripojeni s kompresi budou komprimovane. Nic vic, nic min.
-
Lael Ophir (neregistrovaný)
Pokud zkusíte komprimovat videa nebo obrázky, prostě nezískáte žádné místo navíc, a bude vás to stát trochu času CPU. Žádná velká katastrofa. Naopak pokud máte na disku třeba velkou hromadu logů nebo dokumentů, komprese se velmi hodí. Praktické použití? Na file serveru dochází místo, a disky dorazí až za pár dní. V notebooku máte na pevno SSD o malé kapacitě, a potřebujete tam nacpat spoustu dokumentů.
-
phejl (neregistrovaný)
Ani toho CPU casu navim moc nebude, pokude nezapnete compress-force jak jsem psal vyse.
Navic na pomalych plotnovych discich a s nekolika jadry cpu (ktere se dost casto stejne flakaji) komprese vyrazne zrychli cteni. Je rychlejsi precist a dekomprimovat 200MB nez precist z plotny 1G.
-
student (neregistrovaný)
Ja mam na logy logrotate, ktory komprimuje len ked je to treba a len subory, ktore su treba - zaroven ich vymiena a aj premazava stare, takze sa mi neoplati zbavit sa ho vymenou za featuru filesystemu.
Dokumenty (ODF a aj OOXML) maju kompresiu aj same a AFAIK sa taky zip neda dost dobre komprimovat. Okrem toho si neviem predstavit, ako by bolo mozne napisat behom normalneho zivota aj len jeden GB takychto dokumentov.
Plnit tak necakane a rychlo fileserver nedokazem, ale mozno je to len moj zvyk na notifikacie a sledovanie grafov, co pomoze odhalit podobne problemy dopredu.
-
phejl (neregistrovaný)
Asi zalezi na pouziti.
Me se rozhodne komprese vyplati na nekolika desitkach GB chekoutnutych repository. A zaroven se zrychli kompilace.
Stejne tak se podle meho nazoru vyplati komprese na root (resp. usr) - malo zapisu spousta cteni.
Nastesti si kazdy muzeme vybrat jaky FS povazujeme za vhodny.
-
Lael Ophir (neregistrovaný)
Dost mě zajímá, proč nemáte na linuxových FS implementovanou tu kompresi volitelně přes nějaký flag na souboru. Jak jsem psal, ve Windows nastavíte souboru nebo adresáři kompresní atribut (obdobně jako suid na Unixech), a je hotovo. Když to nastavíte na adresář, dědí to všechny nově založené soubory. Vaše závěrečné konstatování by na Windows znělo "nastesti si kazdy muzeme nastavit kompresi na ty adresáře/soubory, kde to uznáme za vhodné".
-
Trident (neregistrovaný)
Jak nemam widle rad, tak ti musim dat za pravdu. Tohle maji widle zmaknuty mnohem lip.
Linuxaci jsou posledni dobou uplne mimo realitu. Operacni system na kterem jsem zacinal doposud nema zadny poradny filesystem. Zatim jsem pouzival jen XFS,KillWifeFS a nakonec jsem zase skoncil u zalaminovane zombie ext4 s ruzovou masli. To je hanba. Na unix based systemu kde je prace se s adresarovou strukturou zaklad. Kde je vsechno soubor. Ba i soubor je soubor:)
Jedna se porad jen o tu jednu a tu samou oplacavanou zombii.btrfs je silne admin unfriendly a na produkci bych ho nepustil. Co to je za kravinu nastavovat to jako mount parametr? Kolikateho ze je?
-
Lael Ophir (neregistrovaný)
Bohužel to funguje jen pro nově zapisovaná data, komprimované soubory zpátky dekomprimovat, neexistuje interface pro zjištění komprimované velikosti, neumí s tím pracovat file managery, nenašel jsem popis API po nastavení komprese (chattr je utilita a nikoliv API)... Takže je to rozhodně krok správným směrem, akorát skoro o dvě dekády opožděný, a zatím dost malý.
https://btrfs.wiki.kernel.org/index.php/Compression#Can_I_force_compression_on_a_file_without_using_the_compress_mount_option.3FBTW proč to autorům btrfs trvá tak dlouho? Za šest let dali dohromady FS, který je pořád považovaný za experimentální, a dlouhá řada věcí je nehotová.
-
> nenašel jsem popis API po nastavení komprese (chattr je utilita a nikoliv API)...
No že's to nenašel asi nebude chyba Btrfs...
A co's vlastně hledal? Jestli očekáváš, že jako na Windows bude na každou ptákovinu zvlášť funkce, tak to's ani najít nemohl :) Nastavuje se to stejně jako ostatní atributy.
Tady třeba nastavení nocow:
http://www.spinics.net/lists/linux-btrfs/msg09605.html -
...jinak seznam ioctls je tam, kde má být:
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
-
Lael Ophir (neregistrovaný)
No právě že ne. V dokumentaci ext4 je EXT4_FS_IOC_SETFLAGS, který je *dnes* synonymem pro FS_IOC_SETFLAGS. Zítra to tak být nemusí. Ext4 navíc transparentní kompresi neumí. Dokumentaci FS_IOC_SETFLAGS jsem opět nenašel, jenom hlavičkový soubor (což není dokumentace). Při pohledu na Linux si člověk o to víc váží MSDN.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364592(v=vs.85).aspx -
> V dokumentaci ext4 je EXT4_FS_IOC_SETFLAGS, který je *dnes* synonymem pro FS_IOC_SETFLAGS. Zítra to tak být nemusí.
Co je nebo není synonymem čeho vás vůbec nemusí trápit. Stejně jako vás nemusí trápit, že v dnešním kernelu tohle makro má hodnotu 10 a v zítřejším třeba 12, to je vám jako programátorovi šuma fuk.
> Ext4 navíc transparentní kompresi neumí.
Zkusím ještě jednou, třeba to pomůže: je to atribut a nastavuje se stejně jako jiné atributy. Líp už to fakt vysvětlit neumím. Pokud nechápete, nechte to koňovi.
> Při pohledu na Linux si člověk o to víc váží MSDN.
To vám nikdo nebere, važte si, čeho chcete. Já si zas vážím třeba tohodle:
http://lxr.free-electrons.com/ident?i=FS_IOC_SETFLAGSUkažte mi zdroják, jak je to vaše Windowsí API implementováno a pak se budeme bavit o tom, kdo má o jakém OS lepší informace :)
-
Ale když už jsme dostali do takového družného hovoru, můžete mi prosím v tom výborném MSDN najít, co mám jako administrátor dělat, když v logu najdu hlášku "Pokus o Není známo se nezdařil"? Nebo když se mi zobrazí hláška "Nastavení tiskárny nelze uložit. Operace se nezdařila" a v logu není nic? Nebo "Z důvodu neznámého problému nemůže systém Windows zobrazit nastavení brány firewall systému Windows" a v logu opět nic?
https://plus.google.com/109540561880466469418/posts/8rPHaTwuHmL
Nebo mi prosím najděte v dokumentaci, proč Windows zobrazují *warning*, že nejsou schopny nainstalovat aktualizaci něčeho, protože to není nainstalováno.
https://plus.google.com/109540561880466469418/posts/K6B5TwAxiZk
Prosím, najděte mi, kde jsou tyhle featury v MSDN zdokumentovány, ty mě totiž reálně pálí, zdokumentovanost API *experimentálního* fs alfa kvality je mi fakt putna...
-
A proč to chcete vědět? Chcete začít programovat pro unixové systémy? V tom případě můžu doporučit kvalitní literaturu, např:
Stevens, W.R.: Advanced Programming in the UNIX Environment
Raymond, E.S.: The Art of UNIX Programming
Kerrisk, M.: The Linux Programming Interface: A Linux and UNIX System Programming Handbook
Kusick,M.: The Design and Implementation of the FreeBSD Operating SystemSchválně jsem vybral ty, co se dají koupit na Amazonu.
No a pak i něco málo v češtině:
Linux: Dokumentační projekt, http://www.root.cz/knihy/linux-dokumentacni-projekt/stahnout/859/
Mathew, Stones a kol.: Linux Programujeme profesionálněNo a samozřejmě z důvodu přenositelnosti určitě standard POSIX, popř. Single UNIX Specification (tady ale trochu pozor na Linux).
Jestli v těch knihách narazíte na nějaký problém, je tu fórum, kde vám zkušenější rádi s konkrétním problémem poradí.
Uvidíte, že vás to bude bavit. A časem zjistíte, že často lepší než různé tutoriály, je kouknout se, jak tu kterou věc skutečně implementovali zkušenější programátoři - takže pokud máte nějakou obzvláštní zálibu v problematice nastavování atributů, doporučuju otevřít si zdroják chattr.c, tam je to jako na dlani.
-
Jo a abych nezapomněl - jako uživatel Windows možná nevíte, že narozdíl od Windows mají unixové systémy kvalitní dokumentaci v každé instalaci a člověk ani nepotřebuje ke čtení browser. Prochází se tak, že do terminálu napíšete "man <co mě zajímá>".
Pro začátek teda "man man".
Tady ale bohužel Linux trochu zaostává, u derivátů BSD najdete v manu víc a bývá to trochu systematičtěji zpracováno. Projekt GNU nevím proč razí vlastní dokumentační systém info (do terminálu "info info").
-
Lael Ophir (neregistrovaný)
Ve Windows xyz /? vypisuje většinou totéž, co verze v lokálním helpu. V některých případech je toho v helpu samozřejmě víc, například u robocopy.
Je ale smutným faktem, že v MS produktech postupně mizí nápověda typu obsáhlého popisu každé volby v dialogu, a narůstá objem článků typu "jak nastavím bezpečné brouzdání pro své děti". Koncovým uživatelům to možná dělá radost, ale mě moc ne.
-
Lael Ophir (neregistrovaný)
Zdroják není dokumentace, to jsem nakonec psal o pár příspěvků dál.
Ano, POSIX samozřejmě funguje, ale bohužel spoustu věcí nepopisuje. Nehledě na to, že glic není POSIX compliant.
Knížky jsou zajímavý nápad, ale víc bych ocenil kvalitní dokumentaci.
Psaní SW pro unixy je právě vzhledem k odlišnostem jednotlivých systémů celkem náročné, zvlášť pokud chcete napsat něco jiného než POSIXovou command line utilitu v C. Jsem sice dobrodružná povaha, ale adrenalin vyhledávám jinými způsoby :)
-
> Knížky jsou zajímavý nápad, ale víc bych ocenil kvalitní dokumentaci.
Ale ta dokumentace je, chápete to? Pokud mátě nějaký problém s tištěným textem, můžete se dokonce podívat na grafické zobrazení linuxových kternelových volání. Jistě si to googlem najdete sám.
> Psaní SW pro unixy je právě vzhledem k odlišnostem jednotlivých systémů celkem náročné, zvlášť pokud chcete napsat něco jiného než POSIXovou command line utilitu v C.
Ale no ták. Drtivá většina softu, který běží na Linuxu, běží i na FreeBSD nebo na macu. A jsou to i takové molochy jako Gnome, KDE apod. Takže tohle je opravdu střelba to prázdna...
Jinak samozřejmě celá tahle argumentace je demagogie jako prase, protože když něco (čistě) naprogramuju pro FreeBSD, tak to s malými až žádnými úpravami spustím na Macu, Solarisu nebo Linuxu. Zatímco když něco naprogramuju pro Windows, tak to spustím kde? Jenom na Windows. Aha. No tak to je výhra a unixy jsou špatné!
-
Lael Ophir (neregistrovaný)
Já jsem - coby náročný člověk - očekával nějaký portál, kde bych našel dokumentaci typu MSDN, nebo Apple Developer. Klidně s odkazy na další zdroje, jako je dokumentace Qt a GTK. Chápu, že každá projekt dělá někdo jiný. Ale hlavně by to chtělo místo, kde se dokumentace shromažďuje, aby vývojář nemusel lítat po celém webu, dohadovat se, zkoušet a po různu luštit zdrojáky. No a vy mi místo toho nabízíte knížky, které jsou sice pěkné, ale problém moc neřeší.
Když napíšete POSIXovou command line utilitu čistým způsobem pro jeden unixový systém, nejspíš půjde i na jiných systémech. Když pánové v Adobe psali Adobe Flash (což je hloupý plugin do browseru), byly nutné změny i ve zdrojáku gcc, a vývojáři řešili řadu problémů s podporou multimédií v různých distrech (takhle to bylo psáno tady na rootu). A že by jim díky tomu Flash běžel automaticky na FreeBSD nebo Solarisu, o tom si mohou nechat zdát.
Co napíšete pro Windows, spoustíte na Windows, což je obrovská spousta počítačů. Nakonec čí je chyba, že původně celkem jednotný UNIX došel značné fragmentace? Za to, přátelé unixáci, Microsoft nemůže. -
> Já jsem - coby náročný člověk - očekával nějaký portál, kde bych našel dokumentaci typu MSDN, nebo Apple Developer. Klidně s odkazy na další zdroje, jako je dokumentace Qt a GTK.
Vsak si jako narocny clovek taky koupite Windows nebo MacOS X a budete spokojeny. Nechapu duvod, proc o tom diskutovat. Ja taky nechodim na stranky fanouska Amiga OS vykladat jim, proc Amiga OS nepouzivam.
Tim nasi diskusi koncim, protoze zjevne mate svuj nazor, o kterem se me snazite presvedcit bez toho, abyste poslouchal, co vam rikam. Jelikoz ja nemam zadny duvod menit vas nazor, nevidim duvod pokracovat.
Snazil jsem se jenom uvest na pravou miru alespon nektere nepravdy, ktere tady sirite, aby si nahodou nejaky nahodny ctenar nemyslel, ze to je pravda.
P.S. skoda, ze jste pri tom "hledani" nezkusil aspon zadat do Googlu "linux kernel api documentation" a kliknout na prvni odkaz :) No, co uz, placat nesmysly je vetsi zabava, chapu :)
Howgh.
-
Lael Ophir (neregistrovaný)
Zatím jsem vyplodil jediný nesmysl, tedy že Linux nemá API pro změnu IP adresy. A vy jste mě zase například přesvědčoval, že mám kouknout do zdrojáku ifconfigu, což vede ke zvěrstvu používání nepodporovaného interfacu. Nakonec to zachránil někdo jiný, kdo to podporované API byl (na rozdíl od vás) schopný najít.
Myslím že beze mě jako vývojáře se unix-like systémy bez problémů obejdou :). Ale jak čekáte že budou vývojáři psát pro Linux, když nemají k dispozici kvalitní dokumentaci a podporovaná API pro spoustu akcí? Když k tomu přičtete malé rozšíření Linuxu mimo webové servery, jde pro vývojáře o extrémně neatraktivní platformu. Samozřejmě jednoduší než problém alespoň pojmenovat je bušit hlavou o stůl s křikem "ale nám to nevadí, nevadí, nevadí!" ;)
-
Lael Ophir (neregistrovaný)
LOL, to je super vtip. .... Počkejte, vy to myslíte vážně? Místo jednoduchého volání spouštět utilitu? Ne, to nemůžete myslet vážně.
libe2p jsem nenašel, ale ve zdrojáku ext2 byly vidět použité ioctls. Bohužel jsem nenašel žádnou dokumentaci, jenom zdroják. to je jednak velmi nepohodlné, a pak ten zdroják může zítra vypadat úplně jinak: jiná čísla ioctls, používající jiné parametry... Tohle je ve srovnání s Windows bažina.
-
> Počkejte, vy to myslíte vážně? Místo jednoduchého volání spouštět utilitu? Ne, to nemůžete myslet vážně.
No v drtive vetsine pripadu se tohle bude volat ze skriptu, takze API fakt neni potreba. A pokud nekdo bude tohle chtit delat z c-ckovyho zdrojaku, tak asi bude o linuxu neco vedet a nebude na to cumet jak tele na novy vrata jako vy...
> a pak ten zdroják může zítra vypadat úplně jinak: jiná čísla ioctls, používající jiné parametry...
Jasne. A taky zitra muze na Zemi spadnout meteorit a nejaka ioctl nas nebudou vubec trapit.
To je asi tak stejna logika jako zajimat se o to, jaka cisla jsou za konstantami. Ta cisla se NIKDY nepouzivaji primo. Vzdycky se pouzivaji konstanty. A zmena tech konstant by znamenala zmenu API, cos se dela jenom v pripade, ze fakt neni zbyti. (no i kdyz... u linuxu... no radsi nic :)
> Tohle je ve srovnání s Windows bažina.
Bavime se tady o EXPERIMENTALNIM kodu. Je v MSDN popsano API Windowsu, ktere prijdou po osmickach?
Jinak dneska na me opet vybafla zajimava hlaska: "Pokus o Napájení vypnuto [nazev_stroje] se nezdařil." Zadne dalsi info. Muzete mi prosim v MSDN vyhledat, kde je tohle zdokumentovano? A potom mi to jeste prosim prelozte do nejakeho lidskeho jazyka, tohle totiz neni ani anglictina, ani cestina...
-
Lael Ophir (neregistrovaný)
Když autoři to API nezdokumentují, tak ho aplikace opravdu nebudou používat :)
Když použijete konstantu, a ta na různých verzích systému bude mít různé hodnoty, tak vám to moc nepomůže.
Takže knihovny e2fsprogs jsou také experimentální?
Jak je podle vás vůbec definovaná platforma? U systémů typu Windows tvoří platformu to, co je jasně popsané. Takový interface programátor smí použít, protože je podporovaný autory, a v příštích verzích se nebude měnit (a snad pokud taková nutnost nastane, bude to v dokumentaci). Na mě to působí, že podle vás je platforma jaksi souhrnem zdrojáků ze včerejšího večera, dokumentace vlastně není třeba, a kdo pro platformu chce něco napsat, tak ať si s tím poradí jak chce.
To je zřejmě hláška "The attempt to {0} PC failed", kde {0} je "power off". Správný překlad by asi byl "Pokud o uvedení stroje do stavu {0} selhal". Aplikace nejspíš zavolala API InitiateSystemShutdown nebo InitiateSystemShutdownEx, a to z nějakého důvodu nezafungovalo (permissions, zamknutá user session a není vynuceno odhlášení uživatele "násilím" apod). API vrací non-zero pokud bylo volání úspěšné, zero pokud selhalo. Více detailů o chybě získáte následným voláním funkce GetLastError(). Je samozřejmě na volající aplikaci, kolik detailů o chybě vám dá. Pokud bylo něco zapsáno do logu, tak nejspíš v logu toho vypínaného stroje. V lokálním logu jen pokud tam aplikace něco zapíše.
http://msdn.microsoft.com/en-us/library/aa376873(v=VS.85).aspx -
> To je zřejmě hláška "The attempt to {0} PC failed", kde {0} je "power off".
Jistě. A pochopitelně je to hláška z lokálního logu a pochopitelně žádné další informace v něm nebyly. Proto to píšu.
Uživatel se zřejmě snažil stroj vypnout, což se nezdařilo a Windows se neobtěžovaly do logu napsat pořádně, PROČ se to nezdařilo. Jen zaznamenaly, ŽE se to stalo.
Ladit to nemůžu, protože se to stalo jednou a neumím tu situaci reprodukovat, protože se jaks Windows neobtěžovaly mi říct žádné detaily. Čili uživatel nejspíš stroj vypnul natvrdo, možná došlo k nějaké ztrátě dat a já jako správce s tím nemůžu udělat vůbec nic... Je sice super, že mám k dispozici krásné omalovánky, kde je zdokumentované API, ale v jiných oblastech chudák správce zoufale tápe ve tmě a nemůže dělat VŮBEC NIC.
-
Jistě, například viz tento screenshot, který jsem už odkazoval:
https://lh5.googleusercontent.com/-VUsHRQrJPqI/UPgVj60G1LI/AAAAAAAAAvg/M-sm4uAhEMA/s452/Win_ulet.png
Můžu si kliknout na link, kde získám víc informací, a můžu debugovat na základě 4 nulových bytů. S chutí do toho :)
-
Lael Ophir (neregistrovaný)
A tam fakt skončíte se složenýma rukama? To si říkáte admin? :)
Co když byla zobrazena hláška o nutnosti ukončit aplikace, a uživatel stisk Cancel?
http://support.microsoft.com/kb/2627489Pokud jsou to WinXP, co UPHClean?
http://blogs.technet.com/b/uphclean/archive/2008/02/28/hi.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=6676Koukal jste na diagnostiku pomocí powercfg? Možná je tam zařízení, které brání vypnutí systému.
http://technet.microsoft.com/en-us/library/cc748940(v=ws.10).aspxV tom EventVieweru je vtipně pouze výsledek operace, ale už ne výsledek GetLastError. Pokud se taková situace opakuje, zkoušel jste zapnout logivání user32, jak je popsáno v MS KB Q221833?
-
Jasně. Prostě kvůli jedné hlášce v logu budu zkoušet tisíc věcí, protože se mi systém vůbec neuráčil dát relevantní informace, abych se aspoň něčeho mohl chytnout. A po hodinách zkoumání zjistím, že jenom uživatel zmáčkl Esc. Bezvadný. A takových hlášek mám denně deset. Čili nebudu dělat nic jinýho, než řešit kokotiny Windows...
...ovšem útěchou mi je, že mám v MSDN bezvadně zdokumentované kernelové API :) Tak to jo :))
-
Lael Ophir (neregistrovaný)
Já to zkoumal cca 10 minut. Vy umíte lépe s vi i skriptovat bashi, a navíc brouzdáte ze skvělého Firefoxu místo MSIE, takže to určitě dáte za polovic :D
To není o dokumentaci jedné nebo dvou věcí, ale o dokumentaci celé platformy. A samotná dokumentace je jen jednou z věcí, které Linux brzdí.
Pro vaši informaci MSDN popisuje kernelové API jen v kontextu vývoje driverů. Windows totiž mají architekturu. Kernel interně používá Native API, které aplikace přímo nevolají. Nad kernelem jsou pak subsystémy, například Win32, OS/2 a POSIX. Ty poskytují API pro aplikace. Trochu škoda, že se Linus před začátkem vývoje OS nestudoval trochu architektury OS, snad s výjimkou starých UNIXů. Možná by i na tak mizerném vývojovém modelu, jakým je open source, mohl vzniknout perspektivní a inovativní OS.
http://upload.wikimedia.org/wikipedia/commons/5/5d/Windows_2000_architecture.svg -
> Trochu škoda, že se Linus před začátkem vývoje OS nestudoval trochu architektury OS [...] Možná by i na tak mizerném vývojovém modelu, jakým je open source, mohl vzniknout perspektivní a inovativní OS.
Jako třeba Hurd? :)))
Linus monolitický kernel zvolil schválně, nebylo to z neznalosti. Chtěl vytvořit kernel, který bude funkční a použitelný co nejdřív, aby měli lidi k dispozici kompletní opensource OS. A přesně tohodle vytřeného cíle se mu podařilo dosáhnout, vědomě za cenu ne-ideálního ne-nejestetičtějšího kernelu.
From a theoretical (and aesthetical) standpoint linux looses.
If the GNU kernel had been ready last spring, I'd not have bothered to
even start my project: the fact is that it wasn't and still isn't. Linux
wins heavily on points of being available now.
https://groups.google.com/forum/?fromgroups=#!topic/comp.os.minix/wlhw16QWltIhttp://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
Když toho o něčem moc nevíte, tak o tom nepište. Anebo se aspoň pod to podepište. Šířit anonymní pomluvy je bolševická manýra.
-
Lael Ophir (neregistrovaný)
Pokud si pamatuji, tak Linus psal původně terminálový emulátor, a pak mu došlo, že je to vlastně skoro jako kernel. Prostě profi návrh architektury, kvalitní kódování... :D Nakonec koukněte na ten druhý link.
http://en.wikipedia.org/wiki/History_of_Linux#The_creation_of_Linux
http://groups.google.co.uk/group/comp.os.minix/browse_thread/thread/76536d1fb451ac60/b813d52cbc5a044bProblémy zavlečené tímhle "návrhem architektury" se s Linuxem táhly dekády (třeba absence threadingu), a některé přetrvávají dodnes. Třeba Big Kernel Lock teprve před pár měsíci rozbili na subsystem locky. Třeba stihnou tuhle část "návrhu" napravit už před pětadvacátým výročím :)
-
Lael Ophir (neregistrovaný)
Windows i Linux jsou event-driven systémy, takže opravdu tickless ani nebudou nikdy. Různé délky časového kvanta používají Windows tuším od Win2003/XP. Od Win7 se používá timer coalescing a CPU core parking. U Win8 je timer coalescing agresivnější, takže se idle time výrazně protahuje.
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2642.Idle_2D00_duration_2D00_histogram_5F00_2514617C.png
http://blogs.technet.com/b/askperf/archive/2009/10/03/windows-7-windows-server-2008-r2-core-parking-intelligent-timer-tick-timer-coalescing.aspx -
No pokud si pamatuju já, tak Gates zase prodal něco, co neměl a pak to horečnatě sháněl. Podařilo se mu koupit Quick&Dirty OS, jehož dědictví si jako smrad ssebou Windows táhnou až do dneška a který mimochodem může za to, že české Windows používají dvoje kódování, při kooperaci s rádobykonsolí a rádobyshellem, co mají, dost často vypisují blbě češtinu. A to prosím v roce 2013, kdy už je UTF i v hodinkách s androidem.
Takže být váma, historii bych radši do svého trollingu nezatahoval.
A znovu opakuju: pokud chcete pomlouvat a lhát, mějte aspoň tolik odvahy, abyste to dělal pod vlastním jménem. Anonymně pomlouvat je bolševická manýra.
-
Lael Ophir (neregistrovaný)
1. To nemá s Windows NT vůbec nic společného. Mohl jste si všimnout, že WinNT mají čistý návrh. A to ve srovnání s Windows 9x, klasickými UNIXy i OS/2, o Linuxu ani nemluvě.
2. Navíc si to pamatujete špatně. Tim Paterson ze Seattle Computer Products spolupracoval s Microsoftem již před tím, než vůbec začal psát svůj QDOS. SCP prodávali svůj HW s Microsoft BASICem. Takže Gates a Allen nesháněli. Naopak měli dohodnutý kontrakt, nejspíš smlouvu o smlouvě budoucí. Bylo to asi rychlejší a/nebo levnější, než si ty cca 4000 řádek v ASM napsat in-house :)
http://en.wikipedia.org/wiki/Timeline_of_DOS_operating_systems
3. Windows NT používají interně odjakživa jedno kódování, a to Unicode/UTF-16. Samozřejmě kompatibilita s DOSem, Windows 3.x a Win9x znamená nutnost podporovat další kódové stránky. Co je to ovšem proti Linuxu, který se učil i 8859-2 dlouhá léta, kernel i spousta utilit dodnes umí jen chary bez kontextu, funkce glibc vyřešily (ne)podporu UTF-8 předěláním dokumentace, a aplikace dodnes používají jiná kódování znaků než kernel (typicky UTF-16 nebo UTF-32 vs chary bez kontextu)?Co je konkrétně pomlouvačného na tom co jsem napsal? Vždyť jsou to fakta. Linus opravdu psal terminál tak dlouho až došel k proto-kernelu, a o úrovni návrhu Linuxu, stejně jako schopností autora v oblasti designu OS, si můžete udělat sám představu z druhého linku který jsem přikládal. Žádné pomluvy, jen fakta - byť se vám třeba nemusí líbit.
Ohledně své osoby odpovídám vždy stejně: diskutujme o technice a nikoliv o osobě toho druhého. Pokud vás zajímá moje jméno, Lael Ophir myslím říká vše potřebné. -
Lael Ophir (neregistrovaný)
Ať žije rekurze :)
http://www.root.cz/clanky/btrfs-v-praktickych-ukazkach/nazory/450148/ -
j (neregistrovaný)
Kdyby slo jen o desktopy ... mam tu par widlich serveru, furt to ma logy plny ruznych warnigu a nekdy i errory ... a jediny co se dovim, ze se "blizsi informace dovim na MSDN" ... kde je samo ze "zadne blizsi informace k tomuto problemu" ... proste lol.
Takze vim, ze je (asi) neco spatne, ale vubec netusim co a proc ... => nezbyva mi nez cekat, az se to cosi projevi i nejak jinak nez jen hlaskou v logu (trebas tim, ze se serve za chodu slozi ... ale to se stejen dovim kulovy proc).
-
Lael Ophir (neregistrovaný)
A zkoušel jste se někdy podívat do logu nějakého unixového stroje? I na vašem linuxovém desktopu nejspíš dostanete pár kB hlášek, včetně varování a chyb, při běhu běžné GUI aplikace.
Mohl jste si také všimnout, že ty hlášky v Event Logu mají popsaný zdroj a event ID, a event má nějaký text a data. Pokud tomu ani přesto nerozumíte, zkuste support.microsoft.com/search
Je také vtipné, že si tu jedni unixáci stěžují na nedostatek logování, a druzí říkají "obtěžuje mě to, stejně tomu nerozumím" :)
-
Sten (neregistrovaný)
Je unixovým zvykem, že když něco nevím, tak použiju kód, který to umí. Je vyzkoušené, že to funguje, a změnit se to dá vždycky.
libe2p je součást e2fsprogs, což vám řekne libovolný výsledek z první strany po zadání jejího jména do Googlu. Ty ioctl, které jste viděl, jsou velmi pravděpodobně skryté právě uvnitř libe2p.
ioctl se nemění, protože by se tím rozbila zpětná kompatibilita. Nikdo vám ale nezaručí, že stejná čísla ioctl budou fungovat třeba na Macu (a zrovna u té komprese nebudou).
-
Lael Ophir (neregistrovaný)
To není o vědění nebo nevědění. Jde o dokumentaci interface, která prostě chybí. Podobně na Linuxu není API pro změnu IP adresy, založení uživatele, management swapu atd. Pochopitelně to všechno můžete nějak obejít. Například u změny IP adresy můžete strávit čas pitváním zdrojáku ifconfigu, doufat že to funguje na všech distrech, že to bude fungovat i v dalších verzích, a zoufat že vám ten samý kód nefunguje na FreeBSD, Macu, AIXu, HP-UXu a Solarisu. Ve Windows v podobné situaci použijete IP Helper API, dokumentované, včetně tutorialu a komentovaného příkladu. Přitom by to šlo i na Linuxu. Stačí jasně definovat interface a napsat dokumentaci.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366073(v=vs.85).aspx -
> Podobně na Linuxu není API pro změnu IP adresy
Vy máte asi fakt problém pochopit, že ioctl volání JSOU API. Takhle se to prostě v unixech dělá, takhle se s unixovým kernelem komunikuje, zkuste se s tím nějak smířit anebo to nechte koňovi, ale nešiřte nesmysly.
http://www.lainoox.com/set-ip-address-c-linux/
> založení uživatele, management swapu atd
Na založení uživatele nemůže být (kernelové) API, protože s tím prostě nemá kernel vůbec nic společného. Na vyšších vrstvách samozřejmě API existuje - podle toho, jaký backend je použit.
No a management swapu, na to jsou primárně utility. Tyhle věci se prostě na unixech dělají pomocí skriptů. I kdyby céčkové API nebylo zdokumentováno VŮBEC, tak by to NIKOHO netrápilo, protože je prostě NIKDO nepotřebuje. A pokud by nějaký úleťák z těžko pochopitelného důvodu potřeboval takovou věc nastavovat z céčkového programu, tak by se prostě podíval do zdrojáků jádra nebo té patřičné utility.
TAKHLE TO PROSTĚ JE, v unixech se extenzivně používá skriptování. U windowsů je situace zase opačná - na všechno je tuna kernelových API a chybí utility. Což je situace HORŠÍ, protože "skriptové API" se dá použít z libovolného jazyka, nebo ručně z shellu, zatímco céčkové API je jenom pro céčko. Pak na Windowsech dochází k takovým absurditám, jako že kernel něco umí, ale uživatel to nemůže udělat, protože neexistuje utilita, která by to API zprostředkovala uživateli. Takže člověk musí po všech čertech shánět nějaké pochybné PowerTools apod., aby tu vlastnost vůbec mohl využít.
Myslím si, že není pravda, že linuxové/unixové kernelové API je špatně zdokumentované. Ale i kdyby to pravda byla, je to dost podobné jako vyčítat windowsům, že narozdíl od Macu nemají zdokumentované objective-C API... Protože ho nemají vůbec. A chybí někomu? Nechybí. Na Windowsech se prostě používá místo objective-C C++ nebo C. A na Unixech se zase používá C a shell. Takové ty systémy jsou. Pokud se vám to nelíbí, tak je nepoužívejte, ale je úplně zbytečné tady brečet nad tím, že systém X dělá věci jinak než váš oblíbený systém Y.
-
Lael Ophir (neregistrovaný)
Utility jsou tu proto, aby umožnily adminovi provést akci z command line nebo ze skriptu. API existuje naopak proto, aby ho mohly použít interaktivní aplikace nebo služby. Na tom se zřejmě shodneme. Nexistuje technický ani praktický důvod, aby nebyla k dispozici dokumentovaná API pro ty samé akce, které poskytují utility. Jaký je důvod, aby změnu IP adresy, nastavení swapu, založení deamona, dotaz na jeho stav atd. dělal jenom admin interaktivně z command line? Vždyť to prakticky znemožňuje napsat slušnou aplikaci, která by takové věci dělala.
Opravdu podle vás neexistuje například potřeba zastavit službu z aplikace, nebo z aplikace zjistit její stav?
Ohledně ioctl si nerozumíme. Samozřejmě můžete něco dohledat ve zdrojácích, ale 1. je nskutečný opruz to hledat, 2. nejspíš to bude fungovat jen v daném systému, ale už ne na jiném unixu, 3. nemusí to fungovat ani v další verzi toho samého OS, protože to není dokumentovaný interface, a tedy se může kdykoliv změnit. Používat nedokumentovaný interface je bad practice a cesta do pekla, na tom se snad shodneme. U Qt nebo GTK také nebudete používat nedokumentované funkce, přesně z těchto důvodů.
Takže ano, IP adresu na Linuxu dnes můžete změnit pomocí ioctl SIOCSIFADDR. Na FreeBDS, HP-UX, Macu ani jiném unix-like systému to asi nepůjde, a na Linuxu se to zítra může řešit úplně jinak, na rozdíl třeba od funkcí libc, které jsou jasně popsané, a měnit se tedy nebudou. Navíc to nenajdete nikde zdokumentované, což pro vývojáře fakt není dobré. V tom je problém - nikoliv ve vlatním použití ioctl.
Jak k tomuhle průšvihu došlo? Díky fragmentaci unixů. Výrobci se sice nakonec po dlouhých bojích dohodli na POSIXu, ale ten spustu věcí nepopisuje, a od té doby unixy z hlediska standardizace prakticky usnuly. Už dávno mělo dojít k sepsání nějaké knihovny řekněme libsysmgmt, která by tyhle věci koncepčně řešila, byla k dispozici na všech unixech, a byla slušně dokumentovaná (alespoň tak jako libc, lépe řekněme jako Qt). Jak je pak taková knihovna na té které platformě interně implementovaná, to už je detail.API pro založení uživatele nemusí být na úrovni kernelu (nedává to ani moc smysl), ale nějaké by mělo exitovat. V libc, Qt ani GTK jsem takové API nenašel; z toho u libc si troufnu tvrdit, že neexituje.
To srovnání s Objective-C podle mě pohulhává na všechny tři nohy. Jak jsem psal, v Linuxu (a vůbec v unixech) prostě úplně chybí na řadu věcí dokumentované a podporované API, tedy způsob, jak danou věc může udělat aplikace. Výběr hlavního jazyka pro API systému s tím nemá nic splečného.
-
> Takže ano, IP adresu na Linuxu dnes můžete změnit pomocí ioctl SIOCSIFADDR. Na FreeBDS, HP-UX, Macu ani jiném unix-like systému to asi nepůjde, a na Linuxu se to zítra může řešit úplně jinak
Ok. Zatimco na Windows muzu IP adresu nastavit volanim funkce MicrosoftBestAPIForBestDeveloperEver__SET_IP_ADDRESS. Na FreeBDS, HP-UX, Macu ani na jakemkoli jiném systému nez jsou Windows to STOPROCENTNE nepůjde. A na Windows se to zitra muze resit uplne jinak, protoze se Microsoft rozhodne vsechny funkce MicrosoftBestAPIForBestDeveloperEver do Windows 9 nezaclenit.
A to je ten nebetycny rozdil!
-
Santiago (neregistrovaný)
> Na FreeBDS, HP-UX, Macu ani jiném unix-like systému to asi nepůjde
> Jak k tomuhle průšvihu došlo? Díky fragmentaci unixů.
To je ale zcela umely problem. Prirozeny pohled je ten, ze Linux je proste nezavisly operacni system. To ze ma s nekterymi jinymi (treba FreeBSD) spolecne ideove koreny a nejaka API (POSIX, SUS), nic dalsiho negarantuje, podstatna cast API co se tyce advanced featur uz je specificka pro Linux.
Takze portovat program z Linuxu na FreeBSD bude jednodussi nez na Windows, ale je naivni ocekavat, ze pouzivanim nejakeho univerzalniho API se vyhnu s tim spojenym problemum.
API na urovni Linuxu samozrejme funguji, v lepsim pripade jsou i dokumentovane (napr. zminovane nastaveni IP adresy je netlink message RTM_NEWADDR, viz man 7 rtnetlink).
API na urovni jadra moc neuznava rozdeleni na dokumentovana a nedokumentovana - kazde normalni jaderne API je povazovano za stabilni (konkretni hodnoty konstant sice mohou byt odlisne na ruznych architekturach, ale samotna jmena konstant ioctls jsou definovana v jadernych headerech a jsou povazovana za stabilni, ciselne hodnoty jsou stabilni v ramci jedne architektury do budoucna).
-
Lael Ophir (neregistrovaný)
Wow, rtnetlink a jeho RTM_NEWADDR, RTM_DELADDR, RTM_GETADDR. Děkuji za informaci. Samozřejmě by to chtěl nějakou hierarchicky uspořádanou dokumentaci, ale zjevně lepší man než nic. rtnetlink dokumentovaný, a tedy na rozdíl od SIOCSIFADDR určený k používání aplikacemi.
Problém s fragmentací unixů mi nepřipadá umělý. Když už autor investuje do psaní SW, je pro něj zásadní počet uživatelů, kteří jeho produkt budou moci použít. Nakonec proto vznikl POSIX/SUS. Bohužel se standardizovalo jen nezbytné minimum (kterého se Linux mimochodem tak úplně nedrží). Jak jsem už psal, není problém vytvořit dokumentované API pro všechno co nabízejí utility (syscalls a ioctls pro ty věci stejně každý systém musí mít), udělat API pro daemony a spoustu dalších věcí. Vývojářům by to usnadnilo psaní SW i jeho portování mezi různými unix-like systémy. A kdo je pro platformu důležitější než vývojáři? Snad jen uživatelé, ale jejich počet závisí právě na vývojářích.
-
Lael Ophir (neregistrovaný)
Vida. Já našel jen ioctl_list, a ten není autoritativní. Samozřejmě je pořád problém, že jde jen o Linux, a ne ostatní unixy. A pak je tu praktická nepoužitelnost dokumentace. To i glibc má lepší dokumentaci, přesto že spoustu věcí nepopisuje, málo toho vysvětluje a prakticky nic neukazuje. Jako lepší příklady vidím Qt, ještě lepší Apple Developer, a špičkou v oboru je MSDN.
-
Lael Ophir (neregistrovaný)
Úkolem MSDN není dokumentovat chybové hlášky aplikací. MSDN je zkratka pro Microsoft Developer Network.
Firewall: pokud opravdu používáte Windows Firewall a je zapnutý, troubleshooting najdete zde (včetně dvou důležitých linků na konci):
http://support.microsoft.com/kb/920074Obecné informace pro troubleshooting (jako admin byste tohle ale měl znát):
Ve Windows se provádí troubleshooting jinak, než na unixech. Na prvním místě musíte systém trochu znát, což je podobné jako na unixech. Doporučuji nějaké školení administrace Windows, a poté si přečíst Resource Kit (ukázková kapitola: http://download.microsoft.com/download/4/5/E/45E70ABC-C224-4CC7-BB1C-23AA33FDC685/Win7_RK_SampleChapter_29.pdf ). Je to pár tisíc stran, ale jsou tam důležité koncepty. Ve většině případů vystačíte s prostou úvahou o možné příčině problémů. Pak je tu samozřejmě Event Log. Pokud není popis události dost podrobný, vizte níže support.microsoft.com/search
HW kupujte ten, na který jsou slušné reference, a je podporovaný na cílovém OS. Je důležité, aby byl listovaný v Hardware Compatibility Listu. Co není listováno jako kompatibilní či lépe Designed For, neberte.
http://www.microsoft.com/windows/compatibility/windows-7/en-us/default.aspxV případě blue screen se vyplatí vědět, že na MSDN najdete seznam bug check codes, včetně popisu parametrů. Ve spustě případů se také vyplatí po rebootu zaslat data na OCA (online crash analysis). Jednak to mnohdy řekne užitečné věci, a pak to MS řekne, že se stal problém. Oni to pak vyhodnocují, a kopou do vlastních vývojářů i do vývojářů driverů třetích stran.
Popis detailů BSOD a seznam stop codes:
http://msdn.microsoft.com/en-us/library/ff547224.aspx
Případně si můžete vyhrát i s debuggerem, howto najdete tady:
http://blogs.technet.com/b/askcore/archive/2008/11/01/how-to-debug-kernel-mode-blue-screen-crashes-for-beginners.aspxVe Windows je i nástroj pro reportování chyb, který umí ověřit status chyby, případně si přes něj MS umí vyžádat detaily chyby (pokud dáte souhlas). Ve Sitě je ve Start Menu\Programs\Maintenance, Problem Reports and Solutions. Ve Windows 7 je v Action Center, sekce Maintenance. Mimo jiné Windows obsahují i měřák spolehlivosti systému, kde jsou přehledně vidět problémy. Viz Start Menu\Programs\Administrative Tools, Reliability and Performance Monitor.
V případě jakékoliv chyby je dobré použít adresu support.microsoft.com/search, a vyhledat hlášku. V případě blue screen chyby hledejte například "stop 0x00000079", bez uvozovek.
Numerickou chybu můžete přeložit do textové podoby pomocí utility err.exe, která je k dispozici zde (není to jen pro Exchange):
http://www.microsoft.com/en-us/download/details.aspx?id=985
Obecně je ale na aplikaci, aby vypsala smysluplnou hlášku, a nejlépe se z chyby zotavila. Například serverové aplikace i MS Office se dovedou vzpamatovat z low memory condition - na Linuxu nevídáno (protože OOM Killer).Windows mají auditování. Můžete nechat auditovat vybrané akce v dané větvi FS, provedené vybraným uživatelem. Například na profilu uživatele, autor uživatel, všechny selhavší pokusy o zápis do souboru. Výsledek najdete v Event Logu v sekci Auditing. Podobně můžete nechat auditovat Registry. Zajímá vás, kde program hledá informace o registraci? :) Když jsme u toho, strace je proti tomuhle dost nuda.
Ve spoustě případů pomůžou pěkné utility od Sysinternals. Doporučuji Process Monitor, FileMon, PageDefrag, TCPView.
http://technet.microsoft.com/en-us/sysinternals/bb545046.aspxProblémy s výkonem se typicky řeší pomocí Performance Monitoru. Máte možnost sesbírat stovky systémových parametrů do datového souboru (například working pool vybraných porocesů, délku diskové fronty, velikost volné RAM atd), a ten později analyzovat buď graficky, nebo ho exportovat do Excelu.
Různé komponenty lze nastavit tak, aby do něj zapisovaly více. No a máte možnost nechat vytvářet i textové trace logy, viz link. Upozorňuji, že zpravidla textové logy nejsou třeba. Nejprve zkuste ostatní věci, výsledek bývá daleko rychlejší.
http://support.microsoft.com/?id=109626
http://technet2.microsoft.com/WindowsServer/en/library/0907105e-7856-4c93-b97f-a9a306623af51033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/library/0eeec637-d8f2-49b2-9ef8-6db31c98ca9a1033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/library/0e797736-5a4a-403f-a3ab-ed634c486b911033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/library/8fe9f51a-ac45-4213-85c7-1bf5aaa5bd9b1033.mspx?mfr=true
http://support.microsoft.com/?id=907355
http://support.microsoft.com/?id=249621
http://support.microsoft.com/?id=324383
http://technet2.microsoft.com/WindowsServer/en/library/bfd1241c-fc7b-45ca-9fa8-17a579b8d31e1033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/library/02043c4e-8cec-4db1-9fec-caca07f917cc1033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/library/63695e21-058b-41e1-b94a-cf25a477f13a1033.mspx?mfr=true
http://support.microsoft.com/?id=262177
http://support.microsoft.com/kb/221833Seznam pár diskuzních fór a serverů s postupy, není moc aktualizovaný:
http://support.microsoft.com/search
http://forums.microsoft.com/technet/default.aspx?siteid=17
http://www.microsoft.com/cze/technet/komunita/newsgroups.mspx
http://www2.vyvojar.cz/Diskuzn%c3%adf%c3%b3ra/tabid/52/Default.aspx
http://blogs.msdn.com/vyvojari/
http://www.experts-exchange.com/ -
Lael Ophir (neregistrovaný)
Logrotate jaksi neřeší situaci, kdy potřebujete těch logů uchovávat fakt velké množství. Komprese na FS to naopak řeší velmi dobře. Všechny soubory máte pořád k dispozici, a zabírají výrazně méně místa.
Dokumenty nejsou jen ODF a OOXML. Je to také DOC, XLS, PPT, PDF, TXT, XML, EDIFACT a pár desítek dalších formátů.
-
Santiago (neregistrovaný)
Problem s transparentni kompresi je v tom, ze obcas je transparentni az moc - napr. pri kompirovani ci zalohovani a spouste podobnych cinnosti se hodi pracovat explicitne se zkomprimovanym souborem (je nesmysl ho transparentne dekomprimovat a nasledne nezmenen zas komprimovat), coz je u transparentni komprese tezko resitelne.
-
Lael Ophir (neregistrovaný)
Primárním cílem je uspořit místo na disku, takže to nevadí. Navíc přístup ke komprimovaným datům vám většinou moc nepomůže, protože se kvůli rychlosti seeku v souboru používá komprese po nezávislých blocích. Standardně kompresní utility komprimují celé soubory.
Nicméně získat přístup ke komprimovanému streamu přece není tak těžké. Vezměte si inspiraci ve Windows, kde se to používá pro šifrované soubory. Pokud má uživatel oprávnění SeBackupPrivilege (například je člen skupiny Backup Operators), může číst soubory zvláštním API, které čte přímo RAW stream. Při restoru se postupuje stejně, a pokud byla provedena i záloha klíče :), uživatel je pak schopen soubor dešifrovat. Není problém obdobně zavést nějaký CreateFileRaw, který vrátí přímo komprimovaný stream. Když cílový FS nepodporuje kompresi nebo šifrování, nebo soubor není komprimovaný/šifrovaný, operace prostě vrátí příslušnou chybu.
Podobně kopírování lze řešit přímo kopií RAW streamu, pokud je zdrojový i cílový FS stejného typu.
ČLÁNKY DO MAILU
