Názory k článku
Preference vývojářů podle OS

Přechod na NT byl možný jen díky zpětné kompatibilitě. Prakticky veškeré stesky kritizovaly jen zpětnou kompatibilitu a HW náročnost NT.

MS už dnes doporučuje .NET jako primární vývojové prostředí. Ano, za pár let poběží Win32 aplikace v sandboxu (uživatel to zřejmě nepozná), a můžeme spekulovat, že kernel bude napsaný v .NETu, stejně jako u projektu Singularity. Samozřejmě na root.cz se bude psát, že MS zabil zpětnou kompatibilitu, a jak je to špatné :). Když si jen vzpomenu, co tu bylo křiku, když si MS dovolil odstranit z MS Office importní filtry 20 let starých formátů :)

Pokud to na root.cz nebudou psát ti samí autoři, pak je to v pořádku. Každý může mít jiný názor a projevit ho jen v případě nesouhlasu. Už jsem Vás tuhle nachytal, že personifikujete (přisuzujete lidské vlastnosti) firmám, teď to samé děláte i serverům. :-)

Opravdu: server nemá mozek, nemá názor. To mají jen (různí) lidi, co tam příspívají.

Nevim, jestli sandbox je tim spravnym resenim. Mozna, ze vypolstrovana zvukotesna cela by byla lepsi.

Ne, tím to opravdu není. Je to tím, že se vývojáři nedrží dokumentace, činí nesprávné předpoklady, a spoléhají na nedokumentované vlastnosti systému. Například u těch adresářů i vykrádání resources z knihoven shellu jde o praktiky, které jsou v rozporu nejen s SDK a Design Guides, ale i zdravým rozumem.

Minimalizaci přidělených oprávnění jste mohl provést minimálně od NT4 aplikací vybraného security template (tím nastavíte permissions i user rights).
http://www.windowsecurity.com/articles/Understanding-Windows-Security-Templates.html

S dovolením Windows například od začátku používají NTLM autentizaci, místo plain textu (telnet), nebo dokonce protokolů které jsou prakticky bez autentizace (NFS). Autentizace uživatelů se ve Windows odjakživa prodáví pomocí Local Security Authority Subsystem, kdežto v unixech se prodáděla původně tak, že aplikace dostala heslo v plain textu, a ověřila jeho MD5 proti /etc/passwd. Rovněž Access Control Listy jsou ve Windows NT minimálně od verze 3.51 (a zřejmě už od první verze). Naopak unixy používají svůj systém rwx bitů, a ACL jsou v nejlepším případě volitelným rozšířením (které snad není ani součástí POSIXu).

Windows NT byly certifikované na POSIX compliancy, stejně jako dnes MacOS. Dnešní verze Windows nemají by default podporu POSIXu, ale lze jí doinstalovat. S doinstalovanými Services for UNIX jsou Windows POSIX compliant. Mimochodem Linux nikoliv.

MacOS je technická spatlanina. Přechod z Motorola 68xxx na PowerPC hodil uživatele přes palubu, a systém běžel z větší části emulovaný. Přechod z MacOS 9 na MacOS X vede k situaci, kdy aplikace pro MacOS 9 jedou v sandboxu, s vlastními fonty, vlastními drivery tiskáren atd. Fuj! No a příchod 64 bitů, který dnes v Apple probíhá, je opět technicky zpackaný. Ano, 64-bitová verze licb, k tomu 32-bitový kernel, 32-bitové drivery, 32-bit only Carbon layer... Prostě pejsek a kočička vařili dort.

Když říkáte, že si MS vyžírá jenom to, co si sám nasral* v minulosti, o čem konkrétně mluvíte? Byla tu řeč o tom, že autoři aplikací spoléhají na jména adresářů, která se mohou měnit; autoři aplikací vykrádají ikony a animace z knihoven shellu; autoři aplikací místo zavolání funkce API zobrazí kontextové menu a vyberou pátou položku od konce, což na jedné verzi Windows zobrazí správný dialog, ale na žádné jiné ne. Ve které konkrétní věci z výše uvedených si MS vyžírá, co si sám nasral* v minulosti? Nebo jste mluvil o něčem jiném?

Donedávna máte na mysli před uvedením Windows 2000? :) A víte třeba, že podmínkou udělení loga Degsined for windows 95 byla funkčnost SW i na Windows řady NT? A myslíte si, že ve Windows 95 bylo doporučeno vykrádat resources z knihoven shellu, střílet jména adresářů od boku, vyvolávat pátou položku od konce kontextového menu namísto volání API apod.? Možná až tohle pochopíte, zjistíte, že návyky programátorů jsou prostě takové, že když aplikace kompiluje, tak to bude nejspíš OK, a když ani nepadá, tak je čas na párty. Ne všech programátorů, ale bohužel dost velkého procenta, aby to způsobilo problémy.

Aplikace pro MacOS běží v MacOS X v sandboxu. Důvodem je technická neschopnost Apple. Nebo považujete za výhodu pro uživatele, když starší aplikace mají vlastní fonty, vlastní drivery tiskáren apod.? To "zbastlení dohromady" v praxi znamená udělat nějakou překladovou vrstvu. MS kupodivu bez problému běží aplikace pro DOS, Windows 16-bit, Windows 9x a Windows řady NT bez problémů, a se zachováním kompatibility. Výjimou jsou psasácky napsané aplikace.

Nedělejte se sebe idiota (kolikrát to mám psát?). Mluvil jsem o přechodu na 64 bitů, ne o přechodu na Intel. MacOS je ještě pořád 32-bitový. V nejnovější verzi má 32-bit kernel, 32-bit drivery, 32-bit vrstvu Carbon (ta přes původní prohlášení Apple nebude 64-bitová, a proto se zdržel 64-bitový Photoshop). 64-bit je jen libc a Cocoa, což je vzhledem k absenci řady features ve vrstvě Cocoa dělá z celé věci spíše technologický cirkus.

FP4AWEC.DLL - vy používáte Office 2000? Vy máte problémy s klíči registru? To ze sebe spíš jen děláte idiota, jako obyčejně.

Ještě jednou: myslíte, že vykrádání resources z knihoven, střílení názvů adresářů od boku v rozporu s dokumentací, kódem prováděná aktivování položek menu v shellu místo volání správného API apod. jsou zvyky, které byly v době windows 9x v pořádku?

Kompatibilita: na tomhle světě je to tak, že velká spousta firem dodnes jede účetnictví napsané původně pro DOS. Jsou tu speciální aplikace psané pro DOS, například knihovní, hotelové a další informační systémy. Zpětná kompatibilita je důležitá, ať se vám to líbí, nebo ne. Navíc: if it ain't broke, don't fix it.

Já osobně mám 64-bit Vistu. Ta 16-bit aplikace běžet neumí (32-bitová ano), takže nemám Virtual DOS Machine. Samozřejmě systém musí podporovat 32-bitové aplikace, a to dělá více než dobře (pokud neobsahují 32-bit drivery). Celý systém jede v Unicode (jako všechny Windows řady NT), a aplikace které v Unicode nejedou jsou do něj překládány.

Berličky pro kompatibilitu jsou nutné i v MacOS (viz celý Carbon).

Bity jsou vám šumák, to věřím. Kyž se ale podíváte pod kapotu MacOS X, je to na zvracení. A jak jsem psal, v Carbonu jsou aplikace typu Finder, Photoshop, a další. Celkem smůla.

Mohu se zeptat, jak kokrétně vypadá problém s daným klíčem registru? Nebo rovnou přiznáte, že je to GUID a jméno knihovny, které jste našel někde na Googlu? ;)

Rekl bych, ze problem s danym klicem registru je v totalni blbosti jeho nazvu. Obycejny smrtelnik nema vetsinou moznost zjistit, co to je, kdyz uvazime, jak "dobre" jsou registry zdokumentovane. MS sice predstira, ze uzivatel do registru vybec lezt nemusi, nicmene z nejakeho neznameho duvodu jsem byl jiz mnohokrat nucen do nej lezt a rucne jej cistit a z podobnych nazvu se mi jezi vlasy. I kdyz se clovek snazi, dobre vycistit registry nelze a tak lze jen najit a pobit klice, ktere obsahuji nazev vydavatele nebo aplikace a chlivek s podobnymi nazvy tam jednoduse zustane.

Ten klíč registru má zcela správný název. V SDK najdete popsáno, jak registrace COM komponent vypadá. Uživatel do registrací komponent nemá co hrabat. V .NETu je totéž uloženo v Global Assembly Cache, která je čistě binární, a na Linuxu máte třeba databázi rpm, která je také binární; ani v jednom případě do těch binárních struktur nelezete, a needitujete je. Pokud chcete komponentu odregistrovat, použijte regsvr32 /u [file komponenty]. Opět v SDK najdete popsáno, jak komponenta provádí self-registraci a odregistraci (zavolá se entrypoint DllRegisterServer/DllUnregisterServer).
http://msdn.microsoft.com/en-us/library/ms683954(VS.85).aspx

Odinstalace aplikace samozřejmě odstraňuje registraci COM objektů. Pokud neprovedete odinstalaci, a registrovanou komponentu smažete natvrdo, záznam vám v Registry pravda zůstane. Ale čemu vadí? Sám o sobě zabírá pár set bytů, což systém nijak nezpomalí (ještě jsem neviděl stesky na pomalé instancování objektů v důsledku počtu registrací). Instanci objektu nikdo vytvářet nebude, protože aplikace je mrtvá. A pokud to někdo zkusí, tak dostane chybu, protože komponenta neexistuje.

Takže vidíte, že 1) neznáte základy COM, 2) do registrací komponent nemáte co hrabat, 3) ten "chlívek" je poměrně dobře dokumentovaný, jen mu nerozumíte, 4) pokud neproběhne odinstalace komponenty, není to žádná tragédie.

rpm -qi provádí query info, ale bohužel man nepíše, co to znamená. Windows Installer je výrazně složitější, než rpm. Pro uživatele je k dispozici instalace, odinstalace, a repair. Pro admina jsou k dispozici logy z těchto akcí. Pokud jste vývojář, a chcete zkoumat obsah databáze Windows Installeru, nainstalujte si SDK. Najdete tam skripty, které například vylistují soubory asociované s daným produktem. Jestli se odstraní při odinstalaci, to závisí na jejich nastavení.
Using the Installer Database:
http://msdn.microsoft.com/en-us/library/aa372454(VS.85).aspx
Windows Installer Scripting Examples, zřejmě chcete List Components nebo List Features:
http://msdn.microsoft.com/en-us/library/aa372865(VS.85).aspx
Software Development Kit:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4377F86D-C913-4B5C-B87E-EF72E5B4E065&displaylang=en

Pokud neznáte základy COM, přicházíte o možnost velmi pěkně psát aplikace. Ale vaše chyba.

Pokud máte v logu záznam, že došlo k chybě při instancování komponenty X, lze to řešit hromadou jiných způsobů, než tak, že budete koukat do registru na položky, kterým nerozumíte. Pravda, jako lepší admin byste jim rozumět měl, ale nemůže od vás člověk chtít všechno.

Subsystémy ve Windows pracují na dost podobných principech. Kupodivu za masochismus nepovažujete učit se stovky unixových příkazů, jejich syntaxi, umístění stovek konfiguráků, hromadu bugů a zpoůsobů jak je obcházet (tak by to člověk slušně vychovaný unixem neudělal - tak jste to říkal?), ale naučit se základy Windows, ž když se je snažíte administrovat, to je nad vaše síly.

Na co nejste zvyklí? Vy především nejste na unixech zvyklí na komponenty. Code reuse se provádí pomocí copy-and-paste zdrojáku, v nejlepším případě se používají knihovny. Komponenty již pravda existují také, díky Bonobo a KPart, ale jejich využití je zatím minimální. Unixy jsou holt tak 15 let pozadu.

Pokud neproběhne odinstalace COM komponenty, a místo toho jí smažete z disku (na to zase nejsme zvyklí ve Windows), tak vám v Registry zůstane záznam o komponentě, který nikomu a ničemu nevadí. O kolik systému asi pomůžete, když ho zbavíte pár set bytů položek v Registry? Asi daleko méně, než když po odinstalaci Oracle odstraníte jeho logy, a zbylé konfiguráky různě po disku. Takže z toho nedělejte komedii.

To je mi na prd, kdyz SDK nemam a nehodlam studovat proto, ze nejaka blba aplikace nebu driven na nejaky priblbly HW nekde nadela chliv, ktery si po sobe neumi uklidit a treba namisto vyhledani starych klicu si do registry hodi nove, pri cteni ale pak najde ty stare, protoze jsou v poradi prvni. Nebudu studovat SDK abych ty klice pobil a mohl provest novou instalaci.

RPM databaze s registry nema moc spolecneho. Jeste tak by se registry dalo srovnat s /etc + RPM databazi.

Takze dobre, az mi priste neco nepujde, tak si otevru cmd okno a napisi tam regsvr32 /u. A co dal? Jsem ja vyvojarem aplikace, se kterou mam problemy nebo co? Vy tady furt mluvite o tom, jak jsou Windows mnohem uzivatelsky pratelstejsi, nez GNU/Linux a pak mi napisete, ze mam sve problemy resit pomoci regsvr32 /u. Navic, i kdyby na Linuxu mohla vzniknout situace, kdy v /etc vznikne nova verze konfiguraku po kazde reinstalaci aplikace, vyresil by to lehce Midnight Commander. U Windows to resi regedit. Vase regsvr32 /u je mi na dve veci. To, ze do registru lezt nemusim, je ciste teoreticka zalezitost, ktera by snad mohla platit, kdyby nebylo tolik dementnich aplikaci a driveru.

Proboha co to plácáte? Když znovu registrujete komponentu, která již existuje, tak se klíče v Registry přepíší, a nehrozí žádné riziko. Navíc ještě jednou: při odinstalaci aplikace se odstraňují i COM komponenty, pokud byly součástí instalace, a nejsou sdílené s jinou aplikací.

RPM databáze má s CLSID ve Windows Registry dost společného. Například to, že ani do jednoho nemá uživatel co hrabat.

Až vám něco nepůjde, rozhodně to nevyřešíte tak, že odstraníte registraci nějaké COM komponenty. Tím nejvýše způsobíte to, že až nějaká aplikace tu komponentu bude potřebovat, tak jí nenajde, a zhavaruje. Nechte registrace COM komponent, jak jsou, pokud velmi dobře nevíte, co děláte. Jak byste asi odpověděl člověku, který se ptá "teď mi něco nefunguje, jsem ve /etc, který soubor to mám smazat?" Moje odpověď je "když tomu nerozumíte, nic nemažte", plus bych dotyčnému preventivně urazil ruce ;)

Do Registry lézt nemusíte. Nastavení provádíte z GUI, a zbytek jede sám. Pochopitelně když se něco zadrhne, může vyvstat potřeba to opravit v Registry. Podobně když se rozbije auto, kvalifikovaný člověk se podívá pod kapotu, a něco tam bude kutit. Rozhodně to ale nefunguje tak, že bez znalosti věci kapotu otevřete, a ono se to pak nějak samo udělá.

