Hlavní navigace

Preference vývojářů podle OS

Sdílet

Pavel Chalupa 24. 6. 2008

Podle statistiky Evans Data Corporation vývojáři vyvíjejí nejčastěji (49%) pro Windows XP, které brzy skončí. Na druhém místě je Linux se 13% a na třetím je MS Windows Vista s pouhými 8% vývojářů. Jedním z důvodů tohoto stavu je postoj vývojářů ve stylu „čekat a dívat se“ jak to dopadne s Vistou. Pro rok 2009 je očekáván vzestup počtu vývojářů zaměřujících se na Linux na 15%, což signalizuje sice pomalý, ale postupný odklon od Windows.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 24. 6. 2008 13:06

    Psycho (neregistrovaný)
    Este by bolo zaujimave mat paralelne statistiku, ze ktory OS by developeri preferovali keby... lebo ja teda na tom WinXP nedevelopim z presvedcenia, ale preto, ze to tak mam 'z hora' nadelene. ;-)
  • 24. 6. 2008 13:29

    Ondra "Satai" Nekola
    Prekvapive zadna zminka o Mac OS X? Chapu, ze lide pouzivajici M$ technologie ho preferovat nebudou, ale trebas pri pohledu na RoR komunitu bych (od boku a bez naroku na presnsot) tipnul, ze v ni bude notne popularnejsi nez Linux.
  • 24. 6. 2008 13:42

    bez přezdívky
    100 - (49 + 13 + 8) = 30
    Z toho na BSD, AROS, AIX, Solaris, Hurd, Win98 a podobne nepripadne vic nez deset, takze tak dvacka je pro Mac OS X.
    Ale zucastnilo se jenom 430 lidi, takze informacni hodnota je nula nula nic.
  • 24. 6. 2008 14:35

    Uživatelka si přála zůstat v limbu (neregistrovaný)
    430 už je docela velký vzorek. Kdybyste měl sociologické vzdělání, tak víte, že v praxi se průzkumy dělají maximálně do 1000 respondentů. Opravdu výjimečně (a přijde to draho) do 10000 ale to jsou už spíš státní projekty a ne něco, co dáte agentuře a ona to jen tak sjede... Toť mé skromné povědomí.
  • 26. 6. 2008 15:03

    bez přezdívky
    No nevim. 430 lidi je dost malo na to, aby to bylo aspon trochu presne, protoze pak zalezi na tom, kde se ptali. Dobry test by byl tak od tisicovky nahoru.
  • 19. 6. 2009 20:34

    ventYl

    tomu sa hovori reprezentativnost vzorku. ak je vzorka ludi reprezentativna (tzn. ze si nepresli vyvojove oddelenia dvoch pasakov programatorov), je vcelku jedno, kde sa pytali.

  • 24. 6. 2008 13:59

    Lael Ophir (neregistrovaný)
    Vývojáři vyvíjejí pro XP z toho důvodu, že aplikace psané pro XP běží i na Vistě. Naopak aplikace závislé na featurách Visty na XP pochopitelně nejdou. A psát dnes Vista-only aplikaci není dobrý nápad. Nakonec všichni víme, že ještě v roce 2003 se často psaly aplikace tak, aby šly i na Windows 9x.
  • 24. 6. 2008 14:11

    X (neregistrovaný)
    "Vývojáři vyvíjejí pro XP z toho důvodu, že aplikace psané pro XP běží i na Vistě." hehehehe - realita je trošku jinde ;-) Vidím to denně.Aplikace běžící pod XP najednou pod Vistou nejede nebo nefunguje správně z důvodu UAC,kódování atd.

    Za nejvtipnější považuji hlášky Access denied,když se Administrator pokouší přistoupit do vlastní složky,případně nemožnost kopírovat přímo do Program Files atp.
  • 24. 6. 2008 14:51

    Lael Ophir (neregistrovaný)
    Aplikace správně napsaná pro XP samozřejmě ve Vistě funguje. Pokud vaše aplikace potřebuje oprávnění admina, musí samozřejmě pracovat s UAC. Typicky je ale problémem to, že autor aplikace je idiot, a počítá s tím, že aplikaci provozujete s právy admina. Viz starší verze Total Commanderu, které zapisovaly konfiguraci do konfiguráku v Program Files. Bohužel autorům nelze za podobnou prasárnu uříznout ukazováček :)

    Zvláštní je, že já nikdy neviděl hlášku Access Denied při přístupu do vlastní složky. Ale je pravděpodobné, že jde zase o chybu vaší, nebo chybu aplikace. Ve Vistě se totiž například změnilo umístění dokumentů z "%USERPROFILE%\My Documents" na "%USERPROFILE%\Documents". Umístění adresáře dokumentů je v SDK popsané tak, že zavoláte API SHGetFolderLocation se správným parametrem, a dostanete adresář.
    http://msdn.microsoft.com/en-us/library/bb776887(VS.85).aspx

    Idiot ovšem spoléhá na "%USERPROFILE%\My Documents", "%USERPROFILE%\Application Data" apod. To samozřejmě neběhá v lokalizovaných verzích Windows (v češtině jsou to tuším tuším "Moje dokumenty"). Ale v anglické Vistě to běhá, protože MS kvůli idiotům vytvořil skryté linky typu "%USERPROFILE%\My Documents" který směřuje na "%USERPROFILE%\Documents", "%USERPROFILE%\Application Data" který směřuje na "%USERPROFILE%\AppData\Roaming" atd. Kvůli fulltextové indexaci je na lincích uzávěra, takže nelze listovat obsah. To je asi ta vaše hláška "Access Denied". Kdyby tam ta uzávěra nebyla, měl byste dokumenty indexované dvakrát. Kdyby tam nebyl ten link, aplikace psané idioty by nefungovaly.

    Jak vidíte, Vista je v pořádku. Problém je na straně vývojářů-idiotů, případně vašeho nepochopení.
  • 24. 6. 2008 15:06

    OHV (neregistrovaný)
    > protože MS kvůli idiotům vytvořil skryté linky typu ...

    LOL !


    > Problém je na straně vývojářů-idiotů, případně vašeho nepochopení.

    Tak proč je MS podporuje ?
  • 24. 6. 2008 16:26

    Lael Ophir (neregistrovaný)
    Těchto problémů je celá dlouhá řada. Například vývojáři vykrádají ikony a animace z knihoven Windows shellu. Přitom obojí najdou v SDK. Když další verze Windows nemá třeba ikonu semaforu v knihovně A na pozici B, aplikace která na to spoléhá prostě spadne.

    Ptáte se celem logicky, proč to MS podporuje. Odpověď je také logická. Když vám aplikace funguje ve Windows verze X, ale už ne ve Windows verze X+1, koho obviníte? Na prvním místě výrobce OS (jak jste to sám předvedl). Popsaných prasáren se totiž dopouštějí výrobci velké spousty aplikací. Proto Windows obsahují knihovny s dávno nepoužívanými ikonami (později se tam nechávají jen bílé čtverečky), proto jsou ve Vistě ty linky atd.

    Tady třeba vidíte ukázku, kdy autor aplikace chtěl interaktivně přimapovat síťový disk, a dělal to tak, že zobrazil kontextové menu, a zavolal pátou položku od konce menu. Kupovidu to ve Vistě nefunguje :).
    http://technet.microsoft.com/en-us/magazine/cc160916(TechNet.10).aspx

    A najdete tam i pěknou poznámku. Pokud aplikaci psal konkurent MS (což je celkem běžné), a neběhala by ve Vistě, na rootu by se psalo něco stylu "Windows Vista záměrně poškozuje SW X, čímž Microsoft získává nefér výhodu".

    Program psaný pro Windows 3.1 otevřel Control Panel, File Menu, a hledal položku s názvem Printer. Ve Win95 taková položka v Control Panel nebyla, takže program poslal zmršenou window message. Microsoft proto ve Windows 95 vytvořil falešné nevididelné okno Control Panelu, které tuto zprávu odchytilo a zpracovalo.
    http://technet.microsoft.com/en-us/magazine/cc160898(TechNet.10).aspx

    http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx

    Špatné čtení z Registry
    http://blogs.msdn.com/oldnewthing/archive/2005/09/01/459023.aspx

    Spoléhání na ikony a animace v knihovnách shellu
    http://blogs.msdn.com/oldnewthing/archive/2005/10/26/485133.aspx


    Stačí to pro ilustraci toho, že autoři aplikací jsou prasata?
  • 24. 6. 2008 17:07

    M. Prýmek
    No jo, jenže to je přesně důvod toho, proč jsou Windows v některých věcech tak zbastlený - protože zachovávají zpětnou kompatibilitu i u věcí, pro který není v moderním OS místo, zejména v podpoře prasáren, který ilustrujete velmi přiléhavě.

    Podle mě by OS měl u programátora trochu vynucovat nějakou štábní kulturu.

    Ilustrace ŠÍLENÝCH návyků: u většiny :( programů českých autorů, který jsem viděl, jsou data pomíchaná s binárkami a obojí je v Program files (!), v horším případě dokonce v C:\ (w2k po čisté instalaci má C:\ přístupné všem (!) ) Když jsem po jedné firmě chtěl, aby mi aspoň vyjmenovali, který soubory jsou (neměnný) binárky apod. a který samotný data (abych nastavil práva), dívali se na mě jako na blázna. Že prý takhle se to vůbec nedělá - že prý se prostě Pepovi a Frantovi a Mařence, který ten program používají, prostě dají k adresáři všechny práva. (u jednoho programu na síťovém disku máme cca stovku uživatelů :)))

    Když jsem nakonec nějak oddělil binárky a data, občas docházelo k problémům a technik dané firmy byl nesmírně vypruzenej a dával jasně najevo, že to je tím, jak mám "debilně" nastavený práva...

    Nechci říct, že konkrétně tohle je chyba Windows. Není. Ale je to děditctví MS DOSu a Win se tváří jako jeho nástupce. Kdyby počínaje Win NT M$ řekl "je to nový systém, kde je potřeba striktně dodržovat nová pravidla" a pro podporu DOS programů vytvořil nějaký sandbox (aby se to nemíchalo s novými programy - trochu něco jako kompatibilita devítky v Mac OS X), tak by byla situace IMHO poněkud odlišná...

    Nebo řečeno jinak: proč velká část programů pro Win standardní pravidla nedodržuje a programy pro Uni*y ano (včetně MacOS X!) ?

    Kdyby podpora debilit starších verzí u Win nebyla, tak by prostě program verze X.Y na nových win nejel a verze X.Y+1 ano. Co je jako na tom?
  • 24. 6. 2008 17:35

    bez přezdívky
    To je také pravda, ovšem pokud by zničehonic přestalo fungovat x-desítek (stovek, tisíců) programů, tak by na tom tratil jen a jen Microsoft, protože by nikdo na nový systém nepřecházel. Stačí se podívat na Windows Vista. 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. Ale proč. Proto, že v MS začali dbát více na bezpečnost a konečně trochu dbají na dodržování pravidel? Není to snad to po čem se volalo? A když to hoši v Redmondu udělali, tak se zase křičí, že tak to dělat neměli a že to měli udělat, tak, či onak.

    Nejsem Windows fanatik, jsem pro vícero alternativ a Linux v dnešní době považuji za plně použitelný systém i pro desktop (samozřejmě záleží na využití), ale celkem mě vytáčí, když se pořád jen všude křičí jak je Microsoft špatný a Windows nepoužitelné, když objektivně vzato se situace u Windows stále zlepšuje. Jen to někteří nechtějí vidět a chtějí mít systém s vlastnostmi Unixu na němž by běhali programy psané stylem pro Windows 98...
  • 24. 6. 2008 18:07

    M. Prýmek
    A není to náhodou spíš tím, že M$ neustále vynalézá kolo? Verze 1 je kolo ve tvaru čtverce a až se to po X letech ukáže jako nesmysl, udělá se kulaté a přestane fungovat spousta SW, který předpokládá, že kolo musí mít hrany...

    > Ale proč. Proto, že v MS začali dbát více na bezpečnost a konečně trochu dbají na dodržování pravidel?

    Ano. Po pár desítkách let objevili, že multiuživatelskost OS není v tom, že každému uživateli se nahraje jeho vlastní plocha. Po pár desítkách let objevili, že bezpečnost spočívá v minimalizaci přidělených oprávnění. Po pár desítkách let objevili, že existuje něco jako přístupová práva pro soubory. Atd. atd.

    > objektivně vzato se situace u Windows stále zlepšuje

    Objektivně vzato je už neudržitelné se pravou rukou drbat na levém uchu. Proto se zavádí řešení, která mají Uni*y od počátku. Ano, bolí to. Ale člověk s alespoň minimální mírou nadhledu vidí, že si M$ vyžírá jenom to, co si sám nasral* v minulosti...(!)

    Opět musím dodat: geniálně to (narozdíl od M$) zvládl Apple. "Leprd" už je certifikovaný Unix. Přechod z devítky byl poněkud bolestný. Ale byl to kompletní přechod na platformu, která má všechno tak, jak to má být a používá standardní řešení. Devítka byla zachována jen v sandboxu. Poté přechod z PPC na Intel - naprosto geniálně zvládnutý díky Universal Binary. Bojím se jenom si představit, jak by takovou migraci řešil M$...

    --------
    * omlouvám se, ale jinak se to prostě říct nedá
  • 24. 6. 2008 18:31

    bez přezdívky
    Samozřejmě nepopírám, že si za tyto problémy může MS z velké části i sám, to máte pravdu.
    Na stranu druhou MS po pár desítkách let objevil... No ona NT větev systému je tu již také řádně dlouho a víceuživatelský systém a oprávněními a uživatelskými skupinami a la Unix je to víceméně od začátku. Proto se tedy ptám proč vývojáři píší i po těch x-letech co existují NT, software pro NT tak, jako by šlo o dávno mrtvou větev Win9x postavenou na DOSu? Možná udělal MS chybu a neměl tehdy v NT pravěku dát novému systému stejné jméno, stejné rozhraní, atd., což vede k záměnám. Na stranu druhou to bylo přínosné pro uživatele, protože tu měli více druhů systémů, ale s více méně stejným ovládáním, atd.

    Že byla DOS-based větev systémů Windows v porovnání s Unixy o ničem je jasné, ovšem na stranu druhou měla na trhu své nezastupitelné a době odpovídající místo. Kolik bylo mezi běžnými uživateli počítačů na začátku devadesátých let. A kolik lidí si mohlo dovolit drahé Unixové operační systémy? Jasně - byly tu i jiné platformy, ale nevydrželi a PC je převálcovalo. A kdo už si mohl dovolit PC, tak ten nechtěl ještě platit za drahé komerční Unixy. Byl tu DOS a posléze Windows, které sice nebyli nijak zvlášť stabilní, technicky na výši, atd., ale byly dostupné a to ani nemluvíme o pirátství, které jejich šíření nepochybně velmi prospělo (jak ostatně přiznal i sám Gates). Linux zdarma byl v té době v plenkách a pro většinu uživatelů nepoužitelný.

    Ale nebavme se o W9x. NT větev je tu již dlouho a byť i ta má své problémy, tak v porovnání se starou větví je o poznání lepší a to s každou novou verzí. Po pravdě mi s každou novou verzí připadá, že se MS více a více blíží v mnohém filozofii Unixů (ano - trvá mu to dlouho, ale ten přerod nejde udělat ráz na ráz). Je tu problém zpětné kompatibility, ale když vzpomínáte Mac a přerod z verze 9 na OS X, tak něco podobného se údajně plánuje i ve Windows 7 (spíše ale až ve Windows 8 :)), kdy by starší verze měli běžet virtualizovaně v sandboxu a systém sám být přepracován. Jsem zvědav, jak se něco podobného Microsoftu podaří - necháme se překvapit ;). Podle mě by to ale při dnes dostupných technologiích nemusel být zase až tak hyper-náročný úkol.
  • 24. 6. 2008 19:58

    Lael Ophir (neregistrovaný)
    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ů :)
  • 24. 6. 2008 22:51

    ABC (neregistrovaný)
    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í.
  • 24. 6. 2008 23:33

    bez přezdívky
    Pravda s tím křikem - také si vzpomínám. Ba dokonce nešlo ani o odstranění, ale jen "by default" zakázání, bo šli znovu povolit, když to bude admin potřebovat :).
  • 25. 6. 2008 9:00

    JardaP (neregistrovaný)
    Nevim, jestli sandbox je tim spravnym resenim. Mozna, ze vypolstrovana zvukotesna cela by byla lepsi.
  • 25. 6. 2008 14:04

    Ivo Peterka
    Starší verze v sandboxu? Tak to si už teď výrobci HW - hlavně pamětí - určitě mnou ruce ... ;-). Jinak zpětná kompatibilita je nutná, protože přepsat to obrovské množství COM SW do .NET v podstatě není možné. Navíc si myslím, že MS s jednotným API pro NT a 9x větev chybu neudělal. Spíš měl u NT větve od začátku více tlačit na nastavování práv a učit své uživatele (tak jak to dělají unixáři), že pracovat pod právy administrátora je nebezpečné. Utilita runas je v NT řadě až ve Win2k - měla tam být mnohem dřív ... .
  • 24. 6. 2008 19:54

    Lael Ophir (neregistrovaný)
    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?
  • 24. 6. 2008 21:25

    M. Prýmek
    No nic, tak to fakt nemá cenu. Možná by pomohlo si uvědomit, jaký byl ještě donedávna před w2k poměr w95:wNT, jaké bylo procento využití souborových práv (o nějakých templates ani nemluvě) apod.

    Možná byste potom, drahý Laele, se kterým si netykám, pochopil, proč tolik programátorů má vysoce shitózní návyky, potažmo, proč jsem se vyjárřil v tom smyslu, že si M$ musí vyžrat vlastní shit.

    > s vlastními fonty, vlastními drivery tiskáren atd. Fuj!

    Ano, tak už to u sandboxu bývá :))) Jeho podstata je totiž v řádném oddělení starých systémů od nových, nikoliv jejich zbastlení dohromady.

    > No a příchod 64 bitů, který dnes v Apple probíhá, je opět technicky zpackaný.

    Přechod na Intel? To je pravda. Strašně zpackaný. Vzal jsem myš, přetáhl soubory (včetně aplikací) z PPC na Intel a vše jelo tak jako předtím. Svinstvo! Kde to má jako nějakou pořádnou plošnost?! Chraň nás Velká Plocha od takových spatlanin!

    ========

    Tak to by asi tak pro dnešní večer stačilo. Plochosti, NTLM kompatibilnímu jen samo se sebou, všemocnému Roamingu, nefunkčním bat souborům a libovolně se prohazujícím 3.8 souborům třikrát nazdar! zdar! zdar! zdar!

    P.S. měl jsem zrovna nějakej problém s HKEY_CLASSES_ROOT\CLSID\{F6FD0A01-43F0-11D1-BE58-00A0C90A4335}, ale je to v poho, podle InprocServer32 jsem zjistil, že jde o C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\40\bin\FP4AWEC.DLL, tak už je to dobrý. Jenom jsem trochu zapřemýšlel, jestli je ta cesta dostatečně plochá a ono "bin" nezavání nějakým unixovým haraburdím nepřehledným!
  • 25. 6. 2008 1:14

    Lael Ophir (neregistrovaný)
    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ě.
  • 25. 6. 2008 2:00

    M. Prýmek
    > Donedávna máte na mysli před uvedením Windows 2000? :)

    Ano. A ještě chvilku po něm. Nebo si myslíte, že po uvedení w2k všichni programátoři se starými návyky šli od válu nebo začali programovat korektně?

    > Nebo považujete za výhodu pro uživatele, když starší aplikace mají vlastní fonty, vlastní drivery tiskáren apod.?

    Výhoda je úplně jinde a musíte být dost zabedněný či hulantní, abyste to neviděl:
    já: * nemám žádné aplikace pro OS9
    * mám pár věcí pro PPC
    * mám Intel stroj

    Moje situace na MacOS: sandbox už v systému nemám (na Intelu není) -> o nic nepřicházím a netrpím žádným zpětným balastem. Aplikace pro PPC mi jedou naprosto stejně jako intelácké/univerzal. Žádný balast to do systému nevnáší a je to seamless.

    Moje situace na Windows:
    * nemám žádné DOS aplikace
    * nemám žádné aplikace zprasené tak, aby přistupovaly k položkám, které jakési Windows obsahovaly před cca 15lety.

    přesto:
    * mám systém zaplevelený jakýmisi obskurními částmi, které používají jakási obskurní kódování
    * všude jsou nacpané jakési odkazy a berličky pro kompatibilitu
    * když jsem si chtěl pustit DOSovou hru (nebo i hru pro W95), stejně nefungovala. Použil jsem tedy DOSbox (sandbox, který je důkazem naprosté technologické neschopnosti - koho tentokrát?)

    -------

    Co se týče těch bitů, tak to nevím a upřímně řečeno je mi to šumafuk. Ale jestli je 64b "jen" Cocoa a libc, tak to jsem tedy naprosto spokojen, protože to je to, co využívá 90% aplikací kromě vykopávek.


    > Vy máte problémy s klíči registru?

    Já mám problém s kdečím, ale je zajímavé, že vetšinou s něčím ve Windows, o Linuxech ani nevím, že je mám :)
  • 25. 6. 2008 3:56

    Lael Ophir (neregistrovaný)
    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? ;)
  • 25. 6. 2008 9:15

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 15:01

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 15:16

    M. Prýmek
    > a na Linuxu máte třeba databázi rpm, která je také binární;

    Ok. Beru.

    Jak se na windows provede "rpm -qi"?

    > 1) neznáte základy COM

    Naznám. Díky Bohu!

    > 2) do registrací komponent nemáte co hrabat,

    Jestliže mám v logu záznam, že došlo k chybě při instanciování komponenty s CLSID XY, tak mi nic jiného nezbyde.

    > 3) ten "chlívek" je poměrně dobře dokumentovaný, jen mu nerozumíte

    Opravdu nemám čas studovat každý subsystém ve Win, který má vlastní pravidla, úplně odlišná od jiných subsystémů. Nejsem masochista.

    > 4) pokud neproběhne odinstalace komponenty, není to žádná tragédie

    Ano, to je typické windowsácké myšlení. Víte, na to my nejsme zvyklí!
  • 25. 6. 2008 18:40

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 17:13

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 18:48

    Lael Ophir (neregistrovaný)
    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á.
  • 25. 6. 2008 20:29

    JardaP (neregistrovaný)
    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.
  • 26. 6. 2008 1:30

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 11:34

    JardaP (neregistrovaný)
    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.
  • 26. 6. 2008 17:44

    Lael Ophir (neregistrovaný)
    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á.
  • 26. 6. 2008 17:50

    anonymní
    Bohuzel musim delat support aplikaci, ktere podle vas behaji bezproblemove. Takze:

    * pomoci _dobre pojmenovanych a zanorenych_ adresaru jde zapricinit, ze soubor nepujde beznym dialogem pro otevreni souboru z Windows 16-bit otevrit.

    * Spousteni aplikaci z DOSu je dost katastroficke, jejich planovani na procesor funguje podivne a zbytek systemu pak bezi extremne pomalu (vterinove lagy). Vyresilo se to instalaci dosboxu, ktery funguje spolehlive. To je ostuda MS.
  • 1. 10. 2009 21:14

    lord_kuko (neregistrovaný) ---.antik.sk

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

  • 24. 6. 2008 22:46

    anonymní
    "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)."

    Chochó! A Kerberos je "prakticky bez autentizace"? To ty Windows musejí být téměř nezabezpečené... ;-) Kdepak, myslím, že náš NFS server v podnikové linuxové síti by mě bez ověření totožnosti asi k souborům nepustil. A ohánět se telnetem, to už je skutečně zoufalý pokus. :]

    "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."

    Ó, jak chrabré. :-) Ještě že měli spoustu BSD a GPL kódu, bez kterého by jim to "jaksi" nefungovalo. :o) Otázka je, jestli se tohle ještě dá označit za dílo Microsoftu.

    "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."

    32b kernel? A nespadlo Vám něco na hlavu? Jak by s 32b kernelem měly fungovat context switche 64b kódu? Ano, Carbon je zastaralý, takže si s ním práci nedávají, ale úplně stejně se Microsoft chová k zastaralým funkcím Windows. Pod 64b Windows zase nefunguje spousta ovladačů, i když by mohla. :-)
  • 25. 6. 2008 3:00

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 3:35

    Rejpal (neregistrovaný)
    "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é.
  • 24. 6. 2008 23:34

    M. Prýmek
    Jo, ještě jsem málem zapomněl reagovat na tohle:

    > Windows NT byly certifikované na POSIX compliancy, stejně jako dnes MacOS.

    Drahy Laele Ophire, se kterým si netykám, POSIX-kompatibilní není to, čemu normální smrtelník říká Windows - tedy to, na čem si např. spustíš notepad.exe

    POSIX-kompatibilní je Interix (aka SFU), který nikdo nepoužívá.

    Fakt, že NTčka mají mikrojádro, nad kterým je možný nakrásně postavit třeba FreeBSD kernel ("subsystém") + všechny BSD utility neznamená, že NT jsou POSIXový systém. To může tvrdit jen silně zhulanizovaný (tady na Moravě se taky říká "zhulákaný") člověk.

    Řečeno velmi polopaticky a bez tykání, s notnou dávkou ironie: když si stáhnu OpenOffice pro MacOS, a poté spustím, tak jsem ho spustil nad Unixem. Když si stáhneš OO pro Windows, pouštíš ho pod Windows (Win32). OO pro Interix neexistuje (alespoň o tom teda nevím :)

    Ani nemluvě o tom, že MacOS 10.5 má i Single Unix Specification v3 certifikaci...
  • 25. 6. 2008 3:21

    Lael Ophir (neregistrovaný)
    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 ;)
  • 25. 6. 2008 18:50

    Lael Ophir (neregistrovaný)
    Jistě, třeba bez grafiky a GUI je systém daleko jenodušší napsat :). Otázkou je, k čemu dnes takový systém je.
  • 26. 6. 2008 22:59

    anonymní
    1. Seznam bezicich procesu ziskam na unixech prenositelne (neni v POSIX) pomoci: ls -d /proc/[0-9][0-9]*
    2. ifconfig maji take vsichni...
    3. ACL je popsano v draftech a je podle nich implementovano.
    4. OpenGL a X umi akceleraci pres sit. Trapna windowsi plocha je neakcelerovana. ooo, jak multimedialni.
    5. Ne-podpora Unicode? Nebyl první systém s unicode NeXTStep?
  • 27. 6. 2008 1:19

    Lael Ophir (neregistrovaný)
    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).
  • 27. 6. 2008 13:01

    ABC (neregistrovaný)
    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).
  • 27. 6. 2008 17:48

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 1:17

    Lael Ophir (neregistrovaný)
    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á.
  • 29. 6. 2008 13:43

    anonymní
    Nikdy nebyla linuxova? A GNU implementace je vosk? Navic to pochazi z NeXTSTEPu, coz je unix. Ze je to "rozsireni nad X11" jsem nikde nenapsal, to jste si vymyslel vy. Zrejme to potrebujete zahnat do outu.

    A navic DPS je starsi nez GDI, dalo by se rict, ze MS opisoval ;-)
  • 29. 6. 2008 17:09

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 21:35

    qwerty (neregistrovaný)
    DPS behalo na hardware, na kterem behaly Windows 9x. Provozoval jsem NeXTSTEP na 486. DPS vzniklo jeste pred rokem 1990 (snadno overitelne).
  • 28. 6. 2008 7:50

    ABC (neregistrovaný)
    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. :-)
  • 29. 6. 2008 2:33

    Lael Ophir (neregistrovaný)
    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é.
  • 29. 6. 2008 13:46

    anonymní
    Windows a localizace, to je vtip, ne? Ja si moc dobre pamatuju, ze ve windows ucebne ve skole byly pocitace pro cizince, protoze neslo mit nainstalovano nekolik jazyku najednou.
  • 30. 6. 2008 0:31

    ABC (neregistrovaný)
    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.?
  • 27. 6. 2008 21:11

    anonymní
    1. Ten kod s ls, co jsem poslal, Vam zafunguje na linuxu, *bsd a solarisu, u ostatnich unixu nevim, protoze je nepouzivame. WinAPI funguje ve windows a kde jeste?

    2. Shell poustet nemusite, muzete rovnou pustit ifconfig. Vytvorit proces je levne.

    3. Ten draft se dodrzuje, rika se tomu posix acl.

    4. Pres gprs jede mizerne i telnet, protoze ma obrovskou odezvu. Dialup doma snad nikdo, kdo by pouzil vzdalene nejakou aplikaci, nema. Nezijeme v minulem tisicileti. Pres moji domaci linku chodi Xka v pohode, ze aplikace bezi vzdalene je poznat maximalne v browseru. Akceleraci jsem myslel 3D a VZDALENE, prijde mi, ze jste to nepostrehl.
  • 29. 6. 2008 2:40

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 13:49

    anonymní
    Nezahrajete? Hraval jsem pres X na dalku quaka. Jinak akcelerovane platno pouzivaj i celkem bezne aplikace, ktere byste pres sit mohl chtit pouzivat.
  • 25. 6. 2008 7:42

    juvi (neregistrovaný)
    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ží.
  • 26. 6. 2008 16:42

    anonymní
    Šíříte FUD.

    1. Telnet se v nezabezpečené síti přenášel zabezpečenými kanály, server i klient to měli přímo v sobě. Pamatuji si to z roku 96, dál moje vzpomínky nesahají. Navíc v tu dobu už bylo ssh.

    2. NFS podporuje zabezpečení, pokud se Vám nechtělo číst dokumentaci, tak alespoň tu wikipedii jste si mohl přečíst. Málo kdo to zabezpečení používá, proč taky, když už se mi někdo vloupá do serverovny, tak je zbytečné řešit, že si může vytáhnout kabel a získat práva k práci se soubory.

    To s tím POSIXem a windows - mají sice certifikát, ale najdou se případy, kdy ho nedodržují. Například nemůžete mít jméno souboru končící tečkou, což je podle POSIXu možné.
  • 26. 6. 2008 18:04

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 18:57

    M. Prýmek
    > 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".

    Ano. Prvni M$ systém, který vůbec odděloval uživatele od sebe (NTFS), byly NT. NT-větev se masivně rozšířila až s W2k (nebo si myslíte, že měl někdo doma NT4?) a je naprosto neomluvitelné, že M$ vůbec přišel s Milleniem.
    Do té doby bylo prostě "všechno všech". Teprve teď si programátoři pro win začínají zvykat, že "všechno všech" v zabezpečeném systému není a že musí dodržovat jisté standardy. A kdo za to může? Kdo je to naučil? Kdo protáhl neskutečně zastaralé DOSové manýry až do 21. století?

    V tomto duchu jsem ty "standardy" myslel. Ohledně telnet/ssh pouze mlžíte.
  • 26. 6. 2008 19:28

    M. Prýmek
    Hm, tak to máme jednoho (a to ještě pouhé dva roky před vydáním w2k). A ještě znám jednoho - ten si z práce ukradl instalační CD. Ale nainstalovaný je myslím neměl. Jinak doma měl KAŽDEJ 95-98 a nedejbože Me. Ani v podnicích nebyla penetrace NT4 IMHO nijak vysoká...
  • 26. 6. 2008 20:02

    Lael Ophir (neregistrovaný)
    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).
  • 26. 6. 2008 19:27

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 19:41

    M. Prýmek
    Ano. Skloňujeme prostě podle vzoru Hulán: "Já mám jednoduchý systém pro jednoduchý HW a proto nemám zabezpečení. - Ty máš ubohý zastaralý systém, protože nemá zabezpečení."

    > A kdo že ty prasárny vývojáře naučil? MS to rozhodně nebyl.

    Byl. Protože jeho OS neměly žádné mechanismy, které by korektní chování vynucovaly, ba naopak, umožňovali naprosto libovolnou míru prasáctví, čehož samozřejmě vývojáři v rámci usnadnění si práce využívali. Kdo má uši k slyšení, slyš.

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

    1. Především si myslím, že to vůbec není klíčové.
    2. V době, kdy byl systém v jedné místnosti a v druhé místnosti terminály, nebylo asi šifrování linky potřeba, nemyslíte?
    3. Později přístup přez telefon. Odposlouchávání myslím nebylo velkým problémem, který by někdo měl potřebu řešit.
    4. Bezpečnost běžných počítačů v dřevních dobách nebyla prioritou. Vytýkat to Unixům a srovnávat s NT, vytvořenými o dvacet let později, je ubohé.
    5. Páteřní síť byla určitě dobře zabezpečena, už kvůli armádním kořenům Internetu. Prameny k tomu ale nemám.
    6. Nenašel jsem, odkdy rlogin podporuje parametr "-x", který zapíná šifrování. Tedy těžko můžeme vědět, jestli to bylo dřív nebo později než v roce 93, kdy vznikla nějaká obskurní verze NT.

    7. Na takovéhle přihlouplé debaty nemám ani čas ani náladu.
  • 26. 6. 2008 20:00

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 20:29

    M. Prýmek
    Třeba takhle ty tragéde! http://minix1.woodhull.com/faq/xt360kdsk.html

    Podpora DOSu přez sandbox. Od 286 nahoru klasická správa paměti a přístupová práva. Cca od roku 92 by nebylo co řešit.

    Jinak, ty blbečku, kdo se neumí podepsat vlastním jménem nebo alespoň registrovat, aby mohly být jeho příspěvky známkovány, v diskusích jenom prudí a zneužívá anonymity k zesměšňování ostatních, si nejenže nezaslouží vykání, ale nezaslouží si vůbec žádnou diskusi.

    Takže papa lala a běž si užívat svoje adminy, který považuješ za přiblblý. Můžeš jim od rána do večera vykládat o tom, že M$ nikdy nic neudělal blbě a ve všem byl o deset let dopředu.

    čau
  • 26. 6. 2008 20:47

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 13:05

    ABC (neregistrovaný)
    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.
  • 27. 6. 2008 17:58

    Lael Ophir (neregistrovaný)
    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 :)
  • 26. 6. 2008 22:06

    anonymní
    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".
    Vždyť já píšu, že si zabezpečený telnet pamatuju z roku 96 a že v tu dobu už bylo ssh, to si přece neodporujeme. Přes co to běhalo si nepamatuju, přestalo se to pak používat ve prospěch ssh.
    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ší.
    A IP, to tam je snad už od začátku existence. Jinak se mi moc nelíbí Vaše kritika, kdy napíšete NFS nemá autorizaci a když řeknu, že už 8 let ano, tak argumentujete tím, že to nikdo nepoužívá. A i předtím se to dalo honit VPNkou.
    což pak ve Win32 bude mít nepredikovatelné výsledky
    To mi ale nepřijde jako košer chování. Vzniknou vám pak dva oddělené světy (a to ještě v tom lepším případě). Jinak si osobně myslím, že když by se tím chtěl někdo opravdu zabývat, tak jim tam těch chyb najde víc. Certifikát mají, ale pro používání to moc není, mnohem víc věcí se uchodí na linuxu nebo na (Free|Open|Net)BSD, které ho nemají.

    Ještě k té tečce: myslím, že ten soubor vůbec udělat nešel, ale jsem líný to zkoušet (a instalovat někam ty services for unix), proto se o tom nebudu přít.
  • 27. 6. 2008 1:15

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 21:43

    anonymní
    Tim FUDem jsem myslel nezabezpeceny telnet a autorizaci v NFS. Chcete rict, ze jste tam mluvil pravdu?

    Budto autorizaci nepotrebuju (pro servery v jedne mistnosti to je zbytecne, tam si to jde bezpecne prodratovat), nebo potrebuju a pak starsi protokoly proste zakazu. VPN tak spatne nebylo, protoze se tim vetsinou prenaselo vic veci. Prislo mi to celkem dobre reseni, je to i relativne snadne na konfiguraci.

    Ziskani POSIX certifikace spociva v uspesne behu nejake sady testu. Nebyl by IMO problem je napsat tak, aby windows neprosly. Uplne oddlene svety to nejsou, protoze se muzou linkovat spolu s wokenimi knihovnami.
  • 29. 6. 2008 2:45

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 22:00

    anonymní
    Predtim jsem to cetl jinde, ale ted na me google vyplivlo toto: http://en.wikipedia.org/wiki/Interix cituji podstatne:

    It is a component of the Services for Unix (SFU) release 3.0 and 3.5
    ...
    "Mixed mode" for linking Unix programs with Windows DLLs

    Ocekavam, ze si za to na hlavu vysypete poradny kontejner popela.
  • 30. 6. 2008 17:04

    Lael Ophir (neregistrovaný)
    "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ž?
  • 30. 6. 2008 21:45

    anonymní
    Lhal jste predtim, kdyz jste tvrdil ze to jsou oddelene svety. To ze "neco nevite" jste napsal az pozdeji behem mlzeni.
    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.
  • 1. 7. 2008 16:51

    Lael Ophir (neregistrovaný)
    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.
  • 2. 7. 2008 0:43

    anonymní
    Kdyz nemluvite pravdu, tak lzete, to jestli lzete vedome nebo nevedome uz na tom nic nezmeni. Ja kdyz neco nevim, tak radeji mlcim nebo si to najdu.
  • 29. 6. 2008 14:01

    bez přezdívky
    mám v živej pamäti, ako ste sa vysmievali, ze Linux nie je POSIX compliant (ty hrozny jsou kyselé a pod.)

    nakoniec uznáte, že testy sa dajú zmeniť tak, aby neprešiel žiadny systém...

    funny, nemyslíte?
  • 29. 6. 2008 16:06

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 21:55

    anonymní
    Ale zmenit je tak, aby ty windows neprosly byla prace na par minut. A pouzivaly by se jen veci popsane v posix.
  • 30. 6. 2008 17:05

    Lael Ophir (neregistrovaný)
    Ří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.
  • 30. 6. 2008 17:20

    bez přezdívky
    Tak sa spýtam: je ten test kompletný v tom zmysle, že označí každý systém, ktorý nespĺňa normu POSIX ako nevyhovujúci? Alebo testuje len na vlastnú podmnožinu podmienok normy?
  • 1. 7. 2008 16:56

    Lael Ophir (neregistrovaný)
    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.
  • 2. 7. 2008 0:17

    anonymní
    Problem tech testu je, ze netestovaly to, v cem se unixy shodovaly. Podobne funguji treba acid testy pro prohlizece, kdy se do nich da to, s cim maji prohlizece problemy a ne to, co umi. MS se pri ziskani cedulky POSIX tedy nemusel soustredit na ty zakladni veci.
  • 2. 7. 2008 10:35

    Lael Ophir (neregistrovaný)
    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? :)
  • 25. 6. 2008 8:54

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 15:23

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 23:15

    anonymní
    NT mají velmi dobrý návrh.
    A ted nam prozradte, kdo ho udelal. Legenda pravi, ze za dekrementaci znaku WNT se skryva pravda.
    Dovedu pochopit, že MS-DOS musel vypadat, jak vypadal, díky HW
    A jaky HW mely prvni unixy? Opravdu na tom dos na tech 286kach byl hur?
    žádný FS se nelepí svými možnostmi na běžnou konkurenci.
    To snad nemyslite vazne, znate treba XFS?
  • 27. 6. 2008 0:57

    M. Prýmek
    > To snad nemyslite vazne, znate treba XFS?

    A co teprve ZFS. To ma funkcionalitu, kterou u windows uvidime nejdrive v pristi verzi (takze nekde 2011) a zase se nejde horda Laelu a Hulanu, kteri budou tvrdit, jak to byl pokrokovy design... no, co uz...
  • 27. 6. 2008 1:04

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 8:15

    LENIN POWER! (neregistrovaný)
    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.
  • 27. 6. 2008 1:27

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 21:34

    anonymní
    1. Kvalita vyvojaru v MS ale od te doby urcite poklesla. Uvedomte si, ze jejich cilem neni udelat kvalitni software, ale vydelat penize. U BSD, kde cilem vyvojaru je jejich vecna slava :) to je o necem jinem.

    2. Ted mi neni jasne, o kterych UNIXech a hardwareu mluvite. Konec chapu, 286 je blba, ale i pres to na ni bylo mozne provozovat unixlike OS. Jinak to, ze jsme porad u te mizrene x86 je dnes zasluhou MS. Mnohokrat diky.

    3. XFS fsck v systemu je, ale fs se mi jeste nezboril, tudiz ho nemuzu pochvalit ani zatratit. Kdyz mate UPS, tak si poskozenych FS moc neuzijete.
  • 29. 6. 2008 2:59

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 14:40

    qwerty (neregistrovaný)
    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?
  • 29. 6. 2008 16:40

    Lael Ophir (neregistrovaný)
    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.
  • 29. 6. 2008 22:26

    qwerty (neregistrovaný)
    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.
  • 30. 6. 2008 17:14

    Lael Ophir (neregistrovaný)
    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).
  • 1. 7. 2008 19:07

    ABC (neregistrovaný)
    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.
  • 1. 7. 2008 19:40

    Lael Ophir (neregistrovaný)
    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. 7. 2008 1:19

    qwerty (neregistrovaný)
    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. 7. 2008 17:56

    Lael Ophir (neregistrovaný)
    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)
  • 1. 7. 2008 19:10

    ABC (neregistrovaný)
    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?
  • 1. 7. 2008 19:36

    Lael Ophir (neregistrovaný)
    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.
  • 2. 7. 2008 13:32

    Lael Ophir (neregistrovaný)
    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.
  • 4. 7. 2008 7:59

    bez přezdívky
    Nič také ako zlý alebo dobrý neexistuje. Existuje len zlý pre sales manažéra distribujúceho klikátka čo najväčšiemu množstvu úradníkov alebo zlý pre programátora spracúvajúceho kvantá textov.
  • 4. 7. 2008 15:32

    Lael Ophir (neregistrovaný)
    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ě.
  • 4. 7. 2008 17:28

    anonymní
    Zdrojové kódy nie sú text?:)

    Nie, nemáte pravdu, na UI neexistujú absolútne požiadavky a kritéria, takto to nefunguje snáď v ničom na svete. Absolútne merítka existujú snáď len v hlavách ignorantov a autorít.
  • 5. 7. 2008 15:54

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 13:36

    ABC (neregistrovaný)
    Jenom dotaz: Windows NT 4.0 měly preemptivní jádro? Netvrdím, že ne, nevím, ale opravdu by mě to zajímalo.
  • 27. 6. 2008 13:37

    ABC (neregistrovaný)
    A možná se spíš diskutovalo o reentrantnosti než o preemptivnosti. Tak bych se zeptal i na tu reentrantnost.
  • 27. 6. 2008 17:17

    Lael Ophir (neregistrovaný)
    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).
  • 27. 6. 2008 18:08

    ABC (neregistrovaný)
    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.
  • 29. 6. 2008 17:25

    Lael Ophir (neregistrovaný)
    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.
  • 2. 7. 2008 9:13

    LENIN POWER! (neregistrovaný)
    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.
  • 27. 6. 2008 18:10

    ABC (neregistrovaný)
    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.
  • 25. 6. 2008 14:15

    ppp (neregistrovaný)
    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...
  • 24. 6. 2008 18:29

    Lael Ophir (neregistrovaný)
    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.
  • 24. 6. 2008 19:51

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

    Napiš si v notepadu soubor test.bat:
    ------------------------
    c:
    cd "\Documents and settings\lael\data aplikací"
    dir
    ------------------------
    a uvidíš :)

    No já teda nevím, ale systém, který neumí ani ve standardním editoru napsat batch, který se dostane do standardní systémové složky mi připadne trochu zbastlený :)))

    Ani nemluvě o tom, že existuje "zpětně kompatiblní" převod názvů souborů na 8.3, ale nemáš zaručeno pořadí, takže to velmi lehce dva soubory prohodí. Fakt dost dobrá featurka :)))) Tak to tam kurva nemá být, když to nefunguje!

    -----------------------------------------
    K testu:

    > Nebo si založte uživatele "František".
    Na Unixu Mac OS X jsem si založil uživatele se jménem 日本語. Založil se naprosto korektně a jde se k němu přihlásit. Home byl automaticky vytvořen jako /Users/nihongo :)))) (jsem ani nevěděl, že můj MacBook umí japonsky :)

    > Podívejte se také, jakým způsobem aplikace tisknou. Unixy používám jen v sebeobraně, ale nepřipadá mi, že by na tom tamní aplikace byly zvláště dobře.

    Podíval jsem se. Po připojení do firemní sítě se mi všechny sdílené tiskárny objevily samy v Bonjour. Všechny tiskárny používají stejný print dialog, všechny programy přez něj umí exportovat do PDF. Podle toho, jestli jsem doma nebo v práci se mi jako default nabídne ta tiskárna, která je k dispozici. Neotravuju se s dialogama "tiskárna neni připojená" ani s nekonečným čekáním na odstranění dokumentů z fronty nepřipojené tiskárny. Bohužel můj unix neobsahuje ani velmi oblíbenou feature Windows: jakmile je USB tiskárna připojena do jiného portu, objeví se jako nová a stará nezmizí, ale zůstane jako default...

    Nojo, holt asi o hodně přicházím...

    > Dostupnost aplikací, a zpětná kompatibilita, to je obojí obrovská deviza.
    Ano. Přesně proto předchozí verze Unixu MacOS X umožňovaly spustit aplikace pro devítku (úplně! jiný systém) v sandboxu = bez vlivu na nový systém, bez bastlení zpětné kompatibility.

    > si čtenář X stěžoval, že ve Vistě mu řada aplikací neběží. Na koho si stěžoval (nakonec nejen on)?

    Že by si stěžoval na to, že M$ své předchozí systémy tak posral, že musel pod tlakem okolností přistoupit k jejich posunutí ke standardu Unixu v sedmdesatych letech, a to za cenu způsobení problémů výrobcům SW, kteří nejsou ochotni své aplikace přepsat korektně?

    P.S.
    Narozdíl od C:\Winnt\$NtUninstallKB920670$
    mi /Applications/Cyberduck.app/Contents/Resources/zh_TW.lproj/Transfer.nib připadne teda obzvláště estetické :)
  • 24. 6. 2008 20:44

    Lael Ophir (neregistrovaný)
    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é :)
  • 24. 6. 2008 21:21

    M. Prýmek
    > Na prnvím místě si netykáme.

    A na druhém?

    > Je to nejlepší možné řešení zpětné kompatibility.

    Ano. Je to báječné! Sám, když se nudím, uložím si cvičně pár souborů v zastaralé CP, která je kompatibilní jen sama se sebou a pak si to spustím v exploreru. Stačím jen zavzdychat: "ach, ta krásná zpětná kompatibilita" a pak příjde ta nám všem známá exploze! (jednou jsem zkusil i Unicode, ale nebylo to ono...)

    (P.S. notepad mi nabízí jen ANSI a ruzne Unicody, CP1250 tam není. Asi teda standardní editor neumí editovat standardní "zpětně kompatibilní soubory"?)

    > S tím převodem na 8.3 názvy tomu nějak nerozumím.

    Mám adresář. Zabalím, rozbalím. Najednou stará aplikace nějak nejede. Schválně, kolik hodin budu šťourat všude možně, než zjistím, že se prohodily 8.3 názvy? Kolik peněz mě to stojí?

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

    Bohužel, Linux 8.3 nemá :)))

    > Mě Qt a GTK aplikace používají jiné dialogy, a OpenOffice ještě jiné :)

    Mě taky staré programy z dob 95, současné programy a programy v .NET používají jiné GUI :)

    > 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.

    Oceňuju to nesmírně! Často totiž k počítači připojuju dvě naprosto stejné tiskárny.

    Uklizečka vyhodí kábl. Blondýnce netiskne tiskárna. Co udělá správce? Zajede tam, koukne na to, asi čtvrt hodiny řeší, proč tiskárna, která je evidentně správně připojená tvrdí, že není připojená. Potom ho napadne, jestli to sakra zase nebyla uklizečka. A fakt že jo! Jenže kde ten kábl byl předtím? No to je jedno. Zrušit dokumenty ve frontě. Deset minut čekání, protože tiskárna je nedostupná. Možná restart, když dojdou nervy (snad proboha zase nespadne spoolsrv.exe). Přidat novou tiskárnu. Nezapomenout starou zrušit! Zůstala tam jako default! Uffff. Je to dobrý, uklízečka přijde zase až zítra ráno!

    Frustrující? Nikoli! Šáhnu do kapsy a vytáhnu krabičku Hulaninu. S potěšením žužlám kapsli a říkám si, jak je ten svět krásně plochý!

    P.S. v systému, který byl navržen pro více než 64kb ram, je tiskárna identifikována např. výrobcem a modelem... když by měly být dvě stejné (nonsens), můžu použít seriový číslo

    > Jde o adresář autora nějaké aplikace, a je jeho věc, jak si ho dál dělí do podadresářů.

    Nikoli. Jde o příklad nádherného standardu, který všichni dodržují. Konkrétně tady serializované GUI v činštině nebo čem. Žádná "plochá" prasárna s názvy, které jsou v každém jazyce jinak...

    ...a světe div se, žádný prasárny s tím nikdo nedělá, všichni dodržují standard - už od doby NeXTu nebo co...
  • 24. 6. 2008 22:56

    ABC (neregistrovaný)
    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.
  • 25. 6. 2008 3:22

    Lael Ophir (neregistrovaný)
    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í.
  • 25. 6. 2008 11:13

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 15:31

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 16:59

    ABC (neregistrovaný)
    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ý.
  • 25. 6. 2008 18:59

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 19:41

    bez přezdívky
    Nerad vám vstupuju do diskuse, ale mám tady hned několik zařízení na USB, kterým je úplně šumák, do kterého portu (včetně USB hubu) strkám kabel.

    Jde o:

    Tiskárnu Kyocera Mita FS 1010, tiskárnu Epson Photo 2100 a nějakou barevnou inkoustovku od Canonu
    Skener Canon (typ teď nevím, nejsem u daného PC) a skener Epson 4990 Photo
    Bluetooth dongle
    mobilní telefony Sony Ericsson K750i a V630
    GPRS modem (typ neznám, tuším, že to je nějaký "hujvej" - netuším, jak se značka píše a jsem líný googlovat)

    a asi i řadu dalších.

    Používané OS jsou XP SP2 a Vista SP1.

    Jediný problém byl s tiskárnou od HP, s USB-RS-232 konvertorem a hw klíčem k Best Color. HP v XP vyžadovala v jiném portu novou instalaci (ale firma HP bohužel nikdy neuměla udělat korektní driver), konvertor se v jiném portu ani nerozjel a hw klíč... no, nechám ho bez komentáře, zůstanu slušný. Ten totiž vyžaduje dlouhé woodoo při každém restartu daného PC.

    S tiskárnou HP problém zmizel ve Vistě (lze měnit porty), konvertor už nemá ovladače a Best jsem na Vistě nezkoušel (tedy ani klíč).


    Takže Windows sice mají jednoznačnou identifikaci, ale pokud není zprasený ovladač, tak se umějí rozhodovat celkem inteligentně a není pravdou, co říkal první diskutující, že je nutné vždy nová instalace daného zařízení a Windows umí přiřadit nový port ke stávajícím ovladačům.

    Občas se objevily informace o novém zařízení např. u myši či klávesnice, ale vzhledem k tomu, že zařízení bylo během několika vteřin funkční a např. u myši to zachovalo nastavení ovladače, tak to není problém.
  • 25. 6. 2008 23:04

    Lael Ophir (neregistrovaný)
    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.
  • 26. 6. 2008 23:34

    anonymní
    Tiskárny seriove cislo maji snad uplne vsechny. Jeste se mi nestalo, ze bych narazil na nejakou, ktera ho nema. Tim, ze to MS nepodporuje, tresta uzivatele.
  • 27. 6. 2008 1:18

    Lael Ophir (neregistrovaný)
    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á.
  • 25. 6. 2008 0:46

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 1:40

    M. Prýmek
    Obávám se, drahý Laele, že i kdybych se snažil nechovat jako idiot ze všech sil, tak úroveň této debaty nezvýším. Tato debata je totiž i tak celá dosti zhulanizovaná a jako taková vrcholně idiotská.

    > Tedy pokud z nějakého důvodu používáte 13 let staré .bat soubory

    Např. na w2k je to jediný jakžtakž normální zabudovaný skriptovací "jazyk" (dost silné slovo). Šílenosti typu VB, JS - děkuji, nechci.
    Co je na tom teda za "nejlepší možnou kompatibilitu", když to ani nezedituju?

    > Záleží to od konkrétního archivačního programu.

    Myslel jsem, že 8.3 vytváří automaticky systém. Pokud ano, nesváděl bych to na archiver, ale na M$ dípšit.

    > K testu: měl jsem na mysli zakládání uživatele.

    Samozřejmě. Dělal jsem si srandu. Nechápu totiž, o čem svědčí fakt, že v Linuxu jsou na jméno uživatele z historických důvodů kladeny jisté požadavky. (a samozřejmě i v tom MacOSu - proto to přetransponoval na ASCII)

    > Qt i GTK jsou dnes používané frameworky, a různé dialogy mají dnes psané aplikace.

    Ano. Stejně tak má jiné GUI dnes provozovaná Win32 aplikace a .NET aplikace. Co z toho jako plyne?

    > V té době vypadalo GUI na unixech tak, že by člověk zvracel.

    Ale, příteli Laeli, možná jste jenom nepřišel do styku s pěknými Unixy. Co třeba NeXTStep? Obávám se, že oproti němu byly Windows ubohá omalovánka: http://www.youtube.com/watch?v=j02b8Fuz73A (o podpoře multimédií ani nemá smysl se zmiňovat)

    > 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.

    Ne, to si nemyslím. Ale konkrétně u tiskáren každý normální OS považuje tutéž tiskárnu za tutéž nezávisle na portu. A kdyby byly dvě, tak je odliší třeba přidáním čísla... Chování Windows je v tomhle ohledu fakt ubohé. Nevím, kde je řečeno, že OS musí s tiskárnou zacházet stejně jako s USB diskem.

    > Plochá je vaše stará

    To je věcí názoru. Odkud se vlastně znáte?

    > zjevně jste vůbec nepochopil, jaký byl kontext slova "plochý"

    Ale pochopil. Jenom mi to přišlo jako Hulánovina největšího kalibru. Něco jako věta, kterou jsem dneska četl na patria.cz: "Chtěl říct, že když to klesá, tak je to vlastně dobře, protože to v podstatě roste." Neboli skloňujeme podle vzoru Hulán: "Já mám plochou organizaci souborů - ty máš bordel"

    (AKA 1. osoba: "Je supr, že licence Vist umožňuje dowgrade, spousta lidí to využívá" - 2. osoba: "chudáci zfanatizovaní uživatelé MacOSu už skoro všichni přešli na Leprda")

    > Sériové číslo tiskárny těžko můžete použít, blablabla, nálepka blablabla

    Možná si vygooglujte něco o udev na Linuxu a používání ID zařízení v něm a pak mudrujte.

    > Víte, že MacOS podporuje HFS+ a UFS? Asi ano.

    Dobrý odhad ;)

    > A víte, že HFS+ umí Unicode, je case preserving.

    Ne, to nevím. Já totiž vím, že při vytváření HFS oddílu si můžu VYBRAT, jak bude s velikostí písmen zacházet. A taky vím, že UFS je tam víceméně jen kvůli kompatibilitě s FreeBSD a pochybuju, že ho někdo soudnej používá...

    A víte vy, že Linux má EXT3, které má žurnál, EXT2, které nemá žurnál, CRAMFS, které je zkomprimované, ISO9660, které je jen pro čtení, VFAT, které stále spousta uživatelů Win používá a tedy podporuje prasárny a viry... ...a mnoho dalších jiných FS? A světe div se, každý z nich má jiné vlastnosti. Pejsek a kočička? Nevím. Já tomu říkám možnost volby. Ale možná vám vyhovuje výběr mezi NTFS a NTFS :)))

    > Co čekat od firmy, která tak těžce technologicky selhala.

    Jojo. Taky bych chtěl takhle selhat! Možná bych klidně selhal i někde trochu níž než na 152.74B USD tržní kapitalizace :))

    P.S. HulánEgo nedosáhlo samozřejmě ani těch silně přeceněných .5M Kč - nevíte o tom náhodou něco ;)
  • 25. 6. 2008 4:41

    Lael Ophir (neregistrovaný)
    .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ý.
  • 26. 6. 2008 23:45

    anonymní
    Kdyz se narazi na unix pro desktopy na normalni uzivatele, tak Vam MacOS a NeXTSTEP nevoni. Kdyz na servery, tak se Vam zase nelibi, ze nekdo chvali Solaris. Proc?

    Muzu Vam taky navrhnout test. Udelejte si adresar s milionem souboru a pak do nej pridejte treba 100 souboru nejakych zdrojovych kodu a pustte kompilaci. Porovnejte cas z win a linuxu.
  • 27. 6. 2008 1:47

    Lael Ophir (neregistrovaný)
    Ř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).
  • 27. 6. 2008 10:51

    anonymní
    Testuje to rychlost toho _uzasneho_ ntfs ve velkych adresarich. Pri kompilaci projektu s mnoha soubory to je dokonce poznat bez stopek, takze par sekund to nebude.

    Jestli myslite, ze za uspechem Win3.X stoji uzivatelsky komfort, tak se velmi pletete. V te dobe totiz uz existoval NeXTSTEP, ktery byl o nekolik generaci vyspelejsi. MS vyhral jen diky marketingu.
  • 27. 6. 2008 11:13

    M. Prýmek
    > MS vyhral jen diky marketingu.

    Jako ostatně vždycky... Nejen proti NeXTStepu, ale i proti OS/2. Otázkou je, jaký marketingový nástroj může nasadit proti opensource a internetovým službám :) - to je trochu jiný trh a M$ se zdá být trochu nepřipraven - možná podobně jako IBM na osobní počítače... Čas ukáže.

    Každopádně trh současné aktivity M$ moc optimisticky nevidí. Po Vistách mírné nadšení a nemírné ochlazení. Úspěchy roku 99 se zatím neopakují...
    Oproti Googlu a Apple je M$ trochu stagnující bratříček a fakt, že ani nezvládl akvizici Yahoo a šmejdí, kde může, aby koupil nějaký internetový projekt, taky o něčem svědčí...

    http://finance.google.com/finance?q=msft&hl=en
  • 27. 6. 2008 11:31

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 12:16

    anonymní
    Aplikace pro to byly. Schvalne se podivejte na nejakej fanouskovskej web. A tech aplikaci nebylo zrovna malo. Nebo si na youtube najdete video, kde S. Jobs predvadi zakladni vlastnosti systemu, nektere vychytavky nejsou ve win jeste ted.

    Ano, MS vyhral ne proto, ze by byli technologicky dobri, ale proto, ze dokazali dobre prodat tu jejich sra*ku (ano, ve srovnani s NeXTSTEPem to tak opravdu je) a ziskat tak postaveni na trhu.
  • 27. 6. 2008 12:26

    M. Prýmek
    Řekl bych, že hlavním motorem úspěchu bylo to, že M$ byl a je mistr ve vytváření vendor lock-in (ještě větší než Apple). Včechno to vlastně začalo tím, že se jim podařilo prorazit s příšerností DOS a posléze získat výhodný kontrakt s IBM. Od té doby jim už stačilo jen udržovat vendor lock-in na dostatečné úrovni, což se jim podařilo. Otázkou je, co bude dál...
  • 27. 6. 2008 12:36

    M. Prýmek
    Nebo se to dá říct ještě jinak: jakou mají Windows konkurenční výhodu kromě rozšířenosti? Byly by úspěšné, kdyby dnes začínaly?
  • 27. 6. 2008 17:20

    Lael Ophir (neregistrovaný)
    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ě.
  • 27. 6. 2008 18:11

    M. Prýmek
    LOL!

    To bylo v nějakým dost dobrým čísle Dikobrazu, ne?

    Bylo to to číslo, jak tam bylo, že 640kb musí stačit každýmu? Nebo v tom, jak byl Bill otcem Internetu?
  • 27. 6. 2008 13:44

    ABC (neregistrovaný)
    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.
  • 27. 6. 2008 17:26

    Lael Ophir (neregistrovaný)
    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.
  • 27. 6. 2008 18:03

    ABC (neregistrovaný)
    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
  • 27. 6. 2008 18:04

    ABC (neregistrovaný)
    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
  • 25. 6. 2008 0:44

    M. Prýmek
    Koukám, že čtu fakt nepozorně - vyberu si první špek a další ignoruju...

    > posunem k systému s textovým interfacem, plain text hesly, nepreemptivním kernelem, bez podpory GUI, grafiky a multimédií?

    pár kontrolních otázek:

    1. který systém měl první pořádnou podporu víceuživatelského přístupu a kdy? (tj. např. že měl VŮBEC NĚJAKÁ hesla, narozdíl od nejmenovaných systémů typu kalkulačka - držím ji, tak jsem její jediný uživatel)

    2. dtto - skutečný 64bit

    3. dtto - se začal používat pro zpracování grafiky na počítači

    4. dtto - zvuku

    5. dtto - uměl nějak pracovat se sítí

    6. dtto - uměl clustrovat

    7. dtto - měl virtuální paměť

    atd. atd.

    Tak nějak od boku bych řekl, že ani na jednu otázku není odpověď "Windows" a rozdíl mezi rokem, kdy se ta která feature objevila v prvním systému a ve Windows bych viděl průměrně tak na 15-20 let (snad kromě GUI, to stačili ukrást rychle).

    Stejně tak od boku, bych řekl, že se nám tam několikrát objeví slovo "Unix" (s nějakými těmi přídavky/odkrojky, ale "X" tam určitě bude několikrát :)
  • 25. 6. 2008 3:38

    Lael Ophir (neregistrovaný)
    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).
  • 25. 6. 2008 11:33

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 17:26

    JardaP (neregistrovaný)
    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.
  • 26. 6. 2008 23:26

    anonymní
    založte uživatele "František".
    Nevim jestli je todle v POSIXu, ale zcela urcite to odporuje RFC pro emaily. Navic todle muze udelat opravdu jen slaboduchy spravce, jak se pak treba Frantisek prihlasi k webmailu z dovolene z italie?
    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.
    Vyreseno velice dobre pomoci cups, staci pripojit tiskarnu a konfigurator se postara i o ziskani ovladace.
  • 27. 6. 2008 1:10

    Lael Ophir (neregistrovaný)
    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í).
  • 27. 6. 2008 1:23

    anonymní
    Se jmenem uzivatele? Prece uplne vsechno. Vzpomente si na vyznam znaku @. Uzivatel pepa ze stroje. pepa@stroj.

    Kdyz uz chvalite jak windows krasne umi mit jakekoliv znaky kdekoliv, tak si udelejte adresar <|> a ukladejte si tam ty Vase vymysly.
  • 27. 6. 2008 1:29

    anonymní
    Asi pred pul rokem jsme s notebookama s nekolika kolegy potrebovali v cizim prostredi tisknout. Vlezl jsem do ovladaciho centra KDE, dal zdetekovat tiskarny na siti a za pul minuty tisknul. Kolegove s windows si nejdriv museli tiskarnu prohlednout, vyhledat na internetu ovladace, a nainstalovat. Prvni z nich tisknul za 20 minut.
  • 24. 6. 2008 16:47

    Lael Ophir (neregistrovaný)
    Autoři píší aplikace mizerně, to je prostě fakt. Tou podporou idiotů máte na mysli něco konkrétního, nebo jen hospodsky žvatláte?
  • 24. 6. 2008 16:48

    Ondřej Tůma
    Pokud se adresare nazivaji v ceskych a v anglickych Windwos jinak - tak je to prasarna!

    Pokud se prejmenuji adresare a Visty je maji jinak, tak programator za to nemuze a pro pripad funkcni aplikace na obou systemech musi resit v podstate 2 varianty - nebo toto osetrit - pak to ale neznamena ze to na Vistach funguje stejne jako na XP!
  • 24. 6. 2008 17:08

    Lael Ophir (neregistrovaný)
    Vzpamatujte se.

    Například Start Menu je ve Windows řešeno jako sada adresářů. Pochopitelně "...\Programs\Startup" se v češtině jmenuje "...\Programy\Spustit po startu". Podobně "My Documents" jsou česky "Mé dokumenty". Jde samozřejmě o jména adresářů na disku, a samozřejmě jsou (teoreticky mohou být) odlišná v každé jazykové mutaci a v každé verzi Windows.

    SDK nepopisuje přímo cesty ("%USERPROFILE%\My Documents"), ale způsob, jak cestu získat (SHGetFolderLocation a další). Programátor naopak NESMÍ spoléhat na konkrétní název adresáře. Prasárna je spoléhat na to, že adresář dokumentů bude v "%USERPROFILE%\My Documents".
  • 24. 6. 2008 18:09

    Uživatelka si přála zůstat v limbu (neregistrovaný)
    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".
  • 24. 6. 2008 19:02

    Ondřej Tůma
    Budete se asi divit, ale ty soubory z teckou na zacatku maji na unixu svuj vyznam. A neni to tedy o tom jeee my sme hrozne UNIX ale my peceme na nejaky reseni jinyho nazvu souboru na win jen proto ze win takovy soubory nepouziva a stejne to funguje.
  • 25. 6. 2008 0:00

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 10:15

    Ondřej Tůma
    Tak windows a kódovaní je kapitola sama pro sebe. A vase argumentace ala obchazeni chyb je prirovnatelna k oknu. Ano de z nej skakat, pripadne s nim vlezat do domu / budovy. Ale obcas je to okno proste moc vysoko. Ovsem k tomu nam slouzi dvere. Win razi cestu kde obsah souboru prenasi do nazvu souboru. Ala ruzna zverstva se znaky v nazvu, jen se to nesmi posilat mailem, hlavne ne MS klientama, nesmi se to pokud mozno vypalovat na CD a uz vubec se to nesmi nahravat na web.
  • 25. 6. 2008 13:25

    Uživatelka si přála zůstat v limbu (neregistrovaný)
    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).
  • 25. 6. 2008 13:31

    Ondřej Tůma
    Ono to ale neni jen o cestine, ono je to i o specialnich znacich ala vykricniky, otazniky, zavorky atd... pak je to taky o delce souboru. A win nema jinou kodovou stranku nez linux, win ma vzdy vlastni kodovou stranku uz od DOSu. Divim se ze neprisli s vlastnim UTF.
  • 25. 6. 2008 15:41

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 17:57

    Rejpal (neregistrovaný)
    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. ;-))
  • 25. 6. 2008 15:39

    Lael Ophir (neregistrovaný)
    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.
  • 25. 6. 2008 18:05

    ABC (neregistrovaný)
    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.
  • 25. 6. 2008 11:36

    JardaP (neregistrovaný)
    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). :-)
  • 25. 6. 2008 11:52

    Ondřej Tůma
    Nevim jestli to jeste plati, ale totalne brutalni byl preklad SQL slova LIKE -> ASI. Takze dotaz pak vypadal VYBER jmeno KDE prijmeni JE ASI "Novák". Z toho by jeden fakt uchcaval :D
  • 25. 6. 2008 15:49

    Lael Ophir (neregistrovaný)
    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 ;)
  • 25. 6. 2008 18:17

    JardaP (neregistrovaný)
    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.
  • 24. 6. 2008 17:12

    krtko (neregistrovaný)
    Nekde nahore je to snad vysvetleny, ze kdyz se programator zachova spravne a natahne si adresar ze systemu a nespoleha na jeho pojmenovani, je mu vcelku jedno, jestli jde o ceskou ci anglickou variantu vist, resp. xp-cek, ne?
  • 24. 6. 2008 17:15

    M. Prýmek
    To není tak docela pravda. Je to totéž, jako kdyby unixový program spoléhal na "/home/$USER" místo $HOME. Např. na MacOS X by nejel ("/Users/$USER").

    ...což ale nic nemění na tom, že struktura "C:\Documents and settings\bill\Data Aplikací\Microsoft\Some F*cking App" je teda fakt síla :)))
  • 25. 6. 2008 11:40

    JardaP (neregistrovaný)
    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.
  • 25. 6. 2008 15:51

    Lael Ophir (neregistrovaný)
    Mezera snad nečiní problému. Windows admini na rozdíl od unixových adminů nesedí nad command line. Skoro by se chtělo říci, že unixoví admini datlují (typicky celé roky) zbytečné blbosti. Navíc je ve Windows doplňování. Takže c:\do[tab], a je hotovo.
  • 25. 6. 2008 18:23

    JardaP (neregistrovaný)
    No, jak kteri admini. Ja nad nim sedel docela dlouho. Ne zcela zdareny pokus zinventarizovat pristupova prava k shares na vsech serverech. Nejvice jsme ztroskotaval prave na tech mezerach. Programem se nedalo jednoduchym zpusobem rozpoznat, kde konci nazev cesty a souboru a kde zacina vypis prav. Mezera by mela byt v nazvech zakazana, i kdyz underscore vypada mene hezky. Dalsi humus pak byl, ze se prava vypisovala nekdy normalne a u nekterych adresaru v jakesi advanced podobe, kdy se kazde pravo, tak jak je kazdy zna, rozpadalo na radu detailnejsich prav. Programove zpracovani je pak docela humus.
  • 24. 6. 2008 17:58

    Lael Ophir (neregistrovaný)
    Hlavně předpoklad, že finální část cesty home adresáře je shodná s uživatelským jménem, je nesprávný. Vždyť to tak prostě nemusí být.

    Ta struktura adresářů ve Windows je náhodou celkem pěkná. "Documents and Settings" je trochu delší, ale zase to dobře popisuje obsah. Struktura adresářů odděluje dokumenty, nastavení, roamující a neroamující data (mailbox vs cache browseru). Na unixech to struktura adresářů bohužel neřeší.

    Mimochodem víte, že starší verze Firefoxu zapisovala cache jako roaming data? Slast pro každého uživatele roaming profiles :). Ono tam těch problémů bylo více. Nefunkční aktualizace, update jen reinstalací celého browseru atd. Ale naštěstí i Firefox se vyvíjí.
  • 24. 6. 2008 19:00

    Ondřej Tůma
    To co tu pisete je hola kravina. Zatimco na win musite resit domovsky adresar a k nemu jeste nejake "logicke" rozmisteni podadresaru.. tak na unixu mate jeden adresar .firefox a v nem mate vse co k ff patri. A nemusite pak hledat tu oblibene polozky, tu historii, tu mail, tu cookies atd... slast je napr. hledat na win data z MS Outlooku, pak z IE Outlooku, pak z IE atd...

    A domovsky adresar je preste ~ pripadne promena prostredi HOME. Ve vysledku ji snejne z 99% nepotrebujete vedet. To co ve svych prispevcich popisujete /a ne jen vy/ je migrace unixoveho SW na win, pravda je ale takova ze principy unixu proste nejdou s principama srovnat a tak tim trpi migrace. Ovsem ze tim musi trpet i migrace mezi jednozlivima verzema win .. nooo to je coool
  • 24. 6. 2008 20:07

    Lael Ophir (neregistrovaný)
    Plácáte nesmysly. Vysvětlím. Ve firmách je zvykem, že se přihlásíte k libovolnému počítači, a máte k dispozici svůj profil - třeba ty cookies a favorites. To proto, že se replikují změny se sítě. Při odhlášení se zase změny replikují na síť. To umí Windows už 10+ let. Samozřejmě některá data nemá smysl cpát na síť, třeba tu cache browseru. Proto existují adresáře, do kterých se ukládají roaming data, a adresáře, kam se ukládají noroaming data.

    To, že výše popsaný koncept neznáte, a připadá vám proto hrozně praktické mít všechno smíchané dohromady, to je primárně vaše chyba. A to, že tento koncept neznali lidé, kteří portovali Firefox, je zase jejich chyba. Naštěstí jim to už někdo vysvětlil.

    Sedl si vám někdo na hlavu? Migrace mezi jednotlivými verzemi Windows trpí jen tím, že autoři píší SW jako prasata. Nakonec kdybyste něco psal vy, dopadlo by to zřejmě příšerně, protože jste už ukázal, že nevíte, že nějaké roaming profiles existují. Možná byste i zapisoval nastavení aplikace do adresáře s executablem... Jak jsem to psal s tím ukazováčkem? ;)
  • 24. 6. 2008 20:38

    M. Prýmek
    A má to spoustu jiných výhod:
    * je to pomalé jako prase kdykoli, kdy je tam víc souborů
    * defaultně tam není možné umístit soubory s jiným vlastníkem než je ten, komu profil patří
    * když se člověk přihlásí na dvou počítačích zaráz, dostane po odhlášení těžko předpověditelný guláš
    a další!

    Ploše zdar!

    P.S. bojím se pomyslet na to, co se stane, když se člověk přihlásí pomocí cached credentials poté, co mu admin zrušil účet - jakápak překvapení nám nejplošší autorizace na světě poskytne? Doufám, že ne přístup ke všem shares, která měl uživatel před zrušením účtu? Bojím se to zkusit :)))
  • 24. 6. 2008 22:00

    Lael Ophir (neregistrovaný)
    Ano, je to pomalé jako prase, když například autoři Firefoxu nacpou cache do roaming dat.
    Ano, do profilu uživatele nepatří soubory s jiným vlastníkem, než majitelem účtu
    Ano, jeden člověk zpravidla pracuje na jednom stroji. Pokud pracuje na více strojích, dojde k mergování profilů na úrovni souboru. Těžko tvrdit, že je to guláš.

    Pomocí cached credentials se přihlásíte jen pokud nejste online. V takovém případě se těžko dostanete ke všem shares. Obecně přihlášení na stanici neznamená, že máte přístup na shares - zkuste si.
  • 24. 6. 2008 22:53

    M. Prýmek
    > Ano, je to pomalé jako prase, když například autoři Firefoxu nacpou cache do roaming dat.

    A když si tam uživatel nacpe svoje data, který tam z povahy věci patří, tak to pomalé není?

    > Ano, do profilu uživatele nepatří soubory s jiným vlastníkem, než majitelem účtu

    Zajímavé. A když bych např. chtěl zajistit, aby uživatel používal FF-profil, který má na H:\FF a žádný jiný, tak nesmím dát do profilu soubor, který to definuje a je vlastněný administrátorem? Škoda.

    > Ano, jeden [uživatel windows] zpravidla pracuje na jednom stroji. [protože to jinak neumí]

    Uživatelé Unixů naopak klidně zaráz používají:
    * vypalovačku na stroji vedle
    * GUI aplikaci ze serveru
    * Xkrát spuštěnou výpočetně náročnou úlohu na clusteru
    * pár ssh sessions na různý strany
    A světě div se, všude mají stejný $HOME :) a už nám to tak funguje pár desítek let :) Ale jinak jo, roaming je fakt úžasná věc :)

    > Pomocí cached credentials se přihlásíte jen pokud nejste online. V takovém případě se těžko dostanete ke všem shares.

    Vytáhnu síťový kábl, přihlásím se pomocí hesla, které už nemá být platné. Připojím kábl zpět. Skutečně nemůžu neoprávněně nabytou identitu použít (např. pro zápis do složky na public share, kam mám přístup jen na základě identity, kterou jsem "ukradl")? (říkám, nevím, nezkoušel jsem, jen mi z toho jde mráz po zádech - strach z neznámého :)
  • 25. 6. 2008 15:21

    K0zel (neregistrovaný)
    Nemůžete. Lsass sice použije při přihlášení cached credentials (pokud nebyly zakázány administrátorem), ale cílový server si bude vaše oprávnění ověřovat podle DC v okamžiku, kdy se pokusíte o přístup k share.
  • 25. 6. 2008 11:11

    jd (neregistrovaný)
    Roaming profiles ve windows je neco, co me budi ze spani uz radu let.

    Priklad? Plocha (Desktop)
    Pokud je plocha soucasti roaming profilu a uzivatele maji ten nestasny zvyk ukladat na plochu spoustu souboru (radove nekolik GB) ani se neptejte jak dlouho pak trva prihlaseni.

    Pokud je plocha standardni cestou smerovana na sitovy disk, z me dusud neodhaleneho duvodu uzivatel na plose sice muze vytvorit adresar ale z plochy se na nej nedostane. Veskera prava ma, pokud se na plochu podiva jako na adresar (pres Explorer nebo i jinak) tak se do podadresare dostane ale kliknutim na plose to nejde. Zadne chybove hlaseni zadne logy ani naznak proc by to nemelo jit a hledam uz to dlouho.
  • 25. 6. 2008 15:57

    Lael Ophir (neregistrovaný)
    Vyškolte uživatele, aby neukládali dokumenty na plochu. Od toho mají My Documents, stový disk, nebo ještě lépe nějaký DMS systém.
    Samozřejmě také můžete napsat skript, který přesune všechny dokumenty daných typů (včetně cesty) z desktopu do My Documents, a na desktopu nechá jen shortcut na My Documents. Pokud ho budete pouštět při přihlašování a odhlašování, ono je přejde ukládat dokumenty, kam nepatří. Drastičtější je vzít prémie tomu, kdo dělá blbosti, ale chápu, že se to blbě prosazuje.

    Nevím o možnosti přesměrovat standardně desktop na síťovou lokaci. Problém může být v tom, že Explorer může začít hrabat po adresáři příliš brzo během přihlašování. Zkuste si zapnout logování shellu.
  • 25. 6. 2008 19:23

    jd (neregistrovaný)
    Přesměrovat desktop na síťovou lokaci jde snadno:

    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
    "Desktop"="J:\\Plocha"
    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders]
    "Desktop"="J:\\Plocha"

    A s přihlašováním to má těžko něco společného. Ta složka nejde otevřít na desktopu už v okamziku vytvoření. Práva jsou OK, přes adresař se tam lze dostat. Zapnout logovaní shellu zkusím.

    PS: zakázat ukladání souboru na plochu jen proto abych udělal ústupek limitům OS to myslíte v roce 2008 vážně? I když souhlasím s tím, že je to pitomej nápad to tam ukládat.
  • 25. 6. 2008 19:29

    Lael Ophir (neregistrovaný)
    Jak limitům OS? Jak jsem psal, na dokumenty jsou My Documents, síťový disk, nebo DMS. Kdyby si uživatelé usmysleli, že budou ukládat dokumenty do tempu, tak to budete přesměrováním tempu na síť, nebo tak, že jim to vysvětlíte?
  • 26. 6. 2008 11:06

    jd (neregistrovaný)
    spusta programů z mě nepochopitelneho důvodu ukládá na plochu defaultně soubory, nechápu proč.
    Ale problém je jinde, proč by si uživatel na plochu nemohl ukládat? Ano není to dobrý nápad. Ano, já bych to neudělal. Ano dokumenty tam nepaří. Ale existuje jediný rozunmý důvod proč ne?
  • 26. 6. 2008 11:12

    M. Prýmek
    Důvod je naprosto stejný jako důvod proč nepoužívat v loginu diakritiku. Čili další pravidlo skloňování podle vzoru Hulán:

    "Já mám plochou organizaci souborů - ty máš bordel"

    "Já mám zpětnou kompatibilitu - ty máš zastaralé API"

    "Já uživatelům vysvětlím, že to nemají dělat - ty máš systém, který neumí použít diakritiku v loginu."
  • 26. 6. 2008 17:53

    Lael Ophir (neregistrovaný)
    Spousta aplikací nabízí k ukládání místo, kam jste ukládal naposledy. To může být i plocha.
    Samozřejmě plocha je adresář jako každý jiný, jde jen o věc house keepingu. Já mám někdy na ploše tolik souborů, že v nich musím přehrabovat v Exploreru, protože nejsou všechny ikony vidět :). Řešený problém byl ale primárně o roaming profiles. Pokud při užití roaming profiles má uživatel veliký profil, trvá přihlašování a odhlašování zbytečně dlouho, protože se synchronizuje lokální profil se sítí. Ve firmě samozřejmě uživatelé mají ukládat data na síť do správného adresáře, nebo do DMS. Nejhorší je, když jsou data na lokálním stroji, tj. bez zálohy, protože disky na klientech ve větší firmě odcházejí jak na běžícím pásu.
  • 26. 6. 2008 0:59

    M. Prýmek
    > zakázat ukladání souboru na plochu jen proto abych udělal ústupek limitům OS to myslíte v roce 2008 vážně?

    Ne. To je jenom předcházení chybám OS, které je typické pro Unixáky :))) (nebo jakže to Lael psal s tím unicodem v loginu? :))))
  • 24. 6. 2008 23:56

    Lael Ophir (neregistrovaný)
    Ještě jsem se zapomněl zeptat: jak řeší roaming profiles například Linux? Zvláště ve chvíli, kdy jsou dokumenty, nastavení, roaming a non-roaming data nasypaná pohromadě?
  • 25. 6. 2008 10:11

    Ondřej Tůma
    Na unixu mate takove veci jako symlink, hardlink, null mount a pod... pomoci tohoto se daji delat moc hezka kouzla.

    A ano daji se pomoci toho udelat neprehledna zverstva, stejne jako se pak takhle daji resit elegantne jakekoli pozadavky (jedna cast dat tam, druha tam, jak je libo).

    Ovsem to nejoblibenejsi napr. mezi unixari je mit nejake to /tmp misto namountovane v ramdisku - data se pak zpracovavaji velmi rychle, a po pripadnem restartu neobtezuji na disku.