Názory k článku
Microsoft vytvořil stabilizátor zrychlených videí

Umis ty vubec pocitat? Jiste bude kazdej doma nadsene prepocitavat 10 let svoje hodinovy video, aby se mu dopocitala scena ... jenom blba rekomprese muze trvat desitky hodin i na velmi vykonym HW ...

Navic to bude fungovat tak mozna na nejaky demo scene, ostatne stejne jako vektorizator bitmapy - funguje to epesne ... ovsem jen pokud ta bitmapa vypada dostatecne "hezky".

> Umis ty vubec pocitat? Jiste bude kazdej doma nadsene prepocitavat 10 let svoje hodinovy video, aby se mu dopocitala scena ... jenom blba rekomprese muze trvat desitky hodin i na velmi vykonym HW ...

O tom jsem ale vůbec nemluvil.

> Navic to bude fungovat tak mozna na nejaky demo scene, ostatne stejne jako vektorizator bitmapy - funguje to epesne ... ovsem jen pokud ta bitmapa vypada dostatecne "hezky".

To video točené z kola mi přijde jako normální reálné video (čti: umím vygenerovat podobné), žádný syntetický příklad.

A kolik rucnich zasahu a rucniho ladeni v tom je to samo netusis ...

Noční šichta místo Lajela?

"Malí umělci kopírují, velcí umělci kradou."

Tak to bylo a je. Chápu, že Microsoft tu není moc v módě, ale stejně tu za těch 15 let vidím pokroky. Už ubyly posměšky o stabilitě a silácké kecy, že ten jediný správný systém se vejde na disketu.

Každý přece ví, jak DOS vznikl... Ovšem každý ví, že nebyl ukraden a Gates nikoho nevydíral :) DOS byl legálně koupen, upraven a rozšiřován ;) Nevidím v podstatě logiku v tom, když Microsoft udělá MS-DOS a pro něj MS-Word, aby dělal MS-Word i pro DR-DOS, který je "kopií" MS-DOSu :D To bych mohl být naštvanej, že binární aplikace, kterou jsem spouštěl v UNIXu mi nefunguje ve FreeBSD :D Stejně jako nesmyslné tažení proti tomu, jaké mnou vytvořené aplikace bude mít mnou vytvořený operační systém - viz.
Je firma prohnilá od začátku i proto, že MS Word nefunguje v Linuxu?
Filozofie Billa Gatese je celkem jednoznačná - "Ačkoliv počáteční práce na programu trvaly jen dva měsíce, celý následný rok nám zabralo zlepšování a přidávání nových vlastností. Dnes mohu říct, že hodnota naší práce přesahuje čtyřicet tisíc dolarů a zpětná vazba od vás, uživatelů BASICu, nám potvrzuje, že jsme si počínali dobře. Škoda jen, že naprostá většina z vás ten program ukradla, neboť vidíte logiku v nákupu hardwaru jako je samotný Altair 8800, ale nechápete, proč by se mělo platit i za jeho software. Je tohle fér?"
V tom prohnilost nevidím ;) Když se podívám na Linux, všude vidím snahu něco kopírovat - inspirovat se :) GNOME u Apple, KDE u Microsoftu - kopie jsou to opravdu mizerné. Neznám jedinou kvalitní profi aplikaci, která by byla pro Linux.
To, jak vypadá byznys "free" je vidět na narůstajícím počtu aplikací, které jsou sice zadarmo, ale prosety reklamami skrz na skrz. Shodou okolností tento boom narůstá hlavně díky "otevřené" firmě goolge...

Ty zjevne neznas vic veci ... mimochodem, koukas na tv? 100% tech filmu je vyrabeno ... na linuxu. Zjevne pouzivaji nekvalitni aplikace. Rika ti neco trebas ... londynska burza? Nj, taky to bezi (stejne jako drtiva vetsina ostatnich) na nekvalitnich aplikacich pro linux. Kvalitni windowsi ji skorem polozily ... A trebas takovy nejvetsi urychlovac na svete ... ten taky bezi na nekvalitnich linuxovych aplikacich. Stejne jako 80-90% tvych paketu dorucujou po internetu nekvalitni linuxy.

Na TV sice nekoukám, ale na Linuxu se (některé) filmy rendrují - protože je to OS postačující pro rendrovací farmy a je zdarma. Modelování se většinou provádí ve Windows. Londýnská burza běží na Linuxu, protože si "doma" napsala s outsourcerem systém na platformě Windows, a ten byl příliš drahý a pomalý. Windows ji samozřejmě nepoložily, ani málem :). Byly tam výpadky, ovšem ty má i nový systém. Pakety často doručuje Linux, protože je zdarma, a ve světě internetu je cena pvořadá.

Působí to, že píšete o věcech, které znáte jen z titulku v nějakém linuxovém bulváru.

Come on, modelování se většinou provádí na Macu. Ono je to totiž jednoduché, buď chcete nízkou cenu, pak volíte Linux, nebo vysokou kvalitu, pak volíte Mac. Volba Windows je dnes již jen kulturní zvyk.

Já naopak myslel, že používání Macu je dneska už jen kulturní zvyk :)

Ne, není, obzvlášť když potřebujete takové zbytečnosti jako barevné profily. Jo, Windows to taky nějak umí (nakonec i Linux to umí), ale u Macu to máte hned po vybalení z krabice. Vždy.

Windows mají samozřejmě správu barev out of the box.

Dobře, správu barev má out of the box i Linux. Myslel jsem tím, že Windows ji nemají nastavenou, zatímco Mac se dodává již přednastavený.

Jak nastavený? Možná na konkrétní typ monitoru, pokud si koupíte se strojem. Profil by se vám ale ve Windows měl nastavit sám, pokud ho pro dané zařízení máte.

Mám tchajwanský monitor, a profil samozřejmě má.

Ne, jmenuje se podle výrobce a typu monitoru.

MacOS má velkou databázi ICC profilů, takže se většinou umí automaticky nastavit podle monitoru, který připojíte. Ve Windows to musíte dělat ručně. A pokud máte dva monitory, tak s Windows si musíte podporu naskriptovat.

Windows mají také velkou DB ICC profilů. Navíc i kdyby Windows neměly jediný ICC profil, a byl pouze dodaný s monitorem, nevidím v tom důvod používat MacOS místo Windows :)

Len v skratke.
Napriklad blender, digikam...
Ma ten uzasny ms ktory ma patent uz hadam aj na zachod nieco podobne??
Asi nie... Este aj program na defragmentaciu ich fs je lepsi od tretej strany.
Dalej sa nebudem rozpisovat.

A sam si napisal ze KDE je zla kopia ale nikde som sa nedocital ze by chceli skopcit nieco od ms. Mne ako pouzivatelovy uz dlhu dobu priklad KDE vyhovuje a nepotrebujem tam to co ma ms. Samozrejme vsetko ma svoje za a proti.
J

Pocitam, ze dnes se na tom nic nezmenilo, pry akorat interface.