To je moc hezke, jeste kdybyste to tak namlatil do hlavy nekterym programatorum. Jiz parkrat jsem videl, ze aplikace nebo driver pri instalaci jednoduse vytvori nove klice a o existenci starych se nestara. Zato si ty stare pak nacte ta aplikace pri spusteni. Na uklid pri odinstalaci se pak treba take vykaslou. Cili vznikaji situace typu: Odinstaluji aplikaci z d:, protoze mi schazi misto. Nainstaluji ji na e:, kde mam mista dost. Nechodi to. Proc? Aplikace si cte stare klice, ve kterych se hovori o c:. Podobne kdyz treba instalace lehne nekde uprostred. Bez rucniho promazani registry to uz treba take nerozchodite a jeste treba budete muset dohledat soubory driveru a inf soubor po disku a rucne je pobit.

To, co rikate, chapu. Nejsem az tak zabedneny, jak se mozna domnivate. Nicmene to neni to, co jsem jiz parkrat pozoroval v praxi. A rucni mazani v registry je pakarna. Klice jsou rozptyleny na spouste mist, dale pak v currentcontrolset nebo jak se to, v zaloznich profilech a clovek to nemuze jen tak bezmyslenkovite odentrovat, ale musi si ty pakarny alespon zbezne precist, aby nesmazal neco, co s veci vubec nesouvisi.

Parkrat jsem takle uz registry mazal, nekdy opakovane, kdyz se zjistilo, ze jsem asi nejaky klic prehledl a novou instalaci se navic vytvorily vsechny klice znovu a ja mohl znovu zacit od shora dolu. A ujistuji vas, ze to nedelam, protoze me to bavi. Jinak to proste neslo, ledaze bych dal prednost kompletni reinstalaci uplne vseho znovu, vcetne Windows, coz me bavi jeste mene. Nezbyva tedy, nez otevrit kapotu a s pouzitim intuice dohledat klice podle jmena aplikace, jmena vydavatele (oboji s mezerami i bez), adresaru a co ja vim, ceho jeste. Podle vas bych si na to mel pozvat nejakeho cloveka, vice kvalifikovaneho nez ja. Muzu vam rici predem, co by mi vetsina z nich poradila: Preinstalovat Windows. Odbornik z Microsoftu, ktery by me stal tolik, ze bych si mohl koupit novy pocitac, by mi nejspis rekl totez s tim, ze MS neresi problemy vznikle nespravnymi programatorskymi postupu tretich stran. Cili zbyva jen najit dobrodruha, jako jsem ja a rucne to probrat a pobit. A to si muzu udelat sam, jeste by mi to nekdo dokurvil vic, nez to je.

Za "vynalez" registry se bude Gates smazit v pekle a za trest tam bude promazavat registry soubor o poctu radku rovnajicimu se poctu atomu ve vesmiru.

Bavili jsme se o registraci COM komponent, která je v Registry. Ta nemá s nastavením aplikace nic společného.

Když je řeč o nastavení aplikace, tak na unixech máte stejný problém. Notepad má nastavení na jednom místě, Oracle na řadě míst. Podobně jako v případě Oracle máte konfiguraci ve stromě Oracle, pár souborů /etc, a něco v /etc/init.d, máte konfiguraci na více místech i v Registry. Pokud po sobě Oracle konfiguraci neodstraní (ne, opravdu jí neodstraní), můžete na unixech, stejně jako na Windows, odstranit zbylé adresáře a konfiguraci ručně. Navíc nastavení aplikace v home adresářích uživatelů asi neodstraníte jinak, než manuálně (minimálně pro uživatele jiné, než pro toho aktuálního).

Pokud něco mažete z Registry, můžete si triviálně psát jména klíčů do souboru (pravá myš na klíči, Copy key name, Notepad, CTRL+V). Je pak triviální z toho udělat soubor .reg, který dané klíče smaže sám. Stačí na začátek souboru dopsat hlavičku "Windows Registry Editor Version 5.00" bez uvozovek, jména klíčů zavřít do hranatých závorek, a před vlastní jméno dát minus. Dvojklikem (nebo regedit.exe /s [soubor.reg]) pak klíče smažete. Jak tohle uděláte u konfiguráků? A jak například změníte/založíte nějaké hodnoty ve více konfigurácích? Kdepak, Registry mají řadu výhod.

Výhody Registry jsou například:
- permissions na každém klíči
- vyšší rychlost čtení než z konfiguráku
- daleko vyšší rychlost zápisu než do konfiguráku (konfigurák musíte komplet přepisovat)
- při vícenásobném přístupu nehrozí problémy
- jeden typ konfigurace, jedno API pro přístup k němu; srovnejte s řadou formátů konfiguráků
- možnost zápisu jiných než textových hodnot, například čísel nebo binárek
- snadné zálohování, které se dokonce provádí automaticky (last known good configuration - jak vy zálohujete své /etc?)
- možnost jednoduše změnit konfiguraci více aplikací najednou, bez parsování více typů souborů a jejich upravování (prostě dvojklik na soubor .reg, nebo regedit /s [soubor], nebo centrálně pro doménu pomocí Group Policy)

Pokud vám někdo radí při triviálním problému reinstalovat Windows, tak asi moc kvalifikace nemá. Jsou případy, kdy je reinstalace nejlepší řešení, ale je to výjimečné. Například na jakémkoliv systému po kompromitaci systému trojským koněm (nevíte, kde všude je nějaké svinstvo), nebo na Linuxu po přeražení závislostí rpm balíčku a následném odstavení systému. Vyjma výjimek je ale reinstalace rada lamera, ne profíka. Když jsme u toho, ve Start Menu/Help and support máte Remote Assistance, tedy možnost pozvat někoho, aby vám s počítačem pomohl. Odešlete pozvánku mailem, dotyčný jí otevře, a připojí se k vám. Pozvat si pomoc zvládne každý.

Pokud něco mažete z Registry, nebo ze /etc, tak důrazně doporučuji to dělat na základě znalosti, a ne intuice.

Ma furt pripada jednodussi dohledat a smazat par textaku. Nehlede na to, ze instalace software typicky ma v sobe cisty konfigurak a treba se me pta, jestli ho tam chci nacpat, namisto toho stareho, nebo ho tam nechat valet pod jinym jmenem, abych se do nej mohl podivat. Vicekrat jsem videl pripad na Windows, kdy si aplikace pri kazde instalaci vytvorila klice s nahodne generovanym jmenem. Tedy vas postup s vytvorenim .reg souboru zde naprosto selhava, da se pouzit vzdy jen jednou. Navidim vyhodu ve srovnani s rucnim mazanim rovnou v regeditu, krome moznosti si to jeste jednou promyslet, nez to clovek spusti. Kdyby aplikace pouzivala furt ty same klice, nemusel bych je mazat.

RPM distra nepouzivam, tedy tenhle problem nemam. Kdyz tedy neco jednou za dva roky podelam na systemu, vzdycky to tedy nejak opravim. Windows ty dva roky ani kolikrat nebezi, navzdory nebo spise diky svemu fantastickemu a vyhodnemu registry - Gentoo mi jede jiz minimalne od r. 2004, soude podle dat z /etc. Krome toho, na Linuxu vzdycky muzu preinstalovat kousek systemu, pokud treba je nakopnuty disk a dojde k poskozeni systemu. Presypu na novy disk, opravim a jedu. Jak preinstaluji kousek Windows tedy nevim. Ze by shanenim souboru na jinych masinach a rucnim kopirovani? To snad radsi preinstalovat.

Pri mazani z registry budu i nadale pouzivat intuici a hlavu. Znalost vyznamu tisicu klicu s kryptickymi jmeny jaksi presahuje mnozstvi energie, ktere tomu hodlam zasvetit, i kdyz popis nekterych bych nasel v SDK. BTW, kde najdu pouhy popis klicu, bez SDK? Nepovazoval byste to za zakladni kus dokumentace, ktery by se mel volne povalovat nekde hned na prvni strance MS supportu?

BTW, mam pocit, ze mluvim o koze a vy o voze. Vy mi pisete o teoretickych pripadech, jak by to melo byt, ale ne vzdy je. Ja pisi o pripadech, tak jak na ne narazi obycejny uzivatel, kdyz si treba koupi HW s drivery a softwarem od nejakeho debila, coz je zjevne bezny pripad. A neni to jen pripad noname vyrobcu z Thaiwanu. Treba rozchodit tiskarnu od Xeroxu na Win 2000 a Win XP byl opravdu porod. A rozchodil jsem ji jen diky tomu, ze mam k dispozici oba systemy. Protoze W2k driver na W2k funguje jen pod adminem a na XP vubec, instalace XP driveru se na XP jen rozpakuje, zobrazi jakysi dialog a sekne se. Nicmene rozpakovane soubory lze pouzit k instalaci na W2k i na XP pomoci Add printer dialogu. Jak u blbych na dvorku.

S radou reinstalovat se od "odborniku" setkate asi casteji, nez si myslite. PC technici, kteri jsou k dispozici obycejnemu smrtelnikovi, totiz nejsou MS inzenyri s deseti certfikaty. Kdyby byli, delali by neco jineho a za vic. Jsou to spis "odbornici", ktere si k pocitaci radsi nepustim.

Dohledat a smazat pár texťáků mi nepřijde jednodušší. Navíc pokud nějaký texťák sdílí více aplikací (třeba rc skripty), tak bych mazání nedoporučil :), a pak je situace jasně ve prospěch Registry.
Ještě nikdy jsem neviděl aplikaci pro Windows, která by si vytvářela klíče s náhodně generovaným jménem, protože je to děsná prasárna. Který SW tuto prasárnu dělá? Upozorňuji, že GUID typu 00000304-0000-0000-C000-000000000046 jsou při opakovaných instalacích stejné, nemění se.

Já měl Windows XP mnoho let, prodělaly několik upgradů HW. Nevidím důvod, proč by "neměly vydržet". Naprotá většina reinstalací je takové to "hm, před týdnem jsem něco nakopnul, a teď se to chová divně, tak to raději reinstaluji" - tedy ne problém Windows, ale problém uživatele. Pro takové uživatele Windows XP obsahují System Restore. Řeknete "vrátit systém do stavu před týdnem", a změny se odrolují (pochopitelně ne v dokumentech). Když se vám poškodí Registry, při startu zvolíte Lask Known Good Configuration, a použije se kopie pořízená při posledním úspěšném bootu. Když se poškodí startovací prostředí, použijete CD, a opravíte startovací prostředí. Když se poškodí nějaké jiné soubory, tak můžete provést in-place upgrade; ten zachová veškeré programy i nastavení, a provede "upgrade XP na XP". Ve Vistě se zabootuje z DVD a použije se repair option. No a samozřejmě můžete nainstalovat Windows na jiný disk nebo do jiného adresáře, a soubory překopírovat, případně totéž udělat z Recovery Console.
http://support.microsoft.com/kb/315341
http://windowshelp.microsoft.com/Windows/en-US/help/5c59f8c1-b0d1-4f1a-af55-74f3922f3f351033.mspx#EI

Reference Registry samozřejmě existuje, viz linky níže. Nicméně jistě chápete, že podobná dokumentace nemůže popisovat klíče založené aplikacemi. Navíc se přiznávám, že jsem tuhle dokumentaci ještě nikdy nepotřeboval.
http://support.microsoft.com/kb/256986
http://technet2.microsoft.com/windowsserver/en/library/56a33a88-a7b2-4f21-ab5e-5c62d728619f1033.mspx?mfr=true

Dělá ván problém "znalost vyznamu tisicu klicu s kryptickymi jmeny"? Tak na ně kašlete. Registry potřebujete znát pro pokročilý troubleshooting (mimochodem jak provádíte pokročilý troubleshooting svého auta, nebo své mikrovlnky?), a i tam se znalost omezuje na cca 5 lokací v Registry (řekněme HKCU\Software, HKLM\Software, HKLM\SYSTEM\CurrentControlSet\Services, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run/RunOnce). Naproti tomu znalost názvu a syntaxe stovek unixových příkazů, znalost umístění konfiguráků a znalost jejich obsahu, znalost log files, ovládání vi, a podobné věci, to jsou prostě základy, že?

Pokud kupujete HW, kupujte ten, který je listovaný v Hardware Compatibility Listu pro váš operační systém. Když koupíte něco, co v HCL není, nikdo a nic vám nezaručuje, že ten HW vůbec bude fungovat. Když k tiskárně nedostanete drivery, a nenajdete je na webu výrobce, vraťte tiskárnu a chtějte zpět peníze. Případně kontaktujte support výrobce daného zařízení (ten vám asi řekne, že OS není podporovaný, a že máte smůlu).

Jestli nemáte přístup k odborníkům, je to v principu váš problém. Když si koupíte počítač Dell, můžete si připlatit technickou podporu, kterou máte na 3 roky za 2500 Kč. Možná seženete i někoho levnějšího. Berte to tak, že snaha vynaložená člověkem, kterého obtěžujete svými zdarma-dotazy, bývá velmi nízká.

tak to s vykradanim resources spominas uz minimalne treti krat. snad ti len nedochadzaju „argumenty“?

Buďte trochu soudný. Mluvil jste o unixech sedmdesátých let. Protokol Kerberos pochází z let osmdesátých. Když jsme u toho, většina unixových systémů dodnes Kerberos nejede (na rozdíl od windows). Protokol NFS je autentizovaný uvedením UID a GID. Telnet byl v 70. letech standardní prostředek, zoufalé to bylo. SSH pochází až z roku 1995, a větší rozšíření přišlo až okolo roku 2000.

POSIX ve Windows na úrovni API nepoužívá BSD kód. Jde o vrstvu, která některá volání libc implementuje (tam by teoreticky použití BSD kódu bylo možné, ale podle všeho zbytečně), a zbytek překládá těch pár volání libc na funkce NT kernelu. Obdobně libs na unixech některé věci implementuje sama, a většina jich propadá na syscalls (které ovšem Windows mají odlišné). Vlastní kernel potom nemá pochopitelně s BSD nic společného. Ohledně utilit je to jiná, ty jsou zřejmě z bsd. Nevidím důvod, proč psát znovu more, vi, grep, a další kousky. Za dílo MS se to jistě označit dá. Rozhodně více, než se MacOS X dá označit za dílo Apple ;)

Vy nevíte, jak napsat 32-bit kernel, který umí obsloužit 64-bitový proces? To jsou mi věci. A víte, že je možné na 32-bit OS běžet ve vmware 64-bit systém? Jak se to asi dělá? A viděl jste třeba Win32s layer pro Win3.11, který umožňoval běžet na nich 32-bitové aplikace? Ano, podobnou věc dnes páchá Apple se 64-bity.

Carbon je možná zastaralý, ale byla do něj pracně převedena většina aplikací typu Finder, Photoshop, PageMaker atd. Přitom převod z Classic do Carbon byl ještě poměrně jednoduchý. Na Cocoa se nebude převádět, ale prakticky komplet přepisovat (Adobe u Photoshopu hovoří o milionech řádků). Veliká sranda bude jistě interakce s 32-bitovým Finderem, 32-bitovým QuickTime (QtKit pokrývá jen část funkcionality QuickTime) atd.
http://arstechnica.com/journals/apple.ars/2007/06/13/64-bit-support-in-leopard-no-carbon-love
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6
http://www.apple.com/server/macosx/snowleopard/

No a 32-bitové drivery? Asi vám nemusím říkat, že pro 32-bit drivery musíte thunkovat buffery, na které jaksi nedosáhne. Navíc Snow Leopard bude údajně mít 64-bit kernel, takže uvidíme, jak to bude s drivery. Faktem také je, že HW pro Apple je tak málo, že drivery nejsou větší problém. Uživatelé staršího HW se mohou hodit přes palubu - Apple v tom má praxi.

"Buďte trochu soudný. Mluvil jste o unixech sedmdesátých let. Protokol Kerberos pochází z let osmdesátých. Když jsme u toho, většina unixových systémů dodnes Kerberos nejede (na rozdíl od windows). Protokol NFS je autentizovaný uvedením UID a GID. Telnet byl v 70. letech standardní prostředek, zoufalé to bylo. SSH pochází až z roku 1995, a větší rozšíření přišlo až okolo roku 2000."

Nic proti, ale jak to v 80. letech řešily Windows 1.x-3.x? Taky měly NTLM? Nepřijde mi příliš relevantní odkazovat na dřevní doby, protože ty měly snad všechny systémy - jen Unix je měl poněkud dříve než Windows, toť vše, a vůbec nevím, co to má společného s tím, jestli Kerberos umí nebo neumí dnešní NFS server. Normální člověk taky v podnikové síti nevypne u windowsího sdílení disků veškeré zabezpečení, když ho může nechat zapnuté, že?

S "větším rozšířením až teď" bych taky pomlčel, ona spousta firem neadoptuje nové systémy hned, takže se to zjevně týká i Windows. BTW, už dlouho jsem nenarazil na Linux, který by Kerberos neuměl. On se tomu člověk v enterprise distribucích přeci jen nevyhne, protože podnikové prostředí si žádá svoje. Proto by mě docela zajímalo, které unixy Kerberos "nejedou". :-)

"Vy nevíte, jak napsat 32-bit kernel, který umí obsloužit 64-bitový proces? To jsou mi věci. A víte, že je možné na 32-bit OS běžet ve vmware 64-bit systém? Jak se to asi dělá? A viděl jste třeba Win32s layer pro Win3.11, který umožňoval běžet na nich 32-bitové aplikace? Ano, podobnou věc dnes páchá Apple se 64-bity."

Takže kdyby tohle Windows uměly, daly by se v nich provozovat aplikace s velkými nároky na paměť a přitom by pro ně fungovaly existující ovladače? :-)))

"Uživatelé staršího HW se mohou hodit přes palubu - Apple v tom má praxi."

Větší praxi než Microsoft+výrobci PC hardwaru? To se mi ani nezdá. Snad až letos Apple dropnul podporu procesorů z roku 1997, a to ještě jen kvůli staré architektuře. Mám novější skener a ten není podporovaný ve Windows výrobcem už teď. G4+ rozhodně je podporované.

Windows mají POSIX kompatibilitu pouze pro usnadnění migrace z UNIXů. Nikdy nebylo zamýšleno, že by se pro windows psaly POSIX aplikace. Vždyť POSIX proti Win32 nic neumí. Nemá API pro správu systému (zkuste přidat uživatele, získat seznam běžících procesů, vypnout jeden síťový interface), neřeší GUI, 2D ani 3D grafiku, multimédia, nepodporuje ACL, neřeší komponenty, má příšernou ne-podporu Unicode... Ne, tuhle vykopávku ani v roce 1989 MS nechtěl. Nakonec MS se moudře zbavil Xenixu, který dlouhá léta vlastnil, a který byl údajně svého času unixem s největším počtem instalací.

OOo pro SFU není podporovaný. Přeložit by asi šel. Gimp trvalo upravit a přeložit údajně pár hodin.

MacOS má Single Unix Specification v3 certifikaci. A jak se jmenuje compliancy test suite pro tuto certifikaci? Je to Posix Certification Test Suite ;)

Jistě, třeba bez grafiky a GUI je systém daleko jenodušší napsat :). Otázkou je, k čemu dnes takový systém je.

1. Ano, POSIX neřeší API, které by vrátilo seznam běžících procesů. Má jen utilitu ps, a ta může být implementovaná různě. /proc mají jen některé unixy, a ještě s odlišnostmi.
2. ifconfig mají všichni, ale řeč byla o API. Nebo ze svého SW budete provádět shell out a spouštět ifconfig?
3. Ano, POSIX neřeší ACL. Některé unixy ho řeší podle draftů, spolehnout se na to pochopitelně nedá.
4. X11 je technická katastrofa. Zkuste se připojit přes dial-up nebo GPRS/EDGE a provozovat X11; nejspíš nedokončíte ani login, protože po stisku klávesy budete čekat vteřinu na reakci (zkoušeno na AIXu a Solarisu). Kupodivu s Windows Remote Desktopem to není jako na lokální síti, ale dá se pracovat. X11 je velmi špatně navržené.
"Trapná windowsí plocha" je řadu let 2D akcelerovaná. Ve Vistě je 3D akcelerovaná. A to včetně akcelerace rastrování fontů, akcelerace ClearType atd. Každé okno se skládá z akcelerovaných primitiv typu obdélníky, písmenka, bitmapy apod. Naproti tomu kompozitní desktopy typu Compiz kreslí obsah oken bez akcelerace, a pouze aranžují výsledné textury po desktopu.
5. Nevím, jestli byl NeXT prvním systémem s podporou Unicode. Vím, že Cocoa na MacOS používá datový typ UniChar, což je UTF-16, stejně jako ve Windows. Ten BSD kód pod tím potom reprezentuje Unicode v UTF-8, což je klasický MacOS styl "nějak to splácáme". Windows používají od kernelu po .NET všude UTF-16, jména souborů jsou na disku v UTF-16 (na NTFS i FAT). A to proto, že autoři při návrhu přemýšleli, a prováděli do v devadesátých letech, nikoliv v sedmdesátých. Unixy mají prostě své C API založené na datovém typu char, a co skrz něj leze, to je jim celkem jedno. V důsledku toho se na disku mohou míchat názvy souborů v různých kódováních. Navíc podobně jako na MacOS různé tolkity reprezentují Unicode různě. Například Qt používá UTF-16, takže se všechny stringy neustále převádí mezi UTF-16 a UTF-8 (při volání i při návratu z funkce).

Ad 4:

X11 je na svoji dobu technicky velmi dobře vyřešené. Není prostě dělané na dial-up.

Pokud to chápu dobře, příspěvek, na který jste reagoval, popisoval vzdálenou plochu, nikoli lokální plochu. Je i vzdálená plocha 3D akcelerovaná (pod UNIXem může být)? Nedávno jsem viděl jak se na vzdálené ploše pouštělo video a zobrazoval se jenom prázdný (tuším, že černý) obdélník. Síť byla rychlá.

Diskutovalo se o tom, že protokol X11 je zbytečně neúsporný a že se v praxi dá 200-krát komprimovat. Ale to není chyba návrhu, prostě bylo asi dřív důležitější jednodušší dekódování než přenosová kapacita. V každém případě se problém dá vyřešit použitím něčeho jiného než X11. Napadá mě VNC, ale určitě existuje i něco jiného (VNC je prý také docela neefektivní).

Ad 5:

Nevidím výhodu UTF-16 nad UTF-8. Je lepší, že je víc cool nebo že má u sebe číslo o 8 vyšší? Pokud vím, tak některé znaky, co se v Unicode nevešly do 16 bitů, umí UTF-8 řešit, ale UTF-16 ne. Vím, že v Javě se to nějak snažili řešit, myslím, že některé znaky se pak reprezentují jako dvojice 16-bitových. Takže stejný způsob jako v UTF-8, pouze komplikovanější.

UTF-16 má větší spotřebu paměti, většina operací, jako porovnávání řetězců apod. je díky tomu pro většinu jazyků pomalejší.

Proč by se na disku v UTF-8 nemohly míchat různá kódování? Pokud má soubor u sebe informaci, v jakém kódování je jeho název, pak je možná transformace do UTF-8 stejně dobře jako do UTF-16. Navíc mi uniká, proč by to někdo chtěl dělat. UTF by mělo být nadmnožinou všech ostatních kódování, tak proč ukládat jméno jednoho souboru v UTF a druhého v něčem jiném. Proč to taky neuložit v UTF?

Linux měl podporu Unicode v dobách, kdy byly s kódovými stránkami na Windows velké problémy. Pokud vím, tak koexistenci jazyků umí Windows až od verze Vista.

Co se týče POSIXu, tak ano, máte pravdu, neřeší tolik věcí, co Windows API. Jenže ne vždy musí být cílem dát do toho všechno. Důsledkem toho je, že je POSIX mnohem jednodušší implementovat a dá se použít i na různých neobvyklých embedded systémech (my děláme např. s vxWorks, které mají taky POSIX). Implementovat na embedded systémech Windows API mi přijde jako zbytečná zátěž pro všechny, navíc to bude mnohem větší a náročnější.

Prostě, když chcete vyvíjet pro UNIX, nestačí vám pouze POSIX, ale musíte podle potřeby používat další standardy nebo se uchýlit k řešením, co nejsou přenositelná (to ale Windows API není v podstatě taky).

Nejsem si zdaleka jistý, jestli je X11 na svou dobu dobře technicky řešené, ale jsem si zcela jistý, že na dnešní dobu je stavěné naprosto nevhodně. Srovnejte s Windows (popisovány XP, u Visty je to složitější): drivery zařízení typu grafické karty, tiskárny, plottery atd mají standardní interface driverů. Každý driver má nějaké capabilities, například "umím bitmapu", "umím barevný obdélník", "umím rastrovat písmo", "umím křivky". Aplikace zavolá modul GDI, řekne "budu kreslit po kontextu X" kde X je okno, tiskárna, plotter apod., a volá kreslicí funkce (ty jsou samozřejmě pro všechny zařízení stejné). Modul GDI přeloží volání aplikace na ty primitiva driverů zařízení, které driver umí (například pro GDI tiskárnu vyrastruje vše do bitmapy, pro plotter převede vše na křivky, u grafické karty podle toho co umí). U toho se GDI ještě postará o správu barev pro všechny aplikace (profily, převody prostorů, případně separace).
Remote Desktop je potom prostě další driver zařízení, který nabízí capabilities, které umí klient na druhé straně sítě (třeba neoficiální klient pro DOS umí jen bitmapy). Remote Desktop je úsporný, má kompresi, šifrování, podporuje certifikáty, umí přesměrovat clipboard, zvuk apod, a ještě nabízí pro vývojáře možnost posílat vlastní data, takže se dá implementovat cokoliv dalšího. Takhle vypadá grafický subsystém. Čistě navržený, elegantní, funkční. X11 je proti tomu pravěk. A to se jedná o GDI, které je dnes nahrazováno WGF.

Jistou UTF-16 je to, že umí znaky Unicode reprezentovat jedním wcharem, bohužel s výjimkou surrogate pairs. Primární problém Unicode na unixech je ale v něčem úplně jiném. Většina libc není locale aware. Pokud aplikace pracuje v 8859-2 (starší aplikace bez podpory UTF-8), zapisuje například názvy souborů na disk v 8859-2. Naopak Qt aplikace zapisují vždy názvy UTF-8, i když zbytek aplikací třeba běží v 8859-2. To vede k míchání názvů souborů v různých code pages na disku. Qt navíc používá UTF-16 stringy. To jednak znamená neustálé překlady mezi UTF-16 a UTF-8, a potom v kombinaci s výše zmíněným fakt, že název souboru zapsaný v 8859-2 nelze korektně reprezentovat v Qt (název není platná UTF-8 sekvence, nelze jí ho převést do UTF-16).

Linux dlouhá léta podporu Unicode neměl, a teď jí má zbastlenou přes staré API. Windows řady NT jsou odjakživa komplet v Unicode. NTFS i (V)FAT má názvy souborů v Unicode, veškeré API pouívá Unicode stringy. Aplikace, která neumí Unicode (DOS, Win16, Win9x), volá jinou verzi API, která provádí překlad parametrů volání do Unicode. Všimněte si, že se překlad týká jen starých aplikací, kdežto v Qt se bude opakovaně překládat každý skoro string z/do UTF-8 až do konce věků.

Na embedded zařízeních lze použít jak embedded XP, tak windows CE. Pochopitelně si můžete vybrat, jaké komponenty chcete, například jen kernel.

A znáte technologii Display PostScript vy? Nejde o žádné "rozšíření nad X11". Šlo o obdobu Windows GDI, která pracuje s PostScriptem. Nevýhody:
- nutnost míst PS licenci od Adobe
- relativně vysoká HW náročnost
- špatná podpora vektorových fontů na monitorech (dlouhá léta velký problém PostScriptu)

Podle vašeho linku na Wiki dnes Display PostScript nepoužívá ani Apple (používá obdobu postavenou na PDF), mimo jiné aby se vyhnul licenčním poplatkům za PS.

Nejvíce mi ale uniká spojitost s diskutovaným tématem. Display PostScript je historická technologie, která nebyla unixová Linuxová.

UNIX je to, co odpovídá specifikaci Single UNIX (dříve POSIX). NeXTSTEP je postavený na unixových základech, ale řada jeho vlastností (včetně Display PostScript) není unixová.

GNUStep (který existuje i pro NT) jsem nikdy nepoužíval, takže nemůžu hodnotit jeho kompletnost a použitelnost. Dohledal jsem jen stesky na nepoužitelnost AppKitu, který je údajně velmi pomalý. Faktem ale je, že aplikace na unixech dnes nepoužívají GNUStep, ale předpotopní X11.

Jestli je novější DPS, nebo GDI, to opravdu netuším. Zato vím zcela jistě, že DPS by nebylo možné použít na HW, na kterém běžely Windows 9x, natož Windows 3.x.

DPS behalo na hardware, na kterem behaly Windows 9x. Provozoval jsem NeXTSTEP na 486. DPS vzniklo jeste pred rokem 1990 (snadno overitelne).

Linux měl podporu UTF-8 minimálně cca od konce 90 let, v roce 2002 už měl RedHat 8.0 Unicode defaultně. Nicméně historie není tak důležitá (tj. mastit si ego, kdo měl co dřív je jen sport, nemá to reálný význam) jako současný stav.

V čem má uživatel prospěch z toho, že UTF-16 umí všechny znaky reprezentovat jedním wcharem (tedy samozřejmě až na ty, které musí reprezentovat dvěma, a přibližuje se UTF-8 :-))? Pro programátory aplikací to význam mít může, ale ti samozřejmě mohou pracovat s UTF-16 interně a názvy souborů z/do UTF-8 konvertovat. Převod je bezztrátový.