GUI už v podstatě zmizelo, radši. Akorát se to dá tlačítkem spustit, pak už nevidíš nic.

Ked zrusili GUI tak som dost lutoval, vzdy mi to ukazalo pekne graficky ako mam zaplneny disk a hlavne kde su vadne sektory.

Hlášky při bootu si můžete v MSCONFIG aktivovat...

A co se tak na ten obrázek podívat pozorněji a nenechat se zmást tím, co je na něm zakroužkováno

Ono to bylo trochu jinak. Diskeeper umožňoval defrag NTFS ve Windows NT 3.51. Bohužel manipuloval přímo se strukturami FS, a když se jakkoliv změnily (nebo vám vypadlo napájení při defragu), mohl je poškodit. V NT 4 MS uvedl defragmentační API, které používají (doufejme) všechny defrag tools. Někdy v té době také licencoval technologii defragmentace od společnosti Executive Software, která psala defrag už pro systémy VAX. Od doby NT4 se dost změnilo. Například byla přidána podpora defragmentace MFT a dalších metadat, by default je plánovaná defragmentace na pozadí s nízkou prioritou I/O operací atd.

Ohledně toho že MS koupil program třetí strany a nenapsal ho sám: nevidím na tom nic špatného. Proč psát SW "doma", když může být rychlejší a levnější ho koupit? A zrovna příznivci open source, který masivně staví na tom že autoři používají kód napsaný někým jiným (nemluvě o "inspiraci"), by to měli uvítat.

Tak zrovna tu defragmentaci se Unixy učily ještě dost dlouho, a některé FS nemají online defrag dodnes. A když se podíváte na unixovou konkurenci, tak tam prakticky žádné utility nebyly. Žádný Stacker, žádná defragmentace, a file managery proti kterým byl File Manager z Windows 3.x rajskou zahradou.

MS vždycky stavěl na ekosystému autorů SW, a utility jsou dodnes silným trhem. Nechápu jak někdo může na jedné straně kritizovat zahrnutí MSIE ve Windows, a na druhé straně požadovat zahrnutí spousty utilit, jejichž psaní živilo a živí spousty malých firem.

Fragmentace je jev společný prakticky všem OS. Těch pár výjimek má zase "vychytávky" jako pevno velikost souboru apod., takže se na obecné používání moc nehodí.
U NTFT se stejně jako u unixových FS předpokládalo, že defrag nebude potřeba. A v obou případech potřeba byl. Na Unixech se to typicky řešilo tak že jste provedl zálohu FS na pásku, znovu ho vytvořil, a pak se modlil, aby úspěšně proběhnul restore :). To že některé unixové FS dodnes neumí online defrag je dané hlavně tím, že je technicky obtížné ho implementovat zpětně, a autoři často nemají dost prostředků ani na implementaci vlastního FS.

Nevidím důvod, proč by MS nebyl schopen to či ono sám napsat. Co by mu v tom podle vás mělo bránit? Lidí, know-how i kapitálu má spoustu. Ale v řadě případů je prostě levnější koupit technologii nebo firmu. Můžete tvrdit, že například Google není schopný napsat vlastní OS nebo vlastní Javu, a že je děsně neinvenční, když musel koupit už před 150 firem. Proč nekritizujete to, že Google jako webová firma koupilo Upstartle (později Google Docs), aby se naučil editovat dokumenty na webu? Je Google tak neschopný, že nedovede spatlat webovou aplikaci? Ne - prostě je jednodušší koupit kód,kus know-how a lidi.

Jo, Stacker, to byla fakt výhra. Zvlášť když se sesypal, což se stávalo nepříjemně často. Podobně ty memory managery byly velká výhra. Chcete síť? Jo, ale nefunguje s memory managerem A. Chcete CD-COM? OK, ale nejde s memory managerem B. Chcete si zahrát hru? Odstraňte memory manager, jinak nejspíš nepojede. Naštěstí se to časem ustálilo tak, že naprostá většina věcí fungovala alespoň s HIMEM.SYS, a většina i s EMM386.EXE.

MSIE vylepšoval funkcionalitu OS, stejně jako třeba file manager. Na jedné straně se vám nelíbí zahrnutí browseru do OS, na druhé straně byste chtěl zahrnovat lepší file manager a řadu dalších utilit, které nejsou pro chod systému nijak nutné, a jejichž psaním se živí řada firem, které by přišly o business. Fakt nevidíte inkonzistenci vlastní argumentace?

Přesně, po třech letech intenzivního vývoje (Git, spousta přesunů a přepisů souborů) a bez jakékoliv defragmentace:

sten@lychee ~ $ sudo e4defrag -c /dev/LVM/Data
<Fragmented files>                             now/best       size/ext
1. /home/sten/.local/share/akonadi/akonadiserver.error
                                               109/1              4 KB
2. /home/sten/.Skype~/DataRv/offline-storage.data
                                                96/1              4 KB
3. /home/sten/.Skype/DataRv/offline-storage.data
                                                96/1              4 KB
4. /home/sten/android/.git/modules/gui_shared/logs/HEAD
                                                16/1              4 KB
5. /var/log/auth.log.1                          16/1              4 KB

 Total/best extents                             1330430/1311756
 Average size per extent                        95 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/LVM/Data) does not need defragmentation.
 Done.

Windows můžou jen tiše závidět.

Btw. že zrovna Skype má problémy s fragmentací asi není překvapující :-D

Co mi tím chcete ukázat? Kdybyste měl podobnou fragmentaci na Windows a spustil si nějaký free defrag, nejspíš by vám vypsal fragmentaci 12.4% (326958/290850) a označil by ji jako vážný problém, s doporučením na koupi professional verze toho defragu :D. Navíc fragmentace FS velmi záleží na způsobu používání disku, na tom nakolik jste ho maximálně zaplnil atd.

Vám se Stacker nesesypal, já takových viděl několik.

Jestli vám s Quarterdeckem chodil Lantastic, neztuhnul driver CD-ROMu a chodily hry, byl jste šťastný člověk. Já s ním měl jen problémy.

MSIE vylepšuje OS stejně jako WordPad, dvoupanelový file manager nebo Calculator - umožňuje uživateli dělat víc věcí out of the box. Samozřejmě ani jedno nesouvisí s primární funkcí OS, kterou je poskytování abstrakce nad HW. Jenže dneska se OS dělají jinak. Koukněte se na distra Linuxu, nacpaná GB kravin.

Měl jsem Lantastic a Digital Pathworks, obojí mělo problémy s alternativním memory managery.

Můj WordPad umí nastavit řádkování. Samozřejmě je to velmi základní aplikace. Nicméně pointa je v tom, že na jedné straně chcete k OS přibalovat další nástroje které konkurují malým firmám, a na druhé straně totéž kritizujete.

Můj WordPad se jmenuje worpad.exe. NT4 tu nemám, a ve WordPadu jsem nikdy nic nepsal, takže nemožnost nastavit řádkování nemůžu potvrdit ani vyvrátit.