Libc samozřejmě je locale aware, pokud máte správně nastavený jazyk, třídí vám podle toho jazyku a dodržuje i další konvence. Přepnete jazyk a změní se vám vše včetně třídění. To je přesně to, co nejpoužívanější verze Windows neumí. Vista to asi umí, prý nastal v podpoře jazyků velký pokrok. Už snad není nutné pro změnu jazyka přeinstalovat systém (z jiného CD!).

Vtip je v tom, že starší aplikace, které Unicode nepodporují, získají podporu automaticky. Samozřejmě nezapisují na disk jména v latin 2, pokud stringy se jmény souborů s diakritikou nemají přímo v kódu (což určitě spadá pod vaší definici "starých, bastlených" aplikací, kterým se to ve Windows samozřejmě promíjí). Aplikace totiž jméno souboru dostane odněkud zvenku - z příkazové řádky, z textového pole ve formuláři, atp. Dostane ho v UTF-8 a tak ho samozřejmě zapíše správně - aniž si musí uvědomovat, že pracuje s Unicode.

Se soubory, co měly špatnou diakritiku jsem přišel do styku pouze při rozbalování stařičkého ZIP souboru z Windows či DOSu (potvrdil jsem si, že ke stejnému problému dojde i na Windows). Jinak se vše samozřejmě vytvoří správně. A kdybych použil nějaký switch při rozbalování, tak mi to zip nejspíš sám převedl, problém byl pravděpodobně v tom, že v daném ZIP souboru nebylo kódování specifikováno.

Jak píšete o jménu souboru v latin 2, zobrazující se v Qt dialogu, tak je to samozřejmě pitomost. Na disku prostě nemáte žádné soubory se jménem v kódování latin 2. Kde by se tam vzaly? Prostě tam v kódování UTF-8 nejsou. Když se snažíte, vytvoříte soubor, co nebude mít název platný v UTF-8 (ale třeba bude platný v latin 2). Přesto s ním půjde pracovat. Ale v první řadě se tam vůbec nic takového u normálních programů nevyskytne.

Překlad stringů v Qt je problém výkonu, nikoli problém pro uživatele. A u málokoho tráví procesor desítky procent času zobrazováním názvů souborů v Qt, aby to byl problém.

Ad poslední odstavec:
Já jsem nemluvil o tom, jak ořezat Windows. Věřím, že to jde. Problém je v tom, že pak to nepodporuje ono bohaté Windows API a s aplikacemi pro Winapi se můžete jít klouzat. Naopak ořezat Linux, aby uměl POSIX, je snadné a výsledek bude miniaturní.
Abych použil marketing-speak, tak Linux API je modulární, skládá se z POSIX API, Kernel/libc API nad standard POSIX, X11 API, OpenGL API, SDL API. Namixujete si to, jak potřebujete. :-)

Podpora Unicode byla ve windows NT už v návrhu, a do stejného stupně podpory Unicode se unixy nedostaly (a zjevně nedostanou).

Pro autory aplikací opravdu má význam používat wchary místo charů. Převod wcharl na char (UTF-8) je bezeztrátový, ale naopak to nefunguje (existují neplaté UTF-8 sekvence).
Teď se podívejme, jak se řeší situace ve starých a nových aplikacích na Linuxu a ve Windows:
Linux: staré aplikace používají char a cp 8859-*; nové aplikace (například psané v Qt) používají UTF-16 a při každém volání neustále převádějí stringy do UTF-8 a zase zpět. Převod se týká všech Qt aplikací, aplikací Mono, a možná i Javy (nebudu to teď hledat), a bude nutný navždy.
Windows: staré ne-Unicode aplikace používají char, který je systémem převeden na UTF-16. Převod se týká jen ne-Unicode aplikací. Nové aplikace jedou v UTF-16, a nic se nepřevádí.

Libc je částečně locale aware. Ve Windows samozřejmě probíhá třídění, zobrazování data atd. podle locale nastaveného v Control Panels/Regional Settings, takže v českých Windows 95 můžete mít německé třídění a formát data.
Když mluvíme o lokalizaci, tam mají unixy ohromné nedodělky. Windows byly odjakživa dodávány v řadě jazykových verzí. Od Windows 2000 navíc můžete do anglických Windows doinstalovat jazykové moduly. Například češtinu, arabštinu a řečtinu. Ve Vistě je změna jen v tom, že tyhle lokalizační balíčky jsou součástí verze Ultimate, kdežto dříve byly součástí multilicenčních programů (například Select). Naopak Linux má lokalizaci mimořádně mizernou. Většina nápovědy a dokumentace není lokalizovaná, řada programů v distrech také ne. Co lokalizované je, zpravidla je překládané amatérsky, stylem každý pes jiná ves.

Zpět k locale aware funkcím libc. Například funkce pro práci se soubory nejsou locate aware. Když aplikace napsaná pro code page 8859-2 (pracující v českém locale) zapíše soubor "ěščřž.txt", tak na disku skončí "ěščřž.txt" v code page 8859-2, bez ohledu na to, že zbytek aplikací zapisuje názvy souborů v UTF-8.

Starší aplikace, které Unicode nepodporují, jeho podporu zdarma nezískají. Ani trivialita typu filtru more nefunguje korektně. Když použijete more psaný bez podpory UTF-8 na zobrazení ruského textu, bude lámat po 80 charech, což není 80 znaků (viz UTF-8 sekvence). O použití ne-Unicode vi na editaci UTF-8 textu, nebo o GUI aplikacích, vůbec nemluvě.

Soubory s názvy v codepage 8859-2 na disku klidně můžete mít. Pokud použijete jakoukoliv aplikaci, která jede v ne-Unicode locale, je problém na světe (viz výše). Navíc aplikace psané v Qt zapisují názvy souborů vždy v UTF-8, i na ne-Unicode systému.

K poslednímu odstavci:
- "POSIX API" je libc
- Namixovat si můžete, co chcete. Problém je, že je to pak peklo pro vývojáře, pro support aplikací, a nakonec i pro uživatele. Další problém je, že X11 je příšernost, OpenGL řeší grafiku ale ne vstupní zařízení a 3D zvuk, SDL je děsivě primitivní...
- Podobně jako můžete ořezat distro Linuxu, aby umělo jen funkce libc (plus pochopitelně syscalls, tedy funkce kernelu, na kterém je libc závislá), můžete ořezat i Windows Embedded tak, že bude umět jen funkce knihovny kernel32. A podobně jako na ořezaném Linuxu nepůjde OpenOffice (protože nebudete mít X11, a řadu dalších věcí), nepůjde na ořezaných Windows aplikace, která bude vyžadovat nějaké API, které jste ořízl. To je snad logické.

Pokud byly ve škole Windows 2000 a vyšší, tak to samozřejmě šlo.

Pokud vím, tak ještě ve Windows XP byly problémy s vícejazyčnou instalací. Někdo, kdo znal Windows, mi říkal, že je třeba problém mít české Office na anglických Windows. Ty lokalizační balíčky, těch mohlo být najednou nainstalovaných víc a šlo mezi nimi přepínat? Včetně změny jazyka, kterým systém komunikuje (tj. jestli to nebyly třeba jenom slovníky apod.)?

Lokalizace aplikací na Linuxu - o tom žádná. Český překlad Windows je velmi kvalitní a překlad spousty aplikací pro Linux prostě není. Já jsem ale spíš myslel na technologický aspekt lokalizace, tj. jak by to mohlo být s danou technologií.


Máte pravdu, je výhodnější mít API, kde dochází k co nejmenšímu množství konverzí.

Proč by ale aplikace, co není locale-aware zapisovala soubor "ěščřž.txt" - kde ho vezme? Pokud je zapnutá UTF-8 locale, tak je velmi málo cest, jak se k ní ten string může dostat jinak než v UTF-8. Aplikace sama si ten název nevymyslí - dostane ho z příkazové řádky nebo třeba z GUI dialogu.

Ano, pokud použijete more bez podpory locales, tak opravdu s UTF-8 nefunguje. Vtip je v tom, že máte defaultně nainstalovaný more (nebo less?) s tou podporou, takže proč byste upgradoval na more bez podpory, že.

Určitě je fakt, že Windows API je mnohem komplexnější a řeší věci, které se jinde dělají těžko. Jsou ale někde ve Windows API definovány podmnožiny, aby někdo mohl říct: tohle poběží na Windows API XXX, bez podpory grafiky, apod.?

1. Jak jsem psal, /proc není součástí POSIXu, a jde o rozšíření, které je na různých systémech různé. Unix nemusí vůbec mít /proc. POSIX prostě nemá funkce pro správu procesů.
2. Místo volání API spouštět utilitu, a parsovat výsledek? To si děláte srandu, nebo to myslíte vážně? Absence řady API v POSIXu je trestuhodná.
3. X11 je mimořádně nenežraný protokol, který na slabším spojení nelze použít. Samozřejmě to je problém i na lokální síti pokud byste chtěl používat tenké klienty ve větším počtu.
3D akcelerace Remote Desktop protokolu je k dispozici od Windows Vista. Starší verze Windows neuměly přes RDP posílat OpenGL ani DirectX, protože to nemá smysl (hru si tak nezahrajete). Citrix Metaframe coby rozšíření Windows terminálových služeb to ale snad uměl.

Teď trochu tápu v dávných dějinách... ale vzpomínám, že byly (už od dob DOSu) situace, kdy nedokumentované funkce byly jediným řešením. Tedy prasárna M$ kvůli konkurenční výhodě. Pokud to M$ vývojáře naučil, netřeba se divit, že se toho drží.

Ale kdež.

1. Ssh pochází z roku 1995, a pořádně se rozšířilo někdy před rokem 2000. Windows NT používají NTLM odjakživa. Jakými zabezpečenými kanály se přenášel telnet? Abychom byli oba v obraze, kolega mi tu mimo jiné tvrdil, že Windows "konečně směřují ke standardu unixů ze sedmdesátých let".
2. Jistě. Pro přístup k NFS exportu potřebujete uvést UID a GID, a tím autentizace končí. S NFS v4 to může být lepší, ale faktem je, že i dnes v datových centrech uvidíte hromady strojů, které jsou autentizované jen přes UID/GID, a v lepším případě ještě IP adresou.
3. Windows jsou POSIX compliant jen pokud apikaci běžíte pod Services for UNIX. Taková aplikace pak nemá jednotky, ale strom začínající /, vidí /dev, má POSIX hardlinky a case sensitive file names, používá libc interface atd. Samozřejmě to může vést k situaci, kdy v POSIX subsystému vyvtoříte například soubory "readme.txt" a "Readme.txt", což pak ve Win32 bude mít nepredikovatelné výsledky (jak je psáno v dokumentaci). Domnívám se, že tečka na konci názvu je přesně z téhle kategorie.

Já například doma používal NT 4.0 Workstation od SP3.

Ano, v ČR měla většina domácích uživatelů ukradené Windows 9x. A co má být? To znamená jen to, že pro lidi byla důležitá nízká HW náročnost, kompatibilita s MS-DOSem, a multiuživatelské rysy systému nepovažovali za prioritu (stejně jako placení za SW).

A tom jsme snad již mluvili. MS-DOS byl levným systémem pro levný HW, a nemohl si dovolit věci typu správy paměti a procesů. OS/2 selhala díky marketingové idiocii IBM. Windows byly nadstavbou pro psaní grafického interface, Windows 9x byly konvergencí k Windows NT, a teprve Windows NT si dělaly ambice být plnokrevným OS srovnatelným s unixy.

Pokud jsem si všiml, tak Windows NT 4 například doporučoval Dell na svých stránkách. Faktem je, že masivní rozšíření přišlo až s Windows 2000 (i když u nás jsme jeli NT 4 i NT 3.51). A jak jsem již psal, Windows 95 měly být původně jedinými Windows řady 9x. Windows ME se MS dost bránil, ale nebylo zbytí, protože řada výrobců HW nechtěla psát drivery pro Windows řady NT, a řada SW byla napsaná tak divoce, že v řadě NT neběžela. A jak jsem psal minule, vy byste zřejmě raději viděl, kdyby MS násilím cpal na trh Windows 2000, a nerozhlížel se okolo. A dnes byste pro změnu necpal lidem nějaké ošklivé Windows Vista. To proto, že MS to dělá prostě špatně, a vy byste to udělal lépe ;)

Samozřejmě i v době Windows 9x platila řada pravidel. Zapisovat nastavení aplikace do Program Files, vykrádat resources z knihoven shellu, aktivovat pomocí window messages položky v oknech shellu místo volání příslušného API (prohřešky které jsme nedávno diskuzovali) byly stejným porušením pravidel tehdy, jako dnes. A kdo že ty prasárny vývojáře naučil? MS to rozhodně nebyl.

Ohledně telnetu mlžím? Jak to tedy bylo, povídejte.

Jak byste asi na IBM PC XT s procesorem 8088 prováděl zabezpečení, vy komiku?

Jaké mechanismy pro vynucování korektního chování byste asi zavedl na systému, který musel mít tak nízkou HW náročnost, že neměl ani implementaci bezpečnosti, a musel například podporovat aplikace MS-DOSu a drivery MS-DOSu? Kdo má mozek, jistě ví.

Telnet, bod 4: byl jste to vy, kdo tu říkal, že Windows NT se snaží blížit beěnžm features unixů sedmdesátých let?

Zajímavé je, že máte čas na přihlouplé argumenty a na šaškárny, ale když jde o diskuzi k vaším výrokům, tak najednou nemáte čas ani náladu.

Jak byste podporoval drivery MS-DOSu s použitím sandboxu? Umíte si představit spotřebu paměti při běhu aplikací v sandboxu? OS/2 na tom dojela, a adaptaci NT to zpozdilo o mnoho let. Minix nenabízel ani kompatibilitu s MS-DOSem, ani GUI, ani podporu multimédií, natož aplikační základnu; to všechno Windows měly.

Registrovaný samozřejmě jsem, ale nevidím důvod se přihlašovat.

Vážený pane Prýmek, několikrát jsem vás žádal, abyste se nechoval jako hovado. Pokud jsem si všiml, tak jste to právě vy, kdo napadá mě. Zameťte si před vlastním prahem, uklidněte hormony, dejte si horký čaj, a učte se, učte se, učte se.

To že Dell něco na svých stránkách doporučoval může mít v zásadě 3 důvody:

1. beželo to všude dobře, ale bylo to nejlepší.
2. jako jediné to beželo dobře na Dellech, ostatní systémy na tom HW měly problémy s ovladači.
3. Dell za toto doporučení dostal peníze (ano, toto se skutečně děje) - přímo nebo slevu.

Já myslím, že Dell radil zákazníkům "Dell pro business dopručuje Windows NT" protože věřil, že je to nejlepší pro jeho zákazníka :). Prostě mají ty zákazníky tak rádi :)

:-)

1. Máte pravdu, neodporujeme si. Ovšem vy jste minule odporoval mě, a tvrdil jste, že šířím FUD. Zjevně nikoliv.
2. NFS můžete autorizovat, ale musel byste zakázat podporu starších verzí protokolu. Jak jsem psal, nevím jestli to lze udělat, ale zato vím, že to nikdo nedělá. Ochrana na IP adresu je na nic, to určitě víte sám. A zřizovat VPN kvůli síťovému spojení, to je vtip? Je mi líto, ale Windows řešily už v době první verze NT sdílení souboru daleko bezpečněji.
3. Pokud POSIX vyžaduje case sensitive file system, a Windows mají case insensitive názvy souborů (což bylo design decision), tak je to jediné řešení. Vzhledem k tomu, že POSIX aplikace stejně nemohou volat Win32 API (a opačně), dá se předpokládat, že půjde o oddělené světy. Nakonec jak jsem už psal, nikdy nikdo nezamýšlel používat PISIX subsystém ve Windows na cokoliv mimo migrace z unixů.
4. Mě se to také nechce zkoušet, ale předpokládám, že by to mělo jít.

Telnet posílá heslo jako plain text, což je nezabezpečené. V době uvedení NT bylo používání telentu zcela běžné; dnes pravda spíše výjimečné. NFS nevyžaduje autorizaci, a v době uvedení Windows NT jí neumělo.

Autorizaci samozřejmě potřebujete. Nechcete mít v serverovně terminál s promptem, bez hesla, protože je to přece serverovna?

Ano, POSIX certifikaceje o testech. Samozřejmě není problém ty testy změnit tak, aby neprošel žádný systém. O změně testů tak, aby Windows nemohly projít, se samozřejmě uvažovalo. A to ve chvíli, kdy MS začal usilovat o certifkaci Windows NT. Pěkné, že?

POSIX aplikace ve Windows mohou určitě pouštět Win32 binárky. Jestli mohou linkovat Win32 knihovny, to nevím, a teď to hledat nebudu.

Tak to sem zkuste hodit, abych se dozvěděl, o čem jsem to vlastně lhal :)

"POSIX aplikace ve Windows mohou určitě pouštět Win32 binárky. Jestli mohou linkovat Win32 knihovny, to nevím, a teď to hledat nebudu."

Kde je ta lež?

Ony to samozřejmě oddělené světy jsou. POSIX subsystém je ve Windows jen kvůli usnadnění přechodu z unixů, a využívá ho minimum zákazníků. A že by někdo linkoval z POSIX kódu Win32 knihovny (které používají odlišné datový typy, Unicode UTF-16 stringy, odlišnou konvenci názvů souborů atd), to je možná technicky možné, ale v praxi dost nepravděpodobné.

A ano, přiznávám, že jsem nevěděl, že POSIX aplikace běžící na Windows může volat Win32 API. Víte ale, jak vypadá lež? Jedná se o vědomně nepravdivý výrok. Kdybych měl každou neznalost zdejších diskutujících nálepkovat jako lež, nedělám asi nic jiného.

Samozřejmě pokud Posix Certification Test Suite testuje API utility, tak stačí testovat API či utility nepopsané v POSIXu, a je vymalováno. Je celkem logické že změna testu vede ke změně výsledků, ale je to dost o ničem.

Říkal kdo, na základě čeho? Systém buď je POSIX compliant, nebo není. Pokud změníte testy, mohou se pochopitelně změnit jejich výsledky.

Ten test je rozhodujícím kritériem. Vyjma toho jde ještě o dokumentaci. Například pokud máte funkce libc definované odlišně, než vyžaduje Single UNIX Specification, máte také smůlu. Pokud jde o technické detaily testu, já je neznám; zkuste si je dohledat.

Těmi základními věcmi máte na mysli dokumentaci funkcí libc, jejich implementaci, a implementaci utilit? Pokud se na takové základní věci nemusel soustředit, na co se tedy soustředit musel? :)

Jenze prechodem z XP na Vista uzivatel moc neziska, krome toho, ze je to prezrane spinave a line prase, nacpane DRM technologiemi, ktere uzivateli prinesou akorat problemy a zpomaleni systemu. Prechodem z Win 9x na NT a vyssi uzivatel vymenil nepovedenou herni konzoli za opravdovy OS. O jeho kvalitach lze vest polemiku, ale je to prece jenom OS s vecmi, ktere u OS jsou dobrym zvykem a s mnohem lepsi stabilitou a to za nejake ty problemy stoji. Prechod na Vista se urychli asi az jen tehdy, kdyz nebude podpora pro XP a nebude je mozno jiz ani koupit. Pri vydani NT Microsoft propasl jedinecnou prilezitost namalovat tlustou caru za prasackou minulosti a zkusit to udelat lepe.

Přechodem z Win2K na Vistu také uživatel moc nezískal. Osobně nevidím důvod, proč by měli uživatelé upgradovat z XP na Vistu. Vista je stavěná na nový HW. S novým počítačem nový OS. Kdo má opravdu výkonný stroj, a chce upgradovat, proč ne. Bude to ale poměrně malé procento uživatelů.

Vistu používám na desktopu asi půl roku. S rychlostí nemám jediný problém, spíše jsem naopak velmi spokojený. DRM technologie se vás týkají jen a pouze pokud přehráváte obsah chráněný DRM, k čemuž jsem zatím nenašel důvod (ale znáte to, ta možnost výběru se počítá). Technologie DRM jsou ve Windows už tuším od Win98. Ve Vistě jsou o něco pokročilejší, ale koho to trápí? Tedy vyjma FUDařů, kteří tvrdí cosi o tom, jak DRM zpomaluje systém, jak díky němu doktoři neuvidí RTG snímky apod :)

Nevím, kde MS udělal co "prasácky". MS-DOS byl systém pro levný desktopový HW, a měl designová omezení vyplývající z jeho určení a z typu HW. Windows 9x byly přechodem k řadě NT, a jak jste si mohl všimnout, měly API kompatibilní s NT. NT mají velmi dobrý návrh.

Já bych zase řekl, že když Linus v devadesátých letech začal psát Linux, měl možnost napsat systém typu MacOS. Tedy použít unixové základy, kde nebylo lze jinak, a ty technicky rozvinout. Místo toho napsal opis unixů ze 70. let, s nepreemptivním kernelem (viz Big Kernel Lock), primitivním FS, schedulerem bez podpory threadingu, a spoustou nevyřešených problémů. Takhle to vypadá absence designu.
Výsledek? Po 18 letech je kernel preemptivní pouze v experimentálním módu, který vývojáři kernelu nedoporučují používat. FS existuje dlouhá řada, některé mají i funkční tools, ale žádný se nelepí svými možnostmi na běžnou konkurenci. Threading byl dopatlán, a výsledné Linuxthreads byly jednou z nejhorších implementací vůbec. Teprve po 12 letech, v kernelu 2.6, byl uveden threading NPTL, který je sice také dobastlený nad process model, ale alespoň funguje. Některé další "lahůdky", typu předpotopních device nodes, se po dlouhých letech podařilo trochu uhladit použitím udev; jiné, typu terminálů a X11, čekají na řešení.
A proč to všechno? Dovedu pochopit, že MS-DOS musel vypadat, jak vypadal, díky HW a určení. Dovedu pochopit, že Win95 musely běžet na 4MB RAM, a být kompatibilní s DOSem včetně device driverů, takže tomu odpovídal design. Ale proč proboha Linux? Vždyť stačilo plánovat, přemýšlet, a dělat více designu, než jen přepisovat unixy sedmdesátých let.

Jenže většina z nás ví, že ZFS na Linuxu není (resp. je přes FUSE, což se z pochopitelných důvodů nepočítá). ZFS je pěkný FS, a Sun ho potřeboval jako sůl, protože ten UFS byl příšerný (zákazníci museli vyjma Sun HW kupovat ještě Veritas FS, který je vyšel i stejně draho, jako licence Windows Serveru). Problémem ZFS je jeho náročnost (average case je prostě pomalý), a to, že se snaží suplovat funkcionalitu storage. Na běžný FS můžete použít například RAID controller, který bude počítat paritu, a tedy mít zajímavý výkon. ZFS ale počítá paritu sám, a neumí to offloadovat na HW. Nakonec proto se na ZFS neběží třeba databáze. Podotýkám, že se od prvního uvedení ZFS mohlo něco změnit, já to zase tolik nesleduji.

na ZFS se neprovozuji narocnejsi databaze kvuli COW pri zapisu - efektivne to totiz zrusi moznost clusterovat tabulky, coz u warehouse aplikaci posle vykon k zemi.

Ano, tzv. urban legend ;). Za návrhem Windows NT stojí částečně David Neil Cutler a pár jeho kolegů. Samozřejmě když píšete nový OS, musíte mít vhodného architekta. A to by měl být někdo, kdo v oboru už dělal (aby to nedopadlo jako Linux). Cutlerovi zrušili projekt v Digitalu, tak šel do MS. A nutno říci, že odvedl skvělou práci. Možná se to zpočátku nezdálo (NT se díky HW náročnosti neprosadily až tak rychle), ale čas to ukázal.

Na těch 286-kách běžel DOS, a běžely na nich i Windows. Na tehdejších unixech jste si mohl v grafice leda spustit xclock, a zabít tím celý stroj, který stál o řád více, než tehdejší PC. Navíc u 286ky nebylo technicky možné provozovat správu paměti, a zároveň real mode aplikace (což bylo pro kompatibilitu s DOSem veli důležité). Jistě víte, jak se na 286 prováděl exit z protected mode. Kdyby ne, tak připomenu: uložily se registry, nastavil flag, a pomocí řadiče klávesnice se resetoval procesor. BIOS pak na začátku POST zajistil, že jde o exit z protected mode, a předal řízení real mode aplikaci. Ne, to fakt nebylo dobré.

XFS je celkem pěkný. Problém je, že klíčové části (řízení priority I/O, rezervace přenosového pásma) byly odstraněny při portování na Linux. Zpočátku tuším také nebyly funkční utility. Mít FS, a nemít k němu funkční fsck, to není nic moc.

1. Vývojáři MS píší SW tak, aby plnil zákazníkovy potřeby tak dobře, že je ochoten za ten SW zaplatit. Jejich SW je tak úspěšný, že na desktopech běží na 95+% strojů, a velikém procentu serverů (tam se špatně schánějí konkrétní procenta).
Vývojáři *BSD píší SW tak, aby si připadali fakt dobří. Jejich SW se přes nulovou cenu na desktopu prakticky nepoužívá, a i na serverech je poměrně exotický (vyjma jistého zastoupení na internetu).
Kdo myslíte, že dělá lepší job pro uživatele? Za sebe v tom mám jasno.
No a ještě detail. MS uvedl .NET Framework, což je velmi vydařené prostředí. Managed jazyk, tedy méně chyb při psaní kódu, a v runtime výjimky, oproti C/C++ náchylnému na chyby programátora, kde v runtime po chybě typicky dochází k rozsypání paměti aplikace (nepredikovatelné následky chyby). Dále má MS na skladě kernel psaný v .NETu, který povede k dramatckému zvýšení spolehlivosti a stability SW. Co nového přináší pánové ve světě open source?

2. Ano, ztratil jsem nit. Zkuste se prosím nějak podepisovat. Klidně se podepisujte qwerty, hlavně když budu vědět, že mluvím s člověkem, který psal to či ono.
DOS byl původně psaný pro CPU 8086/8088. Jeho výhodou byla mimo jiné kompatibilita API s CP/M. To přinášelo snadné portování SW z CP/M, a spoustu vývojářů. PC od IBM se samozřejmě dodávaly i s unixy. Nakonec Microsoft měl vlastní unix, konkrétně Xenix. Ten byl údajně v době DOSu unixem s největším počtem instalací na světě. Nicméně unixy se na PC neujaly.

3. XFS už má dnes nejspíš fsck bez problému. Jen si vzpomínám, že zpočátku nebyly utilities kompletní. Poškození FS je sice věc poměrně vzácná, ale nástroj pro ověření a opravu FS je celkem zásadní věc.

1. Ano ja si taky vybral ;-) Jinak s tim, co je pouzivane a co ne na serverech bych byl opatrnejsi - odkud je OpenSSH? A nepouzil nahodou MS z BSD sitovy stack? (na todle se opravdu ptam, kdyz budete souhlasit, nebudu se to pokouset najit). Prepisovat unixove kernely do nejakeho vyssiho jazyka imo potreba neni. Ze by byl problem v kernelu se stava vyjimecne (treba i u linuxu staci nasazovat starsi proverena jadra), jestli mate i unixy, tak schvalne napiste, kdy vam naposled nejaky padnul kvuli jadre. Na unixech je vyssi programovaci jazyk uz dlouha leta PERL. I kdyz ho dost lidi nema rado, mne se s nim dela dobre.

2. Neodpovedel jste, jestli se vam libi, jak nas MS zamknul k te debilni x86.

3. Ano, dnes je XFS bezproblemu, tazke to tvrzeni o spatnych fs v linuxu bylo zbytecne, ne?

1. MS koupil TCP stack pro NT od Spider Systems (SpiderTCP). Ten byl založený na BSD zdrojácích, ale jeho výkon nebyl nic moc. V NT 3.5 ho MS ho nahradil doma napsaným stackem.
http://www.kuro5hin.org/?op=displaystory;sid=2001/6/19/05641/7357

Kernely má smysl přepisovat do vyššího jazyka, stejně jako frameworky a aplikace. Vy jste to možná nečetl, ale já jsem tu několikrát psal v jiných diskuzích, že použití managed jazyka umožňuje model checking. V důsledku můžete už z bytecode prokázat, že daný kód v žádném případě nevolá jiné než dané funkce, že v žádném případě nezapíše mimo svůj stavový prostor, nebo že v kódu nemůže dojít k deadlocku. To v jazyce C/C++ uděláte těžko, protože u velké spousta operací nejste schopen stanovit, co vlastně ovlivní. Například prostá funkce strcpy může překopírovat string, stejně jako přepsat hromadu proměnných, nebo dokonce hrábnout mimo adresní prostor aplikace a tím jí efektivně ukončit. Každý pointer může vést k podobným problémům. Teprve pokud je jazyk lépe stavěný, lze se přestat dohadovat, a začít něco dokazovat.
Asi se vám to nebude líbit, ale PERL považuji za příšernost. Chápu, že jedincům odkojeným unixem může připadat i intuitivní. Já když vidím kód psaný v PERLu, tak si říkám "proboha, nezasekl se autorovi na klávesnici SHIFT?"

2. MS uvedl Windows NT pro x86, DEC Alpha, MIPS a PowerPC. Pro další platformy není problém NT portovat (mají například Hardware Abstraction Layer, takže to neskončí hromadou ifdefů, ale čistým designem). Problém je v tom, že ne-Intel HW má mizerný poměr cena/výkon, a není pro něj SW. Druhý pokus o útěk od x86 nastal s příchodem 64 bitů. MS uvedl Windows pro architekturu IA64, která je proti x86 velmi pokroková. Jenže při běhu stávajících x86 aplikací (ano, první Itanium umělo běžet x86 kód) nebyl výkon nic moc, a pak přišel AMD FUD stylu "na tom neběží vaše dnešní aplikace", uvedení x86-64... No a jsme tam, kde jsme. S x86-cokoliv na věčné časy. Může za to MS? Nemyslím.
Ono nakonec nehraje takovou roli, která platforma je dominantní. Mohlo by to být třeba PowerPC. Faktem je, že na trhu je místo pro jednu širokou HW platformu (což přináší velké výhody), a par menších platforem pro speciality.

3. Ano, XFS je bez problémů. Ovšem nemá features, které má NTFS. Otázka byla, jestli má smysl mít hromadu napůl-FS, které umí každý něco (jeden má žurnál, další umí ACL, jiný umí kompresi ale už ne ACL, jiný lze použít s NFS), a proč neudělat jeden pořádný. Samozřejmě udělat pořádný FS je daleko více práce, než napsat ext3, nebo naportovat XFS na Linux. Ale když si uvážíte množství práce strávené nad všemi těmi FS pro Linux, tak by se to snad vyplatilo.
Upozorňuji, že ve Windows není problém implementovat nový FS. Jenom to běžně není třeba, protože NTFS prostě umí, co je třeba. Přesto můžete najít implementace ext2/3, rfs atd. Jsou pochopitelně určené pro čtení disků zapsaných v Linuxu; k použití ext2/3 nebo rfs ve Windows není důvod.

1. Kdyz jsem s PERLem zacinal, tak se mi moc nelibil. Ale ted je to genialni, kdyz chci neco napsat, tak se to dela presne tak, jak by se to delalo v jazyce, ktery bych vymyslel ja :-) A z kodu, co v tom napisu, mam radost.

2. IA64 neumel v prvnich verzich virtualizaci, coz u CPU pro servery je ostuda. Platforma x86 je strasna, srovnejte vykon s GPU, u kterych se nemusi zpetne drzet takova kompatibilita. AMD ten FUD mohl vyvolat jen diky MS, protoze ostatni systemy na tu platformu tolik vazane nejsou.

3. Rekl bych (v teto casti jadra se moc nehrabu), ze ACL jsou implementovany tak, ze staci, aby FS nabidnul prostor pro ulozeni nejake informace s kazdym inodem a ACL tak ziska "zadarmo". Kazdopadne u XFS funguje NFS, ACL a ma zurnal. Stejne jako u ostatni nejrozsirenejsi FS a to uz pekne dlouho. Ja jsem spis ted zvedavy na novy ext4 a reiserfs, protoze to, co predvadi v testech, vypada velmi zajimave. NTFS ma problemy s obrovskymi adresari.

1. Tomu se říká nechat se přiohnout. Když budete rok mastit věci v ASM, zřejmě vám to pak také bude připadat v pohodě. Uživatelé unixu dokonce mnohdy nedají fopustit na takovou příšernost, jakou bezesporu je editor vi.

2. Platfroma x86 v té době virtualizaci také neuměla. Nikdo nevěděl, že virtualizace bude důležitá. O kousek později bylo pochybení napraveno.
Nemůžete srovnávat výkon general purpose CPU s GPU. To není o kompatibilitě, ale o typu prováděných operací. GPU toho umí velmi málo.
Windows nejsou samy o sobě vázané na platformu. Na platformu jsou vázané aplikace.

3. XFS opravdu umí ACL, má žurnál, a funguje na něm NFS. Dokonce má i quoty. Kdyby uměl kompresi, šifrování, ukládal názvy v Unicode, uměl Alternate Data Streams, byl byl NTFS zase o něco blíže.
Každý FS má nějaké limity. Pokud mluvíte o milionu souborů v jednom adresáři, to je konstrukce, která se prakticky nikdy nepoužívá. Na unixech se také typicky používá několik úrovní podadresářů. A už jsem tu popisoval problémy, které jsem viděl u IBM JFS (FS opakovaně kolaboval při zaplnění malými soubory, support IBM jen doporučil používat více menších FS).

Mě taky přijde, že šifrování není dobré řešit přímo na úrovni souborového systému. Šifrovat pod ním (na úrovni block-device) nebo nad ním mi obojí přijde jako lepší nápad. Ze stejného důvodu tady někdo kritizoval ZFS, že se snaží řešit i věci, které by se efektivněji a pružněji daly řešit jinde.

Mě zase připadá, že při implementaci na úrovni block device budete těžko šifrovat jen vybrané soubory, nebo dokonce různé soubory různými klíči.

EFS je technicky postavené nad NTFS. Soubor je na NTFS v zašifrovaném stavu, a při průchodu filtrem se dekóduje (pro aplikaci je to samozřejmě transparentní). Implementace není čistým filter driverem, který by bylo možné nasadit třeba nad extX nebo VFAT, ale je modulární. Lze EFS odstranit, lze jej nahradit vlastní komponentou, lze obdobný filter driver implementovat nad libovolný jiný FS.

Mezi kritiky ZFS se počítám i já, ale jak vidíte výše, tohle je trochu jiná záležitost.

1. Tezko, v ASM jsem programoval a nelibilo se mi to (ve smyslu, ze me to neoslnilo). Vi spatne neni, kdyz ho umite. Videl jsem pri praci programatora, co mistrne pouziva vim a jeho navigace a prace s kodem byla ve srovnani s dnes oblibenymi nastroji (eclipse, visual studio) neskutecne rychla. Ja vi take celkem bezne pouzivam, ale k dokonalosti v ovladani mam jeste daleko.

2. Ano, ale az pozdeji. Pritom ne x86 serverove platformy virtualizaci bezne umely. To srovnani jsem myslel spise tak, abyste porovnal vykon/cena GPU a CPU pred 15 lety a dnes. Windows platformove vazane jsou, protoze se dodavaji jen pro x86 (32/64b verze). Vynechme CE, ty jsou na neco jineho.

3. Sifrovani atd.. se na linuxu resi na jine vrstve - v device mapperu. Vyhodou je, ze ty vlastnosti jsou pak nezavisle na FS. Nazvy muzete ukladat v cem chcete, to je take jina vrstva ;-)
Hodne souboru v adresari mate napriklad u maildiru. Na to, aby ten vykonovy rozdil byl znat, ale staci i radove mene nez milion.

1. Vi je špatné, protože musíte znát konkrétní příkaz, kterým danou věc uděláte. Když příkaz neznáte, máte smůlu (podobně jako na konzoli). Naopak v GUI vidíte možnosti nabídnuté před sebou. Když potřebujete zakomentovat blok, a nevíte jak, v GUI se podíváte. Najdete to v Edit/Advanced/Comment Selection. A až tam budete v jednom dni potřetí, zřejmě si zapamatujete, že je u položky menu napsáno CTRL+E,C. Ve výsledku vždy najdete všechno bez memorování, a ty věci, které se vám vyplatí naučit (protože je děláte často) uděláte rychle z klávesnice. Ve vi buď víte rovnou, nebo máte smůlu.

Další věcí, kterou vi ani vim nenabízí, je IntelliSense (doplňování klíčových slov, jmen proměnných, tříd, metod, vlatností), zobrazování tooltipu s parametry funkcí a metod a jejich overloadů, integrovaný debugger atd. Ve vimu lze sice použít ctags, ale porovnání s možnostmi IntelliSense je dost neradostné.

2. Itanium má HW podporovanou virtualizaci od roku 2006, x86 (Intel) má Vanderpool od podzimu 2005.
Jak jsem psal, Windows se dodávaly pro více platforem, a bylo by to možné i dnes. Problém je, že se Windows pro jiné architektury neuchytily. Podpora platfromy na úrovni vývoje, distribuce, supportu atd. je celkem drahá záležitost, a ne-Intel Windows prostě trh nechce.

3. S dovolením EFS na NTFS je o něčem jiném, než šifrování na úrovni blokového zařízení. Na disku můžete mít šifrované i nešifrované soubory, a každý šifrovaný soubor může mít odlišný klíč. Klíč uživatele je zamknutý jeho přihlašovacím heslem, uložený v uživatelském profilu či v ActiveDirectory. Efektivně to znamená, že ani administrátor se k souboru nedostane (pokud není definovaný jako recovery agent již před šifrováním souboru).
Ve Windows můžete také implementovat filter drivery. Je tak řešená komprese na NTFS, nebo on-access antiviry.
http://searchwincomputing.techtarget.com/digitalguide/images/Misc/naik_2.gif

Hodně souborů v maildiru na Windows mít nemůžete, protože Exchange i Lotus Notes používají objektovou databázi na serveru i na klientech (serverová DB Exchange obsahuje miliony či desítky milionů objektů). To je o 20-30 let novější přístup k designu ;). K výkonu NTFS při milionech souborů v jednom adresáři se tedy nemohu vyjádřit. Jistou ztrátu výkonu při nárůstu počtu souborů je ale možné předpokládat (podobně jako u DB), protože hledání má složitost O(log n), a nikoliv O(1)

Exchange a Lotus Notes používají objektovou databázi? Nad relační databází nebo čistě objektovou?

A je to vůbec výhoda? Určitě je to novější technologie, o tom žádná :-), ale je to opravdu v tomto případě přínos oproti relační databázi?

Exchange i LN. Ovšem LN neznám tak dobře, takže budu mluvit o MS Exchange. DB Exchange je objektová. Máte tam kontejnery (mailboxy, adresáře), každý objekt může mít hromady vlastností (email v html, email v plain textu, subject, datum odeslání atd).
Je pochopitelně možné vyhledávat podle kritérií.

Relační DB by šlo v principu také použít (řada CMS a DMS systémů jede na DB), ale nemyslím, že by nutně dávala lepší výsledky. Objektová DB je lehce vhodnější abstrakce, protože zatím co tabulka má (pro zjednodušení) pevně dané sloupce, objektová DB vám umožní uložit k objektu jakoukoliv vlastnost. Navíc je na rozdíl od relační DB optimalizovaná pro práci s BLOBy.

Viděl jsem Notepad ve Windows. Vytknul byste něco jeho uživatelskému interfacu? Ano, je to jednoduchý editor, a spoustu věcí neumí. Pochopitelně editor Visual Studia nebo UltraEdit umí daleko více. Ale ani jeden jmenovaný editor nemá tak příšerný interface, jako vi. Interface, kde uživatel musí znát příkazy zpaměti, a který nemá vizuální odezvu, je špatný. Takový jednoduchý edit.com pro DOS ukazuje, že i ve znakovém režimu lze napsat použitelný interface.

Nejsem lama. Jenom vím, jak vypadá špatný uživatelský interface. Víte to vy?

Programátoři nezpracovávají kvanta textu, ale zdrojové kódy. Kupodivu to typicky dělají v IDE, za podpory produktů pro source control and project lifecycle management. Osobně jsem ještě neviděl jediného člověka pracujícího na větším projektu, který by používal vi(m) namísto IDE. Ať si o programátorech myslíme cokoliv, nejsou tak úplně sebevrazi ;)

Zásady pro tvorbu uživatelského interface jsou stejné, ať tvoříte interface pro managera, programátora, nebo administrátora. Požadavky na konkrétní interface se samozřejmě mohou lišit. Nicméně si neumím představit, že by někdo řekl, že požadavkem na interface pro programátora je:
- aby se s ním musel co nejdéle učit zacházet,
- aby neměl vizuální odezvu svých akcí,
- aby mohl používat jen ty akce pro které si pamatuje příkaz,
- aby mu interface nepomáhal doplňováním klíčových slov, jmen proměnných, tříd, metod, vlatností, zobrazování tooltipu s parametry funkcí a metod a jejich overloadů atd.

Možná vy vidíte nějaký důvod, proč by programátoři neměli mít možnosti, které jim nabízí GUI. Většina světa se na to ale dívá výrazně odlišně.

Možné máte pravdy, a na UI jsou různé požadavky. Možná právě proto máme na jedné UI řešící interakci lidí s počítači, a na druhé příšernosti typu vi. Viz kritéria, která jsem popsal v minulém příspěvku.

Jenom dotaz: Windows NT 4.0 měly preemptivní jádro? Netvrdím, že ne, nevím, ale opravdu by mě to zajímalo.

A možná se spíš diskutovalo o reentrantnosti než o preemptivnosti. Tak bych se zeptal i na tu reentrantnost.

Windows NT mají už v návrhu preemptivní a reentrantní jádro, threading apod. Nebyly totiž designovány v šedesátých letech, ani nejsou přepisem UNIXu (byť je samozřejmě mnoho věcí řešených podobně, jako na unixech či dalších systémech).

Jo, to souhlasím, že v takovém případě je to výhoda a Windows měly náskok. Nevypovídá to ale mnoho o současném stavu.

To, že něco není navrženo s ohledem na nějaký aspekt ještě neznamená, že to není možné změnit, použit se z chyb ostatních a nakonec to navrhnout lépe než v systému, kde to bylo od začátku. To je jenom obecná poznámka, nesrovnávám Linux a Windows, neboť Windows moc nerozumím.

Samozřejmě řadu věcí není možné vyloučit.

Současný stav je takový, že Linux plně preemptivní kernel fakticky nemá. V jádru je identifikováno několik míst, kde se preempce provádí. Teoreticky lze zapnout plnou preempci kernelu, ale není to dobrý nápad. Když se totiž kernel psal, s preempcí se nepočítalo. Když jí dnes zapnete, bude výkon nižší než bez preempce, a stabilita jádra bude velmi špatná. Vývojáři kernelu doporučují používat preemptivní kernel jen pro ladění (aby člověk zjistil, kde někdo zapomněl něco zamknout), a běžná distra jedou bez preempce. Jak vidíte, současný stav po 17 letech není pořád nic moc.

mne tedy jede v db workloadech preemtivni linux kernel dost rychleji. Pravda, je znacne nestabilni pouzivat se to neda. takze prakticky vzato vlastne preemtivni neni.

Jo, to souhlasím, že v takovém případě je to výhoda a Windows měly náskok. Nevypovídá to ale mnoho o současném stavu.

To, že něco není navrženo s ohledem na nějaký aspekt ještě neznamená, že to není možné změnit, použit se z chyb ostatních a nakonec to navrhnout lépe než v systému, kde to bylo od začátku. To je jenom obecná poznámka, nesrovnávám Linux a Windows, neboť Windows moc nerozumím.

Dělat systém kompatibilní s jiným není to samé, jako ho opsat.

Přišli některé výraznější změny (k lepšímu) a už je často oheň na střeše a na Vistu se čtí v diskusích oheň a síra.

Změny přišly, jsouce, či případně byvše (to podle toho, zda mluvíme o změnách obecně, či o těch konkrétních v minulosti) rodu ženského. Ale víc mě pobavilo slovo "čtí", svědčící o tom, jak si autor "nevidí do huby", a cosi píše, nepřemýšleje ani zbla o tom, co použitá slova vůbec znamenají. Slovo "dštíti" má svůj základ a původ ve slově "déšť", pane Přemysle...

To by mě zajímalo, ve kterých věcech jsou Windows zbastlené ;)

Ano, autoři aplikací mají šílené návyky. Na tom se shodneme.

Windows řady NT s každou další verzí utahují permissions. Windows 2000 měly být mainstreamem pro přechod z Windows 9x, takže na některých místech permissions nebyly by default takové, jak by si člověk představoval. Ovšem od toho jsou security templates - nikdo vás nenutí používat default (když vám nevadí, že pak spousta aplikací nepůjde).

Programy pro MS-DOS ve Windows běží v emulaci. Mají standardně práva uživatele, a nevyžadují více práv, než jiné aplikace.

Proč velká část programů pro Win standardní pravidla nedodržuje a programy pro Uni*y ano (včetně MacOS X)? Na to mám dvě dobré odpovědi. 1) Pro Windows je obrovská spousta aplikací. Neexistuje žádná autorita, která by autorům zakázala dělat prasárny. Jsou sice psané guidelines pro vývoj aplikací, ale jejich dodržování je dobrovolné. I dobrovolný certifikační program pro HW a SW většina čtenářů root.cz považuje div ne za fašismus, protože svoboda, svoboda, tučňák. Zkuste jim to vysvětlit, až se o věci bude mluvit. 2) Jste si jistý, že aplikace pro unixy a MacOS dodržují pravidla? Já o tom zdaleka nejsem přesvědčen. Třeba řada aplikací pro unixy se nepopere s dlouhými názvy adresářů. Zkuste nainstalovat Oracle do adresáře "/můj adresář/Oracle 10Í". Nebo si založte uživatele "František". Podívejte se také, jakým způsobem aplikace tisknou. Nevím, jak je to dnes, ale svého času aplikace používaly často vlastní drivery tiskárny (zvlášť pokud šlo o barevný tisk, který byl jinak prakticky nepoužitelný). Unixy používám jen v sebeobraně, ale nepřipadá mi, že by na tom tamní aplikace byly zvláště dobře.

Kdyby Windows měly horší zpětnou kompatibilitu, výrazně by se to odrazilo na rychlosti (resp. pomalosti) přechodu na novou verzi. Chápejte, že zatím co pro Linux existuje pár aplikací, které jsou převážně přiložené rovnou na DVD, pro Windows je jich o pár řádů více. Skoro každý máme svou obskurní aplikaci, kterou potřebujeme. Řada firem dodnes jede SW psaný pro DOS, nebo pro Windows 9x. Dostupnost aplikací, a zpětná kompatibilita, to je obojí obrovská deviza.

Nakonec když se podíváte, jak tahle diskuze začala, tak si čtenář X stěžoval, že ve Vistě mu řada aplikací neběží. Na koho si stěžoval (nakonec nejen on)? Na své současné aplikace (které v XP bez problému běží), nebo na Vistu? Posuďte sám.

Na prnvím místě si netykáme.

Dávkové soubory .bat jsou ve Windows pro kompatibilitu s DOSem. A stejně jako v DOSu používají OEM code page, takže je musíte v této CP uložit (File/Save as, vyberte OEM code page). Je to nejlepší možné řešení zpětné kompatibility.

S tím převodem na 8.3 názvy tomu nějak nerozumím. Jak by mělo být zaručené pořadí? Pokud se souboru nemění dlouhé jméno, zůstává 8.3 jméno stejné. Pokud se změní dlouhé jméno, může se změnit i 8.3 jméno. Nic jiného není zaručeno, a spoléhat na to je prasárna.

K testu: zkuste si totéž na Linuxu :)

Hm, s tiskárnami máme odlišné zkušenosti. Mě Qt a GTK aplikace používají jiné dialogy, a OpenOffice ještě jiné :). No a Gimp-Print byla svého času jediná cesta, jak vytisknout něco na barevné tiskárně tak, aby to barevně alespoň trochu odpovídalo.

Dvě zařízení stejného typu připojená do jiných portů jsou různými zařízeními. Oceníte to, když budete mít jakákoliv dvě zařízení stejného typu. Ale to vám nedošlo, že?

Ne, on si stěžoval na to, že mu nejdou některé aplikace, které jdou ve Vistě. To pouze vy blábolíte něco o posunu ke standardu unixů 70. let. Nebo si myslíte, že popsané problémy (určení cesty k adresáři My Documents v rozporu s SDK, vykrádání ikon a animací z knihoven shellu, použití zobrazení kontextového menu a aktivace páté položky od konce namísto pouužití API) vyřešíte posunem k systému s textovým interfacem, plain text hesly, nepreemptivním kernelem, bez podpory GUI, grafiky a multimédií? :) Viz též http://www.root.cz/zpravicky/preference-vyvojaru-podle-os/211515/

PS: Co máte za problém s Cyberduck.app/Contents/Resources/zh_TW.lproj/Transfer.nib? Jde o adresář autora nějaké aplikace, a je jeho věc, jak si ho dál dělí do podadresářů. Jestli mu do toho chcete moudře promlouvat, obraťte se na něj. Upozorňuji ale, že adresáře s daty aplikací nejsou na počítači proto, aby uživateli připadaly jejich názvy estetické :)

Ty jsi s tím vykáním fakt veselý týpek :)

Např. pokud vím, tak USB zařízení musí mít dle standardu rozdílná ID (sériová čísla nebo tak něco), čím se v USB sběrnici identifikují. Takže dvě úplně stejná zařízení byste mít neměl.

Pokud já vím, tak mají device ID, což je ale jen model zařízení. Konkrétní zařízení je tedy určeno sběrnicí, portem na sběrnici, a ID zařízení.

Nevim, jak to u USB zarizeni je obecne, ale treba:
Philips webcam
Serial Number: 016800006CF10001
Speed: 12Mb/s (full)
USB Version: 1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Vendor Id: 0471
Product Id: 0311
Revision Number: 0.03
(............)

Solid state disk
Manufacturer: USB
Serial Number: 20731BE33E6B1890
Speed: 12Mb/s (full)
USB Version: 1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 0ea0
Product Id: 6803
Revision Number: 1.00
(..............)

Cili u dvou zarizeni, ktere se mi tu vali, je seriove cislo. Kdyz se to zkombinuje se vselijakymi temi vendor id, product id, device class a co ja vim, vznikne tim identifikator, ktery, myslim, muzeme povazovat za jednoznacny. To pro pripad, ze by existovalo riziko vyskytu dvou zarizeni od ruznych vyrobcu se stejnym seriovym cislem. Nevim, jestli vyrobci maji prideleny rozsahy cisel podobne, jako treba vyrobci NIC pro MAC adresy. Rekl bych, ze mlzite za ucelem obhajoby nedodelku Microsoftu. BTW, nedavno jsem prendal mys z jednoho USB portu do druheho na Win 2000. Musel jsem se prihlasit jako admin a nechat mys znovu nainstalovat, dokonce se i prokousat nejakym dialogem, ktery snad chtel i lezt na Windows update, prestoze driver na tu mys jiz mel na disku (z Windows update). A ne, nejedna se o mys nejakeho blbeho vyrobce z Tramtarie, ktery neumi udelat korektni mys. Je to microsofti mys.

USB specification does not require a hard coded serial number as mandatory for USB devices
Co řeknete teď? Navíc nejde jen o USB zařízení. Jde i o grafické karty, zvukové karty, a jakákoliv další zařízení. Pokud rozeznáváte zařízení jen podle typu (protože serial number prostě nemají), a nikoliv podle lokace na sběrnici, zaděláváte si na velký problém, pokud budete mít v systému více zařízení stejného typu. Pokud mě paměť neklame, dvě zařízení stejného typu byl v Linuxu vždy problém.

MS myši mají v některých případech specifické drivery. Já mám například myš MS Habu, která chce driver z Windows Update.

Ano, není to specifikováno jako povinné, ale právě jsem udělal testy a pouze Logitech a Genius myši neměly sériové číslo. I USB čtečka karet a flashdisky (Kingston) měly unikátní sériové číslo.

Jinak lze se samozřejmě zařízení na USB, PCI, PCI-Express a dalších sběrnicích identifikovat podle umístění na sběrnici.

Např. když se podíváte do konfigurace XWindows, tak možná uvidíte, že vaše grafická karta je identifikována číslem sběrnice i polohou na sběrnici (viz parametr BusID). Ten se vám, pokud vím, změní, když kartu přesunete z jednoho slotu do druhého. Dřív tam byl implicitně, dnes se možná právě z tohoto důvodu implicitně nezadává. Není problém si ho ale v případě existence dvou karet doplnit (je možné, že v takovém případě si ho doplní sám).

To samé platí i např. pro scannery. Tam se také uvádí ID na sběrnici. Myslím si, že i v něm je zakódována poloha zařízení, i když si v tomto případě nejsem zcela jistý.

Je vcelku jedno, jestli to či ono zařízení má sériové číslo. Většina sběrnic nepodporuje sériová čísla, často sériová čísla bývají duplicitní (kdo asi tak spravuje number ranges?), a konzistentní přístup ke všem zařízením je pouze správný. Jestli si nedokážete zapamatovat, do kterého portu zařízení strkáte, holt se při přehození do jiného portu reinstaluje driver.

Ve Windows se vám samozřejmě při přesunu zařízení ze slotu do slotu také změní umístění na sběrnci. A to proto, že staré zařízení bude odinstalováno, a nové nainstalováno (takže "nová" grafická karta možná bude mít jiné rozlišení). Instalaci dvou zařízení stejného typu samozřejmě musí podporovat systém, a ne uživatel tím, že bude lézt po konfigurácích, a hrabat se v nich.

Ano, to je v pořádku. Když odpojíte zařízení z jednoho portu, a připojíte k jinému portu, staré zaříení se odebere, a nové přidá. To nové zařízení můe mít pochopitelně odlišné nastavení. Jestli (a jak) mizí tiskárny HP, to fakt netuším.

Instalace zařízení je věcí na pár sekund, takže to není problém.

Mě zase připadá, že MS má dobře a konzistentně koncipovanou správu zařízení. Ale celý problém, který tu někdo zmiňoval, byl nakonec zřejmě o tom, že při odstranění tiskárny z USB portu se neodinstalovala (a při připojení do jiného portu měl tiskárny dvě). Při troše smůly to může být driverem, nebo tím, že je tiskárna nasdílená.

Zkuste se chovat méně jako idiot. Prospěje to úrovni dikuze.

Ano, .bat soubory jsou v OEM code page, stejně jako v DOSu. Jestli víte o lepším řešení zpětné kompatibility, dejte vědět. Ovšem nechoďte sem s tím "konceptem" z unixů, kde se například na disku míchají názvy souborů v různých code pages.

Notepad by měl nabízet OEM code page. Ve vistě už nenabízí, tam je třeba použít Wordpad. Tedy pokud z nějakého důvodu používáte 13 let staré .bat soubory :)

Pokud si zabalíte a rozbalíte adresář, 8.3 názvy nemusí zůstat zachovány. Záleží to od konkrétního archivačního programu. Souhlasím ale, že to může být problém, pokud se takhle chová ZIP komprese vestavěná ve Windows. Za celou dobu první váš dobrý argument :)

K testu: měl jsem na mysli zakládání uživatele. Založte si uživatel Přemek, nebo ještě lépe to japonské jméno, na Linuxu.

Qt i GTK jsou dnes používané frameworky, a různé dialogy mají dnes psané aplikace. V případě aplikací pro Windows 95 je to trochu jinak. V té době vypadalo GUI na unixech tak, že by člověk zvracel. Musím uznat, že dnes je GUI na unixech mnohdy nevhodně řešené, ale tak na zvracení, jak to převáděli Motif nebo CDE ve výchozí konfiguraci, to rozhodně dávno není.

Oceňujete. Nejde jen o tiskárny, ale také o zvukové karty, grafické karty, IDE či SCSI řadiče, USB tokeny atd. Myslíte, že je vhodné z principu "dvě zařízení stejného typu na různých portech jsou různá zařízení" kvůli tomu, že zrovna vy máte zrovna jedno zařízení zrovna typu tiskárna? Podle mě ne.

Plochá je vaše stará - zjevně jste vůbec nepochopil, jaký byl kontext slova "plochý", takže ze sebe děláte idiota (viz výše - přestaňte s tím prosím). Pokud nedovedete pochopit, že systém musí být schopen podporovat dvě zařízení stejného typu, tak je to s vámi marné.

Sériové číslo tiskárny těžko můžete použít, pokud ho přes USB port nedostanete jako součást identifikace zařízení. Na štítku tiskárny vám to sériové číslo moc platné nebude :), z nálepky na PCB grafické karty ho nedostanete...

Hm, když jsme u toho dodržování názvu od dob NeXTu... Víte, že MacOS podporuje HFS+ a UFS? Asi ano. A víte, že HFS+ umí Unicode, je case preserving a má alternate data streams (forks), kdežto UFS neumí Unicode, je case sentivite, a alternate data streams neumí? Pejsek, kočička, dort... Co čekat od firmy, která tak těžce technologicky selhala.

.bat soubory nejsou jedinou možností skriptování ve windows. Jak skoro správně píšete, je tu Visual Basic Script (VBs, nikoliv VB). A jestli je šílený? Mě přijde naprosto v pohodě, na rozdíl od bashe nebo nedej bože PERLu.
Nejlepší možná zpětná kompatibilita je taková, kde se staré aplikace chovají, jak se chovaly. Například nemůžete aplikaci pro DOS změnit kódovou stránku, protože by to nerozdýchala. A pochopitelně jí nemůžete změnit kódovou stránku .bat souborů, protože by to také nerozdýchala.
Soubory .bat můžete editovat ve starších verzích Windows v Notepadu, v novějších verzích ve Wordpadu. Už jsem to psal dříve.

8.3 jména vytváří automaticky systém. Obecně tato konverze nekončí vždy stejně. Pokud máte v adresáři soubor se zamýšleným krátkým jménem, použije se další krátké jméno v pořadí (typicky neco~2), a po pár iteracích se použijí 4 náhodná čísla. Ten algoritmus se navíc liší mezi Win9x a WinNT, plus se dá nastavovat (NtfsAllowExtendedCharacterIn8dot3Name) nebo úplně zakázat (dnes celkem dobrý nápad). Z principu je tedy jasné, že když adresář zabalíte pomocí dlouhých názvů, a krátké názvy nebudete uvažovat (proč by to nová aplikace dělala), tak po rozbalení mohou být krátké názvy odlišné. Dá se to řešit tak, že uchováte i krátké názvy, a pak je nastavíte zpět (fsutil file setshortname, funkci API si nepamatuji). Jestli to dělá ZIP z Windows Exploreru, to nevím. Ale můžete mi říci, jak byste situaci řešil lépe.

Na Linuxu (či dalších unixech) je požadavkem na jméno uživatele, že může obsahovat jen alfanumerické znaky? A je to někde napsané, nebo je to jen takové empirické pravidlo, protože všichni vědí, že by to mohlo dělat problémy? ;) Navíc u cest a názvů souborů takové omezení neplatí. Přitom si z názvy s mezerami řada aplikací neporadí, i když by měla. Proto jsem psal, že aplikace na unixech na tom nejsou ohledně korektnosti nijak skvěle.

Win32 aplikace a .NET aplikace mají různé dialogy? Já si toho nevšiml. Máte nějaký příklad? Samozřejmě vám vyrobím Win32 aplikaci, která použije Win2K vzhled dialogu, nebo jeho starší verzi, ale o tom se nebavím.

NeXTStep byl zajímavý, bohužel nikoliv úspěšný (aby ne, s tou cenou). Bohužel features Nextu, které zmiňujete, nejsou features unixů, ale naopak tím, co Next odlišovalo od zbytku unix-based systémů. Jako typický unix uvažujme třeba HP-UX, AIX, Solaris.

S těmi tiskárnami a jejich odlišením přidáním čísla jste to nějak nedomyslel. Zařízení je prostě v systímu identifikováno pomocí ID sběrnice, číslem portu na dané sběrnici, a svým typem. Zkuste mi navrhnout jiný model, který bude fungovat, a to i pro případ, že nepoznáte, že se zařízení odpojilo (tiskárny mají auto power off - když se pak objeví tiskárna na jiném portu, nevíte, jestli je to ta samá, která před tím z nějakého důvodu umřela, nebo jiná).

Udev... Nebudu teď hledat nic o udev. Zato si rýpnu. Proč unixy dodnes používají ten příšerný systém major node a minor node pro adresování driverů? Například SLES 9 ještě nemá udev. Takový systém má potom ve /dev tisíce zbytečných device nodes, které nekorespondují s žádným HW. A když nějaký HW připojím, tak si stejně nemůžu být jistý, že tam pro něj device node je připravený (natož abych věděl, který to je). Tohle patří do počítačového středověku. Proč mohou mít Windows NT od první verze v kernelu Object Manager, který tohle řeší elegantně, a unixy po 50 letech mají pořád předpotopní systém, který mimochodem omezuje počet partitions na RAIDu na 15? Podobné je to s příšerností zvanou terminály.

Obávám se,že HFS neumí být case sentivite. Tedy podle toho co jsem našel - Mac tu nemám.

Ano, Linux má řadu FS. Jeden umí žurnál, další umí kvóty, jiný umí kompresi, jiný ACL, ještě jiný umí kompresi a ACL, další ACL, kompresi a navíc je rychlý :). Otázkou je, proč nemít jeden *dobrý* FS, který umí Unicode, kompresi, šifrování, má podporu pro external storage (třeba HSM), umí Alternate Data Streams, umí ACID transakce, má funkční utility... Prostě nadmnožinu možností, které mají ty různé reimplementace BSD UFS a další pokusy. Samozřejmě pro Windows je možné napsat jakýkoliv jiný FS, včetně ext2/3, xfs, a dalších. Implementací existují zřejmě desítky, jen jsou určeny pro velmi specifické účely. Existují i implementace pár linuxových FS pro Windows. Pochopitelně je nikdo na windows nepoužívá, protože proti NTFS nemají co nabídnout.

Apple je firma, která dnes žije z prodeje MP3 přehrávačů vázaných na příšený iTunes, a "chytrých" telefonů, které nelze použít jako modem k notebooku ani GPS navigaci.

HulánEgo jsem kupovat nechtěl, jestli tak zněla otázka. Hulán je zajímavý fanatik, někdy výjimečně i zábavný.

Řekněme, že MacOS považuji pro uživatele za druhou nejlepší volbu po Windows. Ono nakonec nezáleží tolik na technologii pod kapotou, jako na komfortu pro uživatele (viz veliký úspěch Windows 3.x). Navíc Cocoa je poměrně pěkný framework. Ty technologické "třetí cesty" nepotěší, ale kdyby nebyly Windows, asi nezbyde nic jiného.

Solaris je technicky možná nejlepším unixem. Bohužel i ta je to unix. Navíc administrace Solarisu je oproti HP-UX nebo AIXu ještě horší - žádný nástroj typu SMIT nebo sam.

Co takový test má testovat? Implementaci cache, nebo rychlost kompilátoru? Nějak mi nedochází smysl. Na rychlost operací nad soubory může mít poměrně velký vliv i to, na jaké části disku jsou uložené (protože dnešní disky dávno nepoužívají Constant Angular Velocity, ale Zone Bit Recording).

Otázka je, kde byl tehdy NeXT. Já to soudit nemůžu, protože jsem NeXT na živo nikdy neviděl.

Faktem ale je, že Windows běžely na levném HW, samy byly levné, a existovala pro ně spousta aplikací. Světe div se, ale NeXTcube za USD 10 000, bez aplikací, a bez zpětné kompatibility s čímkoliv, neprorazila.

Já jsem zase nikdy nevidel Windows.

Když je to levné, tak to asi bude pro socky.

Vzhledem k tomu, že nikdo jiný nenabízí tak dobrou kombinaci uživatelsky příjemného prostředí, dobré architektury, široké funkcionality platformy, kvalitní dokumentace a vývojových nástrojů, podpory vývojářů, nabídky školení atd., asi by současné Windows při startu "všichni z nuly" skončily na dost dobrém místě.

Poslední větu nechápu. Při Constant Angular Velocity snad nezáleží na tom, kde jsou data uložena?
CAV a Zone Bit Recording si odporují? Neznám disk, který by neměl CAV - to neměly pouze CDROM.

Při čistém CAV byste měl na každé stopě stejné množství dat, a tedy výrazně nižší hustotu záznamu na cm^2 na vnějším kraji plotny. V praxi má plotna sice otáčí konstantní úhlovou rychlostí (CAV), ale navíc se modulační frekvence mění podle vzdálenosti hlavy od středu plotny. Říká se tomu Zone Bit Recording. Důsledkem je, že na kraji plotny čtete data rychleji.

Vím, co to je Zone Bit Recording. CAV neznamená, že je na každé stopě stejné množství dat, ale že disk rotuje stejnou rychlostí ať se čtou data uprostřed nebo data na okraji disku. Všechny disky jsou CAV. Proč by se CAV a ZBR vyločovaly?

Pokud vím, tak pouze staré CDROM a vypalovačky používají Constant Linear Velocity, což je opak CAV.

Zone Bit Recording se také nazývá Zone Constant Angular Velocity (Zone CAV, Z-CAV nebo ZCAV).

Víc viz: http://en.wikipedia.org/wiki/CAV

http://en.wikipedia.org/wiki/Zone_Bit_Recording

Taky jsem odsud čerpal. :-)

Vím, co to je Zone Bit Recording. CAV neznamená, že je na každé stopě stejné množství dat, ale že disk rotuje stejnou rychlostí ať se čtou data uprostřed nebo data na okraji disku. Všechny disky jsou CAV. Proč by se CAV a ZBR vyločovaly?

Pokud vím, tak pouze staré CDROM a vypalovačky používají Constant Linear Velocity, což je opak CAV.

Zone Bit Recording se také nazývá Zone Constant Angular Velocity (Zone CAV, Z-CAV nebo ZCAV).

Víc viz: http://en.wikipedia.org/wiki/CAV

Samozřejmě unixy mají velkou kapitolu v historii IT. Hluboce se klaním, a říkám "to bylo super". Unixy svého času přinesly počítače z univerzit a laboratoří do každé větší firmy. Přinesly za poměrně nízkou cenu obrovské zvýšení produktivity práce. Patří jim za to můj dík, a čestné místo v muzeu. Hned po bodu MULTICS, OS/360, OS/400, VMS, Pilot (na Xerox Star) a dalších. Ale nějak mi není jasné, proč bych proto dnes měl ovládat vi pomocí kláves hjkl, protože kdosi před půl stoletím vymyslel systém terminálových sekvencí, který byl jistě skvělý pro dálnopis, ale je naprosto příšerný na dnešním počítači. Dnes jsme jinde. Počítače jsou stejně běžné, jako mikrovlnky, a koncept unixů působí asi stejně skvěle, jako parní lokomobila ve srovnání s dnešními automobily.

Když jsme u toho, Windows nemohly být první, protože přišly na trh v roce 1985, a byly určené pro desktopové počítače (tam se clustering moc nenosí). Technicky zajímavou verzí byly až Windows NT v roce 1993. Ty překonávaly unixy v řadě věcí. Mimo jiné měly daleko novější a lepší návrh (preemptivní kernel, Hardware Compatibility Layer, subsystémy, portabilitu, threading, bezpečnost, na svou dobu geniální GDI).

Pokud chcete srovnavat lokomobilu s automobilem, mohl byste tez srovnavat lokomobilu s kecupem nebo Wagnerovu operu s automobilem. Oblast jejich aplikace je stejne odtazita. Patrne nevite, co je to lokomobila. Rozhodne to ale neni dopravni prostredek prez to, ze slovo obsahuje koren mobil.

Parní lokomobila:
http://upload.wikimedia.org/wikipedia/commons/0/0c/SteamLocomobile1901.jpg

Locomobile Company of America
http://en.wikipedia.org/wiki/Locomobile

Teď se zase můžeme vrátit k předmětu diskuze.

Nojo, zase mlzite. Nemluvil jste o Lokomobile ale o lokomobile. A lokomobila je uplne neco jineho: http://cs.wikipedia.org/wiki/Lokomobila. Jiste se nejednalo o preklep a nemel jste na mysli vlastni jmeno v Evrope dosti neznameho vyrobce automobilu z Ameriky, ale podstatne jmeno oznacujici mobilni parni stroj, pouzivany k pohonu hospodarskych a jinych zarizeni. Tedy nikoliv jako tahac nebo jiny dopravni prostredek. S lokomobilou se na pivo nejezdilo.

Co má RFC pro emaily společného se jménem uživatele? Já myslím, že vůbec nic. Tedy alespoň ve Windows může mít uživatel login name frantisekk, display name "František Křeník", a mailovou adresu "franta.kren@firma.cz".

Moje zkušenosti s tiskárnami na Linuxu byly dost tristní. Mizerná podpora HW, mizerně vypadající barvy, nulová podpora color managementu. Možná je něco z toho opraveno, ale zrovna o tom color managementu (který zahrnuje barevné profily, kvalitní převody barevných prostorů, podporu separací, a ve Windows je modulární).

A když jsem u těch idiotů, co je MS podporuje, tak je smutné, že svoje vlastní "My Documents" a "Application Data" si často vytváří i open source programy, případně multiplatfomrní, původně linuxový SW.

Třeba IRSSI vám nadělí tohle: "Data aplikacÝ". Jiné programy si zase hezky tvoří složky s tečkou na začátku, asi aby ukázaly, že UNIX rulez a co že si o vašich windows myslí. Ale bylo by fajn, kdyby to aspoň cpaly tam, kam to patří - do té podsložky "application data/data aplikací/atd".

Asi byste se divil, kdyby vám aplikace portovaná z Windows založila na disku /Program Files a ~/Local Settings/Application Data/Výrobce/Program. Kupodivu přesně tohle dělají aplikace portované z unixů ve Windows. Navíc často používají ANSI volání (tedy nejsou připravené na Unicode), případně mrší češtinu. Ty nejdrsnější kusy navíc zapisují UTF-8 přes ANSI API, což vede například k nepoužitelné změti písmen místo názvu souboru.

To s vaplováním je chyba filesytémů, nebo palících programů. Na windows funguje kódová stránka skvěle, NT systém je plně interně (a externě samozřejmě taky) unicode. Že mají windows a linux jinou kódovou stránku, to není důod nadávat na windows. Osobně jsem měl problém jen když jsem chtěl otvírat soubory z win partišny na linuxu (a naopak).

Windows odjakživa jedou v UCS-2 (případně UTF-16), tedy 16-bitové wide charactery. To až pro unixy bylo třeba vytvořit něco, co procpe Unicode skrz API stavené pro 8-bitové chary, protože měnit API by bylo moc práce. Bohužel to na unixech vede ke spoustě naprosto příšerných problémů, kterých se asi ani nelze zbavit.

Windows odjakživa jedou v UCS-2 (případně UTF-16), tedy 16-bitové wide charactery.

Na Windows 3.0 jsem si svého času ničeho podobného nevšiml. :-)

To až pro unixy bylo třeba vytvořit něco, co procpe Unicode skrz API stavené pro 8-bitové chary, protože měnit API by bylo moc práce.

Jestli máte na mysli, že UTF-8 bylo navrženo tak, jak je navrženo, kvůli Unixům, pak bych si o tom dovolil pochybovat. To by ho nejspíš navhli tzv. "eight-bit clean", mimo jiné, což je nestalo. Navíc na něm měli docela dost podíl pánové kolem IBM a Plánu 9, a to nejsou všichni unixofilové.

Bohužel to na unixech vede ke spoustě naprosto příšerných problémů, kterých se asi ani nelze zbavit.

Jakých "naprosto příšerných problémů" konkrétně? Zcela konkrétně, prosím. (A pro jistotu dodám, že mluvím specificky o používání UTF-8, ne o tom, co podporují nebo nepodporují legacy funkce v libc, jejichž sémantika musí být kvůli zpětné kompatibilitě zachována, stejně jako Windows mají svoje zastaralá - pardon - "zpětně kompatibilní" API. ;-))

Názov souboru má uživateli říci, co je uvnitř. Technicky neexistuje důvod, proč to neříkat s nezerami a diakritikou. File system diakritiku i mezery umí, je to zcela v pořádku. To, že se na unixech ve skriptech všechno escapuje, a často na to autoři zapomínají, je jistě smutné. Ale když udělá chybu autor aplikace, bijte do hlavy jeho, a ne uživatele.

Jaký máte problém s dlouhými názvy na CD? Vždyť specifikace je dovoluje. Viz 9660 s Joliet Extension, jména jsou dokonce v Unicode. I URL dnes podporují diakritiku.

Pokud vím, tak zrovna Joliet není dobrý příklad, má poměrně nízké limity. Často na to narážím, že to po mě chce zkrátit název kvůli tomu, že se cesta do Jolie nevejde.

To je samozrejme chvalyhodne. Na co ale meli spolehat programatori ve Visual Basicu pro Exell, kdyz jim ho Microsoft, v ramci lokalizace, cely kompletne prelozil do francouzstiny (tedy i s klicovymi slovy VB). :-)

Chcete říci, že přeložili funkce Excelu, nebo jazyk VBA? Upozorňuji, že VBA je ta věc v editoru kódu (sub abc(i as integer), debug.print cosi), a funkce Excelu jsou v buňkách.

Francouzi jsou pověstní tím, že jsou (dost nesmyslně) hrdí na svůj jazyk, z čehož plynou tyhle excesy. No, svého času se jednalo o lingua franca ;)

Prelozili VB Excelu. Nepsalo se pak select, ale selectionner. Ovsem, makra byla prenositelna. Stacilo je prelozit do anglictiny nebo jineho jazyka, pokud podobnych prekladu VB bylo vice v dalsich jazycich. :-) Treba cesky Excel stejne verze mel VB normale v anglictine.

Nejlepsi je na tom, ze zvolili tak dlouhe jmeno a navic s mezerou. Asi jim c:\home pripadalo nedostatecne user friendly a navic Windows admini radi datluji zbytecne blbosti.