Co mi tím chcete ukázat? Kdybyste měl podobnou fragmentaci na Windows a spustil si nějaký free defrag, nejspíš by vám vypsal fragmentaci 12.4% (326958/290850) a označil by ji jako vážný problém, s doporučením na koupi professional verze toho defragu

Ve Windows je fragmentace velmi často výrazně vyšší i podle toho microsoftího nástroje.

To dost záleží na tom, jak ji počítáte. Navíc starší verze Windows komprimovaly například zálohy Service Packu na disku, a komprese uloženého souboru na úrovni FS samozřejmě vede k fragmentaci (cca jeden fragment na 64kB). Sice se vám tím zvýší fragmentace, ale zase získáte celkem dost místa na disku, což svého času bylo důležitější, než dneska v době TB disků.

Nevidím jediný důvod, proč by komprese uloženého souboru měla vést k fragmentaci, když se ten soubor nepřepisuje (což se u záloh určitě neděje).

Ta komprese se provádí po 16 blocích, a vede se k tomu seznam virtuálních clusterů. Důvod je vcelku zjevný: musíte zajistit možnost číst nebo přepisovat soubor zprostředka bez dekomprese celého streamu. Pokud vím, ukládají se data na původní místo, a mezi nimi pak zbývá volné místo.

Tak vidíte, kde je ten problém. Ne v samotné kompresi (nakonec btrfs tyhle problémy nemá), ale v tom, že nikoho v MS zřejmě nenapadlo, že když se kompresí mění délka dat, asi nebude úplně vhodné to ukládat na původní místo.

Nevím jak to řeší BTRFS, ale když budete alokovat komprimované bloky na nové místo, zvýšíte fragmentaci volného místa. Jde o volbu mezi A. přidáním fragmentovaného volného místa, s tím že nezasáhnete do existujícího volného místa, nebo B. menším počtem fragmentů komprimovaného souboru, ale vyšší fragmentací volného místa. Jak jsem už psal, každá alokační strategie je kompromis. Myslím že lidem v MS to vysvětlovat nemusíte. Na rozdíl od autorů unixových FS napsali už v půlce devadesátých let žurnálový FS s kvótami, kompresí, šifrováním, podporou velkých volumes i souborů, přístupem po síti atd., a doplnili ho o transakční zpracování, rezervaci přenosového pásma, online resizing, online defrag a další featury, takže o FS asi něco vědí :)

Co třeba tak, že po uložení prvního zkomprimovaného bloku uložíte druhý blok hned za ten první a ne na místo, odkud jste jej načetl? K žádné fragmentaci volného místa nedojde a navíc nebudete mít fragmentovaný ani ten soubor (a fragmenty volného místa uvnitř — co že jste to psal o fragmentaci volného místa?). Ale chápu, tohle je tak strašně těžké vymyslet, že ani profesionálové na FS na to nepřišli.

Upřímně nevím, jaká byla motivace autorů FS v roce 1993. Jestli chcete zkoumat detaily, napište nějaké testy pomocí toho API které jsem linkoval, a pak to můžeme vyhodnotit.

Alokační algoritmy nemají moc společného s tím, jaká byla motivace autorů v roce 1993. Sám moc dobře víte, že v každé verzi Windows jsou jiné. Přesto tohle pořád nějak nedokázali vychytat.

O kompresi nad NTFS vím jistě to, že rozděluje soubor do fragmentů po 15 clusterech. Pokud chcete tvrdit, že to autoři nevychytali, běžte napsat test za pomoci toho linkovaného API. To vám jasně řekne, jak je soubor fyzicky rozmístěný po disku.

To jste tvrdil vy, že to je důvod, proč NTFS tolik fragmentuje

Jestli to nebude tím, že unixové souborové systémy nikdy nebyly tak stupidní jako FAT, že alokovaly vždy první volný blok a proto při multitaskingu příšerně fragmentovaly. Moderní souborové systému pak používají online defragmentaci v podstatě jen kvůli COW či žurnálování. Tedy až na NTFS, který má alokační strategie vyvinuté snad v Oregonské státní nemocnici.

Zřejmě jste nikdy neslyšel o Demos Commanderu, což byl klon Norton Commanderu pro UNIXy. Ve srovnání s ním to byl naopak File Manager z Windows 3.x, co způsoboval příšená utrpení.

Ona se také implementace těch unixových FS nevejde do 512 bytů :). FAT je samozřejmě nevhodný pro systémy s paralelním zápisem, od toho je tu NTFS.

Ad NTFS... má alokační strategie vyvinuté snad v Oregonské státní nemocnici - co se vám na nich konkrétně nelíbí? V praxi mi přijde, že NTFS funguje velmi dobře, a popis alokační strategie vypadá celkem OK.

Ad Demos Commander - proč sem taháte nějaký klon Norton Commanderu s textovým UI? Koukněte se, jak vypadaly grafické file managery na Unixech v době Windows 3.x.

Ona se také implementace těch unixových FS nevejde do 512 bytů :)

Tam se ale nevejde ani implementace FAT, vejde se tam akorát možnost načíst z FAT soubor. A dovolil bych si tvrdit, že taková implementace UFS nebude o mnoho větší.

co se vám na nich konkrétně nelíbí?

Tak například to, že za každý soubor strčí malé prázdné místo a nový soubor alokuje hned za tím, místo aby soubory rovnoměrně rozkládal po disku. Nebo to, že všechna metadata cpe do jednoho souboru (MFT). To pak vede do takových situací, jako když soubor zapisovaný na disk, kam přistupuje jediný program, skončí po kontinuálním zápisu v několika desítkách či stovkách fragmentů. Tohle se snad nestávalo ani na VAXu.

proč sem taháte nějaký klon Norton Commanderu s textovým UI? Koukněte se, jak vypadaly grafické file managery na Unixech v době Windows 3.x.

Protože i tenhle textový správce souborů fungoval daleko lépe a lépe se ovládal než File Manager z Windows 3.x.

Ad za každý soubor strčí malé prázdné místo a nový soubor alokuje hned za tím - to je samozřejmě nesmysl. NTFS provádí při zápisu souboru pre-alokaci mnohonásobku velikosti požadovaného místa (dvoj- až šestnáctinásobku, tak to alespoň bylo ve WinXP).

Rovnoměrně rozkládat soubory po disku vede k tomu, že se velmi rychle zbavíte všech opravdu velkých kusů volného místa, takže větší soubory pak skončí jako řezanka. Navíc pokud zkusíte číst soubory zapsané cca ve stejném čase (tedy nejspíš používané dohromady), bude disk divoce seekovat.
MFT je sice jeden soubor, ale není nezbytně souvislý - i když se o to NTFS snaží. Podobně totiž pokud máte metadata roztroušená po celém disku, tak navigace mezi adresáři povede ke spoustě seekování. A to si uvědomte, že díky skvělému unixovému zvyku ukládat konfiguraci do souborů místo do DB máte například konfiguraci LibreOffice 4 v 96 adresářích(!). Fakt je chcete mít po disku roztroušené náhodně? To se pak nedivte, že vám čtení té konfigurace trvá daleko déle než na Windows (nemluvě o srovnání s Registry).

Napsat dobrý FS alokátor je někde mezi vědou a černou magií, a každá zvolená strategie je kompromis. Například to rovnoměrné rozkládání souborů po disku vám dá o něco nižší fragmentaci při menším zaplnění FS, ale o to větší fragmentaci pokud FS zaplníte víc. MS k tomu přistupuje odpovědně, sbírá v rámci různých data o tom jak zákazníci FS opravdu používají, a na základě toho optimalizuje.

Ad tenhle textový správce souborů - a nebyla náhodou řeč o utilitách dodávaných s OS? Srovnávejte srovnatelné: utilitu dodanou s OS proti jiné utilitě dodané s OS, a GUI proti GUI.

Ad za každý soubor strčí malé prázdné místo a nový soubor alokuje hned za tím - to je samozřejmě nesmysl. NTFS provádí při zápisu souboru pre-alokaci mnohonásobku velikosti požadovaného místa (dvoj- až šestnáctinásobku, tak to alespoň bylo ve WinXP).

Ano, prealokuje dvojnásobek délky prvního zápisu, což je typicky jedna alokační jednotka, a ty následné prealokace už nepůjdou udělat bez fragmentace, pokud mezitím jiná aplikace vytvoří jiný soubor, protože NTFS jej „chytře“ šoupne hned za ten první soubor. Navíc tu prealokaci provádí tak, že může být v až 128 fragmentech. WTF?

Btw. proč MS vydává dokumenty jako EXE? Pak se ani nelze divit, že uživatelé Windows ochotně spouštějí podobné „dokumenty“ z e-mailů.

Rovnoměrně rozkládat soubory po disku vede k tomu, že se velmi rychle zbavíte všech opravdu velkých kusů volného místa, takže větší soubory pak skončí jako řezanka.

Myslím, že se shodneme, že mít 20 MiB soubor v 10 fragmentech je z hlediska výkonu problém, ale mít 20 GiB soubor v 10 fragmentech je prkotina, těch deset seeků už vás moc zdržovat nebude.

Navíc pokud zkusíte číst soubory zapsané cca ve stejném čase (tedy nejspíš používané dohromady), bude disk divoce seekovat.

To samozřejmě lze optimalizovat jen pro takovou sadu souborů (a pro jednu aplikaci), jak to ostatně alokátor ext* dělá.

MFT je sice jeden soubor, ale není nezbytně souvislý - i když se o to NTFS snaží. Podobně totiž pokud máte metadata roztroušená po celém disku, tak navigace mezi adresáři povede ke spoustě seekování. A to si uvědomte, že díky skvělému unixovému zvyku ukládat konfiguraci do souborů místo do DB máte například konfiguraci LibreOffice 4 v 96 adresářích(!). Fakt je chcete mít po disku roztroušené náhodně? To se pak nedivte, že vám čtení té konfigurace trvá daleko déle než na Windows (nemluvě o srovnání s Registry).

V ext4 se žádná spousta seekování nekoná, metadata jsou buď v tabulce inodů nebo přímo v adresáři. Adresáře jsou pak indexované, takže v nich lze velmi rychle vyhledávat, a protože LibreOffice vytváří ty adresáře najednou, tak budou blízko u sebe.

Napsat dobrý FS alokátor je někde mezi vědou a černou magií, a každá zvolená strategie je kompromis. Například to rovnoměrné rozkládání souborů po disku vám dá o něco nižší fragmentaci při menším zaplnění FS, ale o to větší fragmentaci pokud FS zaplníte víc. MS k tomu přistupuje odpovědně, sbírá v rámci různých data o tom jak zákazníci FS opravdu používají, a na základě toho optimalizuje.

Zajímavé, MS k tomu přistupuje odpověděně a NTFS fragmentuje jak o život, zatímco vývojáři open source si to splácají doma a funguje jim to mnohem lépe.

Ad tenhle textový správce souborů - a nebyla náhodou řeč o utilitách dodávaných s OS? Srovnávejte srovnatelné: utilitu dodanou s OS proti jiné utilitě dodané s OS, a GUI proti GUI.

V UNIXech není problém používat v GUI konzolové nástroje i s myší, copy&paste či drag&drop úplně stejně jako jiné GUI aplikace, takže nevidím důvod je oddělovat. Že to ve Windows neumíte, neznamená, že to neumí nikdo jiný.

Ad prealokuje dvojnásobek délky prvního zápisu, což je typicky jedna alokační jednotka - na prvním místě jde o stav před 11 lety. Na druhém místě není důvod mít první zápis velkého souboru typicky menší než jeden cluster. Pokud soubor vytváříte, první request může klidně mít pár MB. Pokud ho kopírujete, na prvním místě vám CopyFileEx nastaví velikost cílového souboru stejnou jako u zdrojového, plus se používají I/O requesty s velikostí v MB, nikoliv kB.
Ad NTFS jej "chytře" šoupne hned za ten první soubor - fakt? Nic takového jsem v dokumentaci neviděl. Jestli vy ano, tak to sem hoďte. Jestli ne, můžete napsat test pomocí Defrag API C# wrappers (a nechat si u toho zdát, že byste měl něco podobného k dispozici na Unixech), a já slibuju, že si pak ten váš test sjedu.
http://blogs.msdn.com/b/jeffrey_wall/archive/2004/09/13/229137.aspx

Ad mít 20 GiB soubor v 10 fragmentech je prkotina - problém je v tom, že když máte po disku náhodně roztroušená data, tak nebudete mít ani ty 2GB souvislého volného místa. Když vezmu svůj disk (450GB, 180GB dat, 450k souborů), s vaším přístupem byste měl při ideálně souvislém ukládání souborů a zanedbání metadat a adresářů souvislé bloky o velikosti jen 630kB, výpočet (450G-180G)/450k. Když ten disk zaplníte stejným způsobem na dvojnásobek, tedy na 80% kapacity, bude souvislé bloky volného místa jen okolo 100kB. A to na disku, kde máte ještě 90GB volného místa, plus jsme zanedbali ta metadata, která chcete také ukládat po celém disku. Zkuste si pak vytvořit 1GB DB soubor - bude z něj řezanka. A se zvyšujícím se procentem zaplnění disku se to bude prudce zhoršovat. Je už jasnější, že umisťovat soubory náhodně po disku je nesmysl?

Ad protože LibreOffice vytváří ty adresáře najednou, tak budou blízko u sebe - aha, takže najednou se hodí mít metadata víc dohromady, a netrousit je náhodně po disku. A přitom jste ještě minule NTFS vytýkal, že se snaží je držet pohromadě.

Ad NTFS fragmentuje jak o život, zatímco vývojáři open source si to splácají doma a funguje jim to mnohem lépe - tak silné tvrzení by to chtělo podpořit velmi dobrými argumenty :)

Ad v UNIXech není problém používat v GUI konzolové nástroje i s myší, copy&paste či drag&drop - kupodivu to není problém ani ve Windows, vizte ENABLE_QUICK_E­DIT_MODE. A pokud chcete použít na konzoli myš jako pointer, stačí zavolat SetConsoleMode s ENABLE_MOUSE_INPUT, budete pak dostávat events. Nicméně původní pointa byla ta, že GUI nástroje instalované s UNIXy byly (a často nadále jsou) ve srovnání s Windows naprosto tragické, takže je pokrytecké Windows vyčítat, že neobsahovaly víc nástrojů v lepší kvalitě.
http://msdn.microsoft.com/en-us/library/ms685035(v=vs.85).aspx

Fragmentace 7% čeho? A pokud jsou to WinXP, nejspíš tam máte komprimované zálohy Service Packů, které fragmentaci zvyšují - ovšem pouze pro tu část disku, na které jsou uložené.

Osobně jsem se setkal s velkou fragmentací NTFS na desktopech jen u strojů, které měly silně zaplněný disk. Tam se tomu bohužel nevyhnete.

Jinými slovy nemáte data.

Ad presna data vam tezko dam - souhlas

Ad fragmentation score 1 - dokumentace k tomu říká následující: Get a current fragmentation count and an ideal fragmentation count, and calculate fragmentation score based on them. To mi přijde poněkud vágní. Navíc to nijak nepostihuje fragmentaci volného místa.

Ad procento, kere uvadi Diskeeper ve Widlich - opět nevíme k čemu se vztahuje.

Ad doporucuji defragmentovat, jakmile preleze 10% - tam je další otázkou, kdy vlastně defragmentovat. Zpočátku to jde celkem snadno, i když fragmentace nemá větší vliv na výkon. Když se fragmentace zvětší, je defrag daleko delší. Jak nastavit hranici?

Ad rekl bych tedy, ze Ext4, kde je typicky pouze par GB volneho mista, je na tom po peti letech intenzivnejsiho provozu lepe, nez NTFS po nekolika mesicich neintenzivniho provozu - 1. nemáte k tomu dost dat, 2. jak jsem už psal, ve WinXP máte nejspíš komprimované zálohy Service Packů, což zvyšuje fragmentaci, ale jen v prostoru, kde jsou ty soubory uložené.

Souhlas, Service Packy mohou být po čase větší než originální instalace. Zálohy stavu před patchováním můžete odstranit pomocí nástroje Disk Cleanup.

BTW na Ubuntu nemáte zálohy stavu před instalací patchů? Co děláte, když se chcete vrátit do stavu před instalací patche?

:) Nevím, jak to mají řešeno v Ubuntu, ale ve Fedoře na to mají řešení pomocí yum history - odkaz
Netuším, zda k tomu je i nástroj hodný OS pro 21.století...

Na RPM mi přijde vtipné hlavně to, že používá binární DB namísto konfiguráků, které uživatelé Linuxu podle zdejších diskusí považují za jedinou správnou cestu. Ohledně toho undo je problém v tom, že je nutné balíčky downloadovat, což v případě Service Packu není úplně dobrý nápad. Už Mach a Šebestová věděli, že bez brýlí se brýle špatně hledají :)

Téma apt pinningu se tu probíralo. Nebude lepší použít apt-undo? Podle popisu to vypadá, že to funguje obdobně jako yum history... koneckonců yum se dá doinstalovat i do ubuntu...

na prvním místě jde o stav před 11 lety. Na druhém místě není důvod mít první zápis velkého souboru typicky menší než jeden cluster. Pokud soubor vytváříte, první request může klidně mít pár MB.

Typicky třeba výstup z enkodéru videa, z multiplexeru, ze síťového proudu nebo i z kompresního algoritmu (OOXML) nemá bloky o velikosti několika MB.

Pokud ho kopírujete, na prvním místě vám CopyFileEx nastaví velikost cílového souboru stejnou jako u zdrojového, plus se používají I/O requesty s velikostí v MB, nikoliv kB.

Takže pokud tomu FS řeknete, že bude mít soubor tolik a tolik dat, tak je dokáže naalokovat nefragmentované. Hmm, to asi musí být hodně komplexní algoritmus :-)

fakt? Nic takového jsem v dokumentaci neviděl. Jestli vy ano, tak to sem hoďte. Jestli ne, můžete napsat test pomocí Defrag API C# wrappers (a nechat si u toho zdát, že byste měl něco podobného k dispozici na Unixech), a já slibuju, že si pak ten váš test sjedu.

V dokumentaci to není, je to vidět z obrazu disku defragmentačních utilit. Soubory vytvořené po sobě různými aplikacemi jsou za sebou.

Proč bych si o tom měl nechat zdát? Vidím kód, který importuje nějaké funkce z kernel32.dll. V Linuxu použijete libext2fs (třeba i v Pythonu), nebo pokud to chcete naskriptovat v shellu, tak ex4defrag umí podávat informace o jednotlivých souborech. Jaký je v tom rozdíl?

problém je v tom, že když máte po disku náhodně roztroušená data, tak nebudete mít ani ty 2GB souvislého volného místa. Když vezmu svůj disk (450GB, 180GB dat, 450k souborů), s vaším přístupem byste měl při ideálně souvislém ukládání souborů a zanedbání metadat a adresářů souvislé bloky o velikosti jen 630kB, výpočet (450G-180G)/450k. Když ten disk zaplníte stejným způsobem na dvojnásobek, tedy na 80% kapacity, bude souvislé bloky volného místa jen okolo 100kB. A to na disku, kde máte ještě 90GB volného místa, plus jsme zanedbali ta metadata, která chcete také ukládat po celém disku. Zkuste si pak vytvořit 1GB DB soubor - bude z něj řezanka. A se zvyšujícím se procentem zaplnění disku se to bude prudce zhoršovat. Je už jasnější, že umisťovat soubory náhodně po disku je nesmysl?

Ty data nejsou roztroušena náhodně, ale organizovaně. Pokud máte soubor, který je zavřený a od vytvoření se nezměnil, asi se měnit nebude a můžete šoupnout další hned za něj. Nicméně pokud máte soubor otevřený pro zápis, asi nebude zrovna ideální strčit další soubor od jiné aplikace hned za něj.

aha, takže najednou se hodí mít metadata víc dohromady, a netrousit je náhodně po disku. A přitom jste ještě minule NTFS vytýkal, že se snaží je držet pohromadě.

Pohromadě máte ta metadata, která se pravděpodobně budou používat najednou. NTFS rve dohromady všechna metadata bez ohledu na to, kdy je kdo bude používat.

tak silné tvrzení by to chtělo podpořit velmi dobrými argumenty :)

Co třeba těmi měřeními fragmentace, které jsme zde uvedli?

kupodivu to není problém ani ve Windows, vizte ENABLE_QUICK_E­DIT_MODE. A pokud chcete použít na konzoli myš jako pointer, stačí zavolat SetConsoleMode s ENABLE_MOUSE_INPUT, budete pak dostávat events. Nicméně původní pointa byla ta, že GUI nástroje instalované s UNIXy byly (a často nadále jsou) ve srovnání s Windows naprosto tragické, takže je pokrytecké Windows vyčítat, že neobsahovaly víc nástrojů v lepší kvalitě.

Kupodivu to problém je, protože v Linuxové konzoli funguje copy&paste či drag&drop i bez nějakého nastavování, myš funguje i přes SSH a taková terminálová aplikace funguje i tam, kde žádné GUI není (hodně štěstí při spouštění aplikace používající SetConsoleMode v DOSu).

GUI nástroje v UNIXech byly tragické, protože nebyly potřeba, zatímco ve Windows byly tragické a navíc jste neměl moc na výběr.

Ad výstup z enkodéru videa, z multiplexeru, ze síťového proudu nebo i z kompresního algoritmu (OOXML) nemá bloky o velikosti několika MB - pokud jsou bloky menší, je předalokace pomalejší. Enkodér videa by měl na začátku odhadnout velikost souboru, vydělit ji řekněme čtyřmi a změnit velikost souboru, protože to pomůže alokátoru. Kopírování souboru z UNC (tedy přes redirector) používá velké bloky, takže tam problém nehrozí.

Ad pokud tomu FS řeknete, že bude mít soubor tolik a tolik dat, tak je dokáže naalokovat nefragmentované - ne nutně, ale má k tomu lepší podmínky, protože může rovnou vybrat dostatečně velké souvislé volné místo. Pokud naopak budete zapisovat 10GB soubor (a pokud váš FS umí soubory nad 2GB :)) stylem "1kB, a ještě 1kB, a ještě 1kB...", tak alokátor neví jak bude soubor ve finále velký, a bude daleko víc fragmentovat.

Ad je to vidět z obrazu disku defragmentačních utilit - kde to vidíte na cca 600 indikátorech na celý disk, tj. s úžasnou cca 1GB přesností. Jo, to je jasný finální důkaz, že NTFS zapisuje soubory bezprostředně za sebe, tedy někdy, a plus minus 1GB :D. Zkuste si to API a otestujte si, kam NTFS skutečně ty soubory ukládá.

Ad Proč bych si o tom měl nechat zdát? Vidím kód, který importuje nějaké funkce z kernel32.dll - jedná se dokumentované defragmentační API, ke kterému máte i návod k použití. Funguje na přimountovaném FS, a nad různými FS (nevím jak to funguje nad Ext2Fsd).
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363911(v=vs.85).aspx

Ad pokud máte soubor otevřený pro zápis, asi nebude zrovna ideální strčit další soubor od jiné aplikace hned za něj - na tom se jistě shodneme. Ale jak daleko ho umístit? Když ho umístíte příliš daleko, zbytečně zvýšíte fragmentaci volného místa, a dojedete na to až se FS trochu zaplní. Když ho umístíte moc blízko, zvýšíte pravděpodobnost, že ten předcházející otevřený soubor budete fragmentovat.

Ad pohromadě máte ta metadata, která se pravděpodobně budou používat najednou - budoucí použití těch metadat dost těžko poznáte. Každopádně když držíte metadata pokud možno pohromadě, ušetříte si spoustu seekování.

Ad třeba těmi měřeními fragmentace, které jsme zde uvedli - jenže to byste musel mít srovnatelná čísla, a FS použitý srovnatelným způsobem. Nesrovnatelná čísla z odlišně používaných FS mají nulovou vypovídací hodnotu. FYI tohle mi vypisuje defrag C: /A /V:
...
Fragmentation:
Total fragmented space = 2%
Average fragments per file = 1.05
...
Free space:
Free space count = 31016
Average free space size = 8.26 MB
Largest free space size = 207.06 GB

Master File Table (MFT):
MFT size = 501.50 MB
MFT record count = 513535
MFT usage = 100%
Total MFT fragments = 3
Jde o SSD, takže na něm defrag nikdy neběžel.

Ad v Linuxové konzoli funguje copy&paste či drag&drop i bez nějakého nastavování - ve Windows funguje drag&drop. V cmd.exe a powershellu to hodí do konzole jméno přetahovaného souboru, v aplikaci to co autor aplikace zamýšlel (upřímně - většinou nic moc, protože konzolové aplikace ve Windows jsou většinou prostě řádkové, na UI máme GUI). Copy&paste by default není zapnuté, protože stačí když si uživatel klikne do okna, a snadno tam vloží třeba 1MB textu z clipboardu, který se pak snadno provede jako příkazy. Proto se to zapíná v nastavení pro pokročilé :), resp. ve vlastnostech okna.
Ad terminálová aplikace funguje i tam, kde žádné GUI není - jo, ještě byste měli držet podporu děrných štítků pro případ, že není ani ten terminál ;)
Ad hodně štěstí při spouštění aplikace používající SetConsoleMode v DOSu - aplikace pro DOS jsou pouštěné pod konzolí vytvořenou cmd.exe, a SetConsoleMode si nastavujete ve vlastnostech okna. Vám pro změnu přeji hodně štěstí při spouštění 20+ let konzolových aplikací na dnešním Linuxu, nemluvě o používání myši v nich :)
Ad GUI nástroje v UNIXech byly tragické, protože nebyly potřeba - jistě, protože ty hrozny jsou stejně kyselé :)
Ad ve Windows byly tragické a navíc jste neměl moc na výběr - nemyslím. Koukněte se na XTree for Windows (GUI), ZTreeWin (klon XTree na Win32 konzoli), Norton File Manager (GUI), Far Manager (klon Nortonu na Win32 konzoli) atd. Plus byla k dispozici samozřejmě spousta aplikací pro DOS, některé se dokonce kvůli Win95 naučily dlouhé názvy.

Je poněkud rozdíl, pokud aplikace nefunguje na jiném systému (widle > linux), protože jsou oba systémy naprosto odlišné, a pokud někdo ZÁMĚRNĚ sabotuje spuštění aplikace na jinak kompatibilním systému (MS DOS > DR DOS).

K těm kvalitním aplikacím přidám: RenderMan Pro od Pixaru, Autodesk Maya, Autodesk SoftImage, Guitar Pro, AfterShot Pro, Lightworks, Kingsoft Office (nově WPS Office, BTW zvládá poměrně slušně MS Office formáty, řekl bych že lépe, než LO), IBM WebSphere, WebLogic, Ardour, Renoise.........

DR DOS přece nepochází z dílny Microsoftu...je to jen pokus o kopii ;) proč by tedy Microsoft měl podporovat jiný systém? :)

MS jej sice nikdy nepodporoval, ale vložil do Wordu explicitní podmínku, že pokud detekuje, že běží na DR-DOSu, tak vyhazuje hlášky o chybách, které se nestaly.

Vy neumíte číst? Chápete, co znamená "záměrně sabotovat"? Ten pokus o kopii byl rychlejší, měl lepší správu paměti, v jádře zabudovanou ochranu adresářů heslem, propracovanou historii příkazů, atd... přesto byl levnější a nepamatuji si, že by byl problém s něčím jiným, než s aplikacemi od M$.

"David Cole and Phil Barrett exchanged emails on 30 September 1991: " "It's pretty clear we need to make sure Windows 3.1 only runs on top of MS DOS or an OEM version of it," and "The approach we will take is to detect dr 6 and refuse to load. The error message should be something like 'Invalid device driver interface.'" Microsoft had several methods of detecting and sabotaging the use of DR-DOS with Windows"

http://www.theregister.co.uk/1999/11/05/how_ms_played_the_incompatibility/

Výčet z několika málo důvodů pro soud, které vyjmenovala společnost Caldera... ;)

• Microsoft úmyslně vytvořil nekompatibilitu za účelem vyřazení DR DOS z trhu
• Microsoft zablokoval produktu Novell přístup k Windows 3.1 beta, aby zabránil vytvoření kompatibility mezi DR-DOS a Windows 3.1 beta - a to považte, že se mluví o Betě ;-)
• Microsoft protiprávně provázal dva odlišné produkty, MS-DOS 7.0 a Windows 4.0, aby vytvořil Windows 95 a vyloučil tak DR-DOS a tím omezil možnost volby zákazníků

Pořád tu ale nevidím něco protiprávního. Mám produkt a někdo vytvoří stejný... Proč bych měl ten jeho podporovat? Co je na tom protiprávního? Jak může někdo diktovat, co já budu dělat s vlastním produktem? Pokud ho někdo nechce, tak ho logicky nemusí používat. Přece nemohu nutit výrobce motoru, aby fungoval na benzín i na naftu jen proto, že je to přece motor ;-) Nebo nutit výrobce automobilu, aby do automobilů umožnil dávat i motory jiných firem ;-) Kecy o monopolu, kecy o protiprávném provázání vlastních produktů... Dnes tu máme linux a ne že by byl zrovna kompatibilní s MS produkty, a jaká je základna uživatelů tohoto "lepšího systému zdarma"??? Uživatel měl vždy možnost volby a má ji i dnes ;)

"Jinak s vlastnim produktem si delej, co chces, ale neprodavej ho. Protoze omezovat zakaznika a nutit mu, jak ma tvuj produkt pouzivat, je prinejmensim nemoralni, pravdepodobne pak protipravni."
Obchod neboli komerce či prodej je lidská činnost, která spočívá ve směňování zboží nebo služeb za peníze, případně za jiné zboží nebo služby. Setkávají se zde nabízející, kteří chtějí směnit za peníze, a poptávající, kteří za ně chtějí získat nějaké nové zboží. Cílem prodejců je maximalizace ceny, zatímco kupující si přejí pravý opak, cenu co nejnižší. Na trhu se tyto protichůdné zájmy střetávají, k transakci dojde pouze v případě, že obě strany jí získávají (jde o dobrovolnou směnu). Nabízející si musí cenit obnosu, který mu kupující nabízí, více než prodávaného zboží. Naopak kupující musí preferovat dané zboží před smluvní částkou peněz. Jestliže jsou obě podmínky splněny, pak dojde k obchodu. Na trhu není nedostatek OS a u žádného uživatele nestojí někdo s pistolí řka: "Kup si Windows a fofrem vole nebo mi selže pistole!"
Uživatelé dostávají to, co chtějí. Byl tu pokus, kdy výrobce dodával PC či notebook primárně s nainstalovaným Linuxem, ale tak něják to nebylo rentabilní... Nelíbí se Android, nelíbí se mi, že zákazník za své peníze dostává bastl, ale co můžu dělat je to, že ho prostě nebudu kupovat ani doporučovat. Současné postavení MS je pouze důsledkem toho, že uživatelům dává to, co potřebují.
MS vzdy vyvijel nejvetsi usili na poli hazeni klacku pod nohy konkurenci, mnohem mene na poli kvality. Vysledkem je to, ze cele odvetvi desktopu je deset let za tim, kde mohlo byt a na vyber jsou v podstate jen tri OS.
Google v tomto není taky pozadu a v podstatě na každé firmě najdeme kousek té "dravosti"
Neni to napriklad tak davno, co web fungoval prakticky jen v IE, prestoze zrovna IE i standardy jadro moc nelamal a byl plny bugu do takove miry, ze kazda stranka obsahovala hafo hacku, aby to v IE fungovalo, jak ma.
No vidíte a dnes v tom zoufalém množství prohlížečů, které si také nedělají starost se standardy a jsou plné bugů můžeme za IE děkovat ;)

Nikdo tu nenutí výrobce motoru, aby fungoval na benzín i naftu. Ale nevím, jak byste se tvářil na to, kdyby ten motor fungoval jen na předražený a nekvalitní benzín prodávaný výrobcem motoru, přičemž jakýkoliv jiný benzín by se snažil detekovat, a i přestože by na něj bez problémů jezdil, elektronika by odmítala s takovým benzínem startovat. A přidejte k tomu to, že by šlo o výrobce motorů pro všechny hlavní automobilky. Ale jistě, pokud by vás to štvalo, mohl byste si místo S-kového Mercedesu, Lexusu LS, šestkového BMW nebo Phaetonu koupit Ladu ;-)

Cítím tu analogii - Motor je HW(PC/Notebook...) a benzín je SW :)
Tedy z vašeho pohledu - "Ale nevím, jak byste se tvářil na to, kdyby ten motor fungoval jen na předražený a nekvalitní benzín prodávaný výrobcem motoru, přičemž jakýkoliv jiný benzín by se snažil detekovat, a i přestože by na něj bez problémů jezdil, elektronika by odmítala s takovým benzínem startovat." - MS tedy vyrábí předražené a nekvalitní věci.
Pak tedy jednoduše nemusíte jeho benzín kupovat a používat. Na trhu je přece dost kvalitnějšího benzínu.
Z dané analogie mi ale zní, že chcete benzín míchat :) chcete DR-DOS a funkční tedy vlastně předražené a nekvalitní věci na DR-DOSu provozovat...
Trh je otevřený každému. Je to o nabídce a poptávce. Procento uživatelů produktů Microsoftu jasně hovoří za své - raději platí za kvalitu, než berou šmejd zadarmo...

Cítíte to špatně, motor je Windows a benzín je DOS. Oboje je SW.

"Pořád tu ale nevidím něco protiprávního."

Tady nejde o protiprávnost, tady jde o to, že takovéto praktiky jsou prostě nečestné.

"Proč bych měl ten jeho podporovat?"

Tak jestě jednou naposledy: jde o záměrné sabotování jinak naproto bez problémů fungujícího OS.

Ta vaše analogie je úplně mimo, dám vám lepší: 90 % cest patří nějaké společnosti, která za provoz na nich inkasuje peníze. Stejná společnost vyrábí auta. No a ta společnost se rozhodne ty své cesty upravit tak, aby na nich jezdily jen ta její auta. Nelíbí se? Vždyť přece nemusíš jezdit autem, můžeš použít vlak nebo bus. Co na tom, že potřebuješ převézt něco těžkého, nebo že do tvého cíle žádný bus ani vlak nejede. Hlavně, ze máš na výběr ;-)

Ad takovéto praktiky jsou prostě nečestné - to si pletete komerční firmy s charitou. Konkurenční boj nespočívá v tom, že si firmy vycházejí vstříc. Naopak si házejí klacky pod nohy.

Ad společnost se rozhodne ty své cesty upravit tak, aby na nich jezdily jen ta její auta - to je dost nesmyslné přirovnání, protože cesty jsou veřejné a placené z daní. Kdo má soukromou cestu na soukromém pozemku, samozřejmě na ní může zakázat (nebo povolit) jakýkoliv provoz.

Jedna věc je konkurenční boj mezi firmami, druhá nucení zákazníka ke koupi svých produktů záměrným kryplením a sabotováním tak, aby zákazník nemohl konkurenční produkt použít, i když by jinak mohl. O to horší je to v případě, že firma má silně dominantní postavení.

Ty cesty byl samozřejmě příklad. Speciálně tedy pro vás: představte si, že 90 % cest patří nějaké firmě...

Hm, a jaký je podle vás důvod, proč například společnost Sun tradičně vybavovala svoje stroje proprietárními konektory, takže jste nemohl použít ani standardní monitor? Proč Apple používá místo microUSB svoje vlastní konektory? Proč jsou kazety s inkoustem od každého výrobce jiné, a často vybavené čipy? Důvod je pořád stejný: konkurenční boj.

Jak jsem psal, cesty jsou veřejné a placené z daní. Pokud si představíte, že jich 90% patří jedné firmě, tak si představujete neveřejné cesty, na kterých může ta firma zakázat nebo naopak povolit cokoliv. To je takový rozdíl proti veřejné cestě, že všechny příměry s tím spojené nutně pokulhávají na všechny tři nohy.

Je sice pěkné vědět, jestli někdo podle vás je nebo není šulín, ale nic to nemění na faktu, že výběr konektoru je (resp. před regulací EU byl) čistě na výrobci, a že výrobci nekompatibilní konektory, tonery a tiskové kazety s čipy apod. zcela používají v konkurenčním boji.

Cesty jsou placené z daní a na obecní půdě. Windows jsou psané soukromou firmou z jejich prostředků. Jistě je vám jasné, že se svým majetkem můžete nakládat jinak, než s majetkem obecním.

Špatně. Mohl bych sem zkopírovat svůj příspěvek slovo od slova, protože jste zase nepochopil, včetně toho, že s těmi cestami jde o smyšlený imaginární příklad, kde vůbec nejde o nějaké vlastnění cest, ale o princip. Já jsem svoje řekl a na tom si trvám. Evidentně jste zde jediný, kdo to nedokáže pochopit.

Chápu o jaký princip vám jde, ale váš smyšlený imaginární případ ten princip nijak neilustruje. Cesty jsou veřejné, a proto oprávněně nechceme, abychom na nich mohli jezdit jen vozem jednoho výrobce. Vy postavíte příklad s cestami v soukromém vlastnictví, a ukazujete na něm, že cesty jsou pro všechny a firma si s nimi nemůže dělat co chce. Jenže kdyby byly cesty soukromé, tak by si s nimi firma mohla dělat co chce, a asi by vám to nepřišlo nijak divné - byl by to majetek té firmy, stejně jako vaše zahrádka je váš majetek. To vaše srovnání prostě nefunguje, protože tam chybí paralela.

Samozřejmě že ilustruje. Že vy to nevidíte je tak nějak váš problém. Zřejmě nemáte dostatek fantazie, že se to pořád snažíte aplikovat na současný stav. BTW kdyby 90 % cest bylo v soukromých rukou JEDNÉ společnosti, buďte si jist, ze by si s nimi nemohla dělat, co ji napadne. To samé platí v jistých případech i dnes, říká se tomu věcné břemeno.

Věcné břemeno je něco trochu jiného. Navíc cest z bodu A do bodu B existuje omezený počet, a jejich stavba je velmi drahá. V IT je naopak počet OS prakticky není omezený, a vydat vlastní OS může kdokoliv s minimálními vstupními náklady. Nakonec OS píšou často i studenti.

Není důležité, že vecné břemeno je něco trochu jiného, důležité je, že si v tomto případě majitel nemůže s tou věcí dělat, co ho napadne.

Pro vstup OS na trh existuje obrovská bariéra, už jsme to tady probírali a vy zase dokola píšete ty samé nesmysly, že OS píší studenti. Takže OPĚT pro vaši informaci: nestačí napsat nějaký OS, jsou potřeba další věci, jako drivery, aplikace, alespoň nějaká kompatibilita či interoperabilita s jinými rozšířenými OS...

Ad v tomto případě majitel nemůže s tou věcí dělat, co ho napadne - jenže jak jsem psal, stavba cest je mnoha faktory omezená, kdežto psaní OS nikoliv.

Ad OS píší studenti VS nestačí napsat nějaký OS, jsou potřeba další věci, jako drivery, aplikace, alespoň nějaká kompatibilita či interoperabilita - ty další věci přece nejsou potřeba pro to, abyste vstoupil na trh. Samozřejmě pokud chcete být na tom trhu úspěšný, musíte nabídnout něco víc než současní hráči, a to může být náročné. Nicméně vstoupit na trh a vyhrát konkurenční boj jsou dvě dost odlišné věci. Tu druhou vám nezaručí nikdo.

No a co? Na principu to nic nemění.

"ty další věci přece nejsou potřeba pro to, abyste vstoupil na trh"

Jenom blázen půjde na trh s něčím, o čem má stoprocentní jistotu, že bude naprosto neúspěšný. Takže i nadále platí to, že pro SMYSLUPLNÝ vstup nového OS na trh existuje obrovská bariéra.

Pro smysluplný vstup třeba na trh automobilů nebo wide-body aircrafts jsou potřeba daleko větší investice.

LOL :-D Děláte, jako kdyby to bylo jen o penězích a srovnáváte nesrovnatelné. Na tohle trollování už nebudu dále reagovat.

Ano, Sun měl vlastní konektory a DOS měl vlastní API. Ale je dost zásadní rozdíl mezi tím mít vlastní konektory či API a záměrně se snažit neumožňovat používání stejných konektorů či API jen proto, že je vyrobila konkurence.

A s jakým záměrem asi Apple nebo Sun zavedli ty vlastní konektory (které jsou minimálně u Applu licencované)? Samozřejmě proto, aby zavedli odlišnost, která ostatním výrobcům ztíží či znemožní jim konkurovat. Z toho samého důvodu mají tiskárny nekompatibilní inkoustové kazety a tonery, a minimálně ty inkoustové kazety si často výrobci vybavují čipem. Podobně je to s baterkami a řadou dalších věcí.

Pokud jde o Windows 3.1, které nefungovaly na DR-DOSu, tak ty také nedetekovaly string DR-DOS. Místo toho prováděly operace závislé na interních strukturách MS-DOSu. A týkalo se to navíc jen beta verze Win3.1; v ostré verzi se žádné takové ověřování neprovádělo.