Intel pracuje na 48jádrovém procesoru, bude za pět až deset let

"Metro mi přijde na ovládání prstem naprosto v pohodě."
S tím souhlasím. Ale desktop silně převládá a tam je jen na obtíž. BTW, Gnome 3, KDE 4 netbook mode, Unity a Metro se orientují na dotyk. Jakoby někdo zapoměl na dominanci desktopu. :/

"Závilosti řeší od roku 1999 Windows Installer, před tím byly jiné techniky."
Proto mám ve Windows jednu a tu samou knihovnu (zlib) asi 10x.

"Mountování ISO souborů je pomocí externích utilit"
Ano, typická vlastnost Windows. Abych to mohl používat, potřebuji tisíce malých pochybných prográmků.

Kde převládá desktop? Pokud hovoříte o Windows 8, tak ty samozřejmě desktop potřebují. S Excelem, administrací Active Directory, Adobe Illustratorem nebo Visual Studiem budete těžko pracovat prstem.

Ve Windows máte zlib přesně tolikrát, kolikrát ji autoři zahrnuli jako nesdílenou komponentu. Za to Windows Installer fakt nemůže :)

Kdežto distro Linuxu je tvoří pár GB takových "pochybných prográmků".

"Kde převládá desktop?"

Čeho je víc - desktopů nebo tabletů?

"Ve Windows máte zlib přesně tolikrát, kolikrát ji autoři zahrnuli jako nesdílenou komponentu. Za to Windows Installer fakt nemůže"

To ale uživatele vůbec nezajímá :) Zajímavé, že v linuxu se to neděje...

"Kdežto distro Linuxu je tvoří pár GB takových "pochybných prográmků"."

Ty jsou ale open-source - takže žádné pochybnosti nejsou. Kdežto Windowsí junksoft je většinout closed-source, kdoví jestli neobsahuje viry, atd.

"Dnes, nebo zítra?"
Spíše "letos, nebo až za deset let?"

Zatím je výrazně více desktopů. Do budoucna se předpokládá nárůst podílu touch input zařízení. V řadě případů to ale nejsou klasické tablety. Na tabletu je totiž díky absenci klávesnice obtížné napsat i email delší než "přijdu pozdě".
http://www.youtube.com/watch?v=t0OLEgCbmVc

Uživatele vůbec nezajímá, že aplikace používá zlib. Když jsme u balíčkování na Linuxu, tak uživatele naopak velmi zajímá, jestli aplikace poběží na jeho konkrétním systému. V případě Linuxu musí mít uživatel balíček pro konkrétní verzi konkrétního distra, nebo se připravit na větší či menší problémy. Tohle mi přijde jako dost daleko větší problém.

Ty utility bývají digitálně podepsané, což zajišťuje identifikaci autora a vylučuje modifikaci obsahu.
U open source nejsou pochybnosti? Nenechte se vysmát. V oficiálních repozitářích nenajdete mnohdy ani MP3 přehrávač. U neoficiálních repozitářů zase nevíte z čeho to kompilovali a kolik malwaru do toho přidali. Výhodou je leda to, že pro to 1% uživatelů se zřejmě moc nevyplatí psát malware. Na příkladu Androidu můžete ale vidět, že s větším rozšířením platformy přichází exploze malwaru.

"Zatím je výrazně více desktopů."
A proto nechápu, proč se všude kurví prostředí a přesměrovává se na tablety. Nechápu prostě, vždyť rozšíření tabletů potrvá dlouhé roky.

"V případě Linuxu musí mít uživatel balíček pro konkrétní verzi konkrétního distra"
Ještě jsem takový problém neviděl a v úplně nejhorším případě to bude jako na Windows ;)

"Ty utility bývají digitálně podepsané"
hahahah :D :D Tak jedna z tisíce :D

"vylučuje modifikaci obsahu."
Možná to nevíte, ale u linuxových repos se také používají podpisy. Jenže máte zdrojový kód, u Windows nevíte, co tam autor přidal za bordel.

"V oficiálních repozitářích nenajdete mnohdy ani MP3 přehrávač"
Zajímavé... Já jich vidím asi 30.

"U neoficiálních repozitářů zase nevíte z čeho to kompilovali a kolik malwaru do toho přidali"
99% software získáte v oficiálním, kde jsou zdrojáky u každého balíčku. Takže opět. V nejhorším případě je to jako na Windows :D

"Na příkladu Androidu můžete ale vidět, že s větším rozšířením platformy přichází exploze malwaru."
Tak u androidu se google vůbec nezajímal o bezpečnost, je to vidět už jen z návrhu systému.

Počítače dnes nahrazují televizi a rádio. Používají je všichni od dětí po důchodce, a obsah často jen pasivně konzumují. Na to jsou tablety velmi dobré.

Fakt jste takový problém neviděl? Já ano. A s Windows bych to nesrovnával. Na Windows 7 (32-bit) spustíte i aplikace psané pro Windows 2.0.

Když si stahujete binární balíček, zdroják nemáte. Můžete si zdroják stáhnout, ale bohužel nevíte, jestli sedí s tím binárním balíčkem. A dostupnost zdrojáku vám také nepomůže, protože než byste zkontroloval jeden build OpenOffice, měl byste čas na důchod. Nehledě na to, že naprostá většina lidí ty zdrojáky luštit neumí, natož aby v nich uměli najít díru.

Google se o bezpečnost staral stejně mizerně, jako Microsoft u Windows Phone. Bohužel cílové skupiny uživatelů desktopu vs telefonů mají dost odlišná očekávání i dost odlišné znalosti počítačů.

Jo, tablety jsou pro opice: www.youtube.com/watch?v=HXtM97uQtAo

A Wosmičky pro děcka: http://www.webpronews.com/windows-8-bears-a-strong-resemblance-to-aol-kids-circa-1996-2012-06

Takže už je jasné odkud ty dlaždice ukradli ;-)

No vida, už tam máte to (32-bit), i když špatně napsané. Ale to je známé, že M$ neustále kurví normy, a to i ty které ostatním sám vnutil.

Ale naprostá většina lidí má 64 bitů, a na tom jim to chodit nebude (leda pod DOSBoxem, který je navíc stabilnější), kolega po několikadenním snažení rozběhat dvaatřicetibitový program pro XP ve čtyřiašedesáti­bitových W7 radši do počítače nainstaloval druhé dvaatřicetibitové sedmičky, ve kterých to šlo.

Jsou lidé kteří ty díry najít dovedou, dělají to, a strašně je to baví. Některým to i docela slušně vynáší, jako tomu maníkovi co nedávno už podruhé našel díru v Chrome...

Klasické GUI se ovládá prstem fakt špatně. Metro vychází ze Swiss Style, a dlaždice můžete najít všude možně od monitorů bezpečnostních kamer, přes menu televizí, až po Windows 8.

M$ neustále kurví normy, a to i ty které ostatním sám vnutil - pět konkrétních příkladů potěší, tři postačí.

Nicméně asi víte, že objevování bezpečnostních děr nevyžaduje zdrojáky. Vtipné jsou hlášky o údajné vyšší bezpečnosti open source díky dostupnosti zdrojáků. Ukazuje se, že ty zdrojáky ve skutečnosti téměř nikdo mimo vývojový tým nečte. Nekoná se žádné security review na komunitní bázi. A konkrétní příklady aplikací jako Firefox, Sendmail, Exim4 a dalších rozhodně pro podobnou teorii nesvědčí.
http://www.root.cz/zpravicky/nahradi-debian-z-bezpecnostnich-duvodu-exim4-postfixem/

2) No tak chlubit se windowsi zpetnou kompatibilitou chce odvahu.
http://www.gamefaqs.com/boards/924432-psi-ops-the-mindgate-conspiracy/51760855
Tahle hra je novejsi nez XP, ale na Win 7 uz nejde LOL (99% lidí se v tom hrabat fakt nebude)

3) Gentoo? SRPM? AUR? Myslim, ze deb to taky podporuje.

"Můžete si zdroják stáhnout, ale bohužel nevíte, jestli sedí s tím binárním balíčkem."
Nic porovnávat nemusíte, když se vám zkompiluje na místě (nehledě na výkonostní boost - to na Windows neznáte, co? :D)

"A dostupnost zdrojáku vám také nepomůže"
Alespoň máte tu možnost - na Windows ne. Navíc těžko u nějakého velkého projektu (KDE, kernel, GLibC) utajíte backdoor/malware, protože na něm pracuje obrovské množství lidí. A u menších projektů taky - pokud by měla knihovna ncurses závislosti na libcurl, openssl, atd. tak by to bylo dost podezřelé - a bez toho toho moc neodešle. Krom toho existují možnosti jak omezovat aplikace, co můžou a nemůžou provádět (takže všem můžu zakázat práci se sítí kromě firefoxu a je to)

4) "dost odlišné znalosti počítačů."
Jó, za neznalost se platí...

2) Windows mají špičkovou, v oboru jinde nevídanou, zpětnou kompatibilitu. Vámi linkovaný problém je zřejmě způsobený domršeným instalátorem. Windows jsou ale holt otevřený systém, MS aplikace neschvaluje a nemá moc jejich autory k čemukoliv donutit. Já osobně bych autorům SW za podobné prohřešky sekal prsty. Jenže autoři (zvlášť open source aplikací) by museli psát brčkem drženým v ústech :)

3) Ano, můžete strávit zbytek života luštěním zdrojáků, které za pět minut překompilujete. Super výhoda :). Ke zdrojáku komerčních aplikací samozřejmě také existuje přístup, pokud se s výrobcem domluvíte. Ale asi vám ho nedají jen abyste měl co dělat doma po večerech.
K překladu na místě: ve Windows tohle není potřeba. Můžete si všimnout, že MS SW je v release verzi pravidelně výrazně rychlejší a úspornější než v beta verzích. Důvodem je optimalizace. Profilerem (a mozkem) zjistíte, které části kódu jsou výkonově kritické. Ty pak obecně optimalizujete. A kde je to potřeba, optimalizujete pro konkrétní rozšíření instrukční sady, velikost cache atd. V některých případech z toho vyleze více verzí kódu, a ta pravá se pak vybírá při zavedení knihovny/aplikace. Zajímavou ukázkou je i optimalizace int 2e/sysenter z WinXP, vizte link.
http://www.summitsoftconsulting.com/SysCallOpts.htm
Pokud si někdo myslí, že kvalitní optimalizaci lze plnohodnotně nahradit překladem na místě, tak se mýlí.

Nejjednodušším způsobem podstrčení malwaru je změna binárního nebo zdrojového balíčku. Samozřejmě pokud už chcete backdoor propašovat do zdrojáku, odpustíte si závislost na openssh :), a prostě použijete sockets. BTW ve Windows samozřejmě také můžete aplikaci omezit, například pomocí Mandatory Integrity Control.

4) Děsí mě představa, že bychom produkty navrhovali jen pro lidi s důkladnou znalostí problematiky (o absenci návrhu v open source komunitě můžeme mluvit někdy jindy). Každý závozník a taxikář by musel umět nejen vyměnit klínový řemen, ale také udělat generálku motoru... Počítače jsou jen nástroj, stejně jako auta nebo psací stroje. U telefonů to platí dvojnásob.

2) Si snad děláte legraci... To byl jeden příklad z milionu.
3)
"Ke zdrojáku komerčních aplikací samozřejmě také existuje přístup, pokud se s výrobcem domluvíte."
Ale u OSS ho mám vždy, nemusím se někoho doprošovat.

"Pokud si někdo myslí, že kvalitní optimalizaci lze plnohodnotně nahradit překladem na místě, tak se mýlí."
Kecy. O nahrazení nebylo ani slovo. Na linuxu můžete dělat co na Windows + kompilace optimalizovaná pro daný procesor. To je prostě plus oproti Windows - to nezakecáte. Každý tvůrce software chce aby běžel na co nejvíce počítačích (co nejvíc zákazníků). Takže (na windows) pápá SSE4, AVX, ...

"Samozřejmě pokud už chcete backdoor propašovat do zdrojáku"
A jak poznám, že Windows samotná nejsou spyware ? :D

4) Jistě, však já s vámi souhlasím. To je ale ve všech odvětvích. Když nerozumím zákonům, můžu se dostat do právních problémů, atd. Pak se lidi nemůžou divit, že když otevřou soubor foto.exe tak tam je virus :D

"Uživatele vůbec nezajímá, že aplikace používá zlib."
Jistě, uživateli je to jedno. Pár desítek GB na disku sem, pár desítek GB tam. O RAM ani nemluvě...

Zlib má 133kB. Když spustíte všech deset aplikací, které si táhnou zlib s sebou, pořád všechny kopie zlib zaberou o řád méně RAM, než jeden tab Facebooku otevřený v browseru. A jak jsem už psal, mít vlastní kopii sdílené knihovny je bad practice.

Tak zlib není jediná taková knihovna. Krom toho je to prostě ZBYTEČNÉ.

"A jak jsem už psal, mít vlastní kopii sdílené knihovny je bad practice."
Ano to je, ale popřemýšlejte proč se tak děje. Je to proto, protože na Windows není žádný systém trackování závislostí. Kdyby se prostě nainstaloval zlib x.y aplikací A, a potom bychom nainstalovali aplikaci B (se závislostí na zlib), tak by se mohli zkontrolovat potřebné verze. Je nainstalována vhodná verze => využít zlib z aplikace A. Není nainstalovaná správná verze (nebo tam vůbec zlib není) => přidat ji do systému (a aplikace C může využít tu z A, B nebo zase vlastní)

Takhle jednoduše by se to dalo celkem slušně zredukovat.

Proč dochází k duplikaci zlib? Na Linuxu máte "oficiální" balíček zlib pro danou distribuci. Pro Windows ale neexistuje žádný oficiální build zlib, autoři uvolňují jen zdroják. Když autor aplikace potřebuje použít Deflate kompresi a nemůže či neumí použít .NET namespace System.IO.Com­pression.Defla­teStream, tak si zkompiluje svoji vlastní binárku zlib, vlastním compilerem, s vlastními volbami (s ASLR bez bez, s debug symboly nebo bez atd). Výsledek pak zahrne mezi soubory své aplikace.

Kdyby mělo smysl používat zlib na Windows (vizte výše - smysl to nemá), tak by autoři zlib měli vydat oficiální Win.x32 a Win.x64 build, s verzováním, debug informacemi a manifestem. Pak by knihovna zlib mohla fungovat jako sdílená. A kdyby navíc zabalili výsledek jako Windows Installer Merge Module, bylo by to úplně nejlepší. Nakonec takhle se distribuují XML Core Services, Crystal Reports, MSDE, VBA SDK a velká spousta dalších věcí.

Právě proto to nemá smysl, přece :-D

Souhlas, v takové výjimečné situaci se může zlib hodit.

"Singularity se navíc zabývaly mixováním managed a unmanaged code."

Prostě zase další BASIC, mrkwošroti se z toho Gatesova svrabu nikdy nevyhrabou :-D

Co se té kopie linuxových repozitářů týče, tak tu jste vidět nemohl, jen hodně ubohou téměř nefunkční napodobeninu. Akorát se spoustou barviček a reklamního hype, takže frikulíni obojího pohlaví s prázdnými makovičkami si z toho ucvrnkou do prádla.

Další vaše lži komentovat nehodlám.

"několika kliknutí jsem to doinstaloval.
Ano, ale to funguje jen na pár moftích produktů.

To je standardní feature Windows Installeru. Těžko samozřejmě autorům vnutit násilím její používání.

Opět, zajímavé, že to tak na Linuxu funguje... A komunita přitom jako celek nemá žádné vedení.

Na Linuxu se vychází z online distribuce software, a z dotahování závislostí třetích stran. Funguje to poměrně dobře, pokud máte připojení k netu a balíčky ve verzi pro konkrétní verzi konkrétního distra. Ve Windows je důležitá i distribuce aplikací na médiu (CD/DVD), aplikace musejí fungovat v budoucích verzích Windows, a musejí fungovat i pokud dodavatel nějaké komponenty přestane existovat. Jde o odlišné modely distribuce SW, které reagují na odlišné požadavky a odlišné podmínky.

BTW: Tak na Linuxu není žádný problém mít repozitář i na CD/DVD.

Aha, a proto mám doma 14 CD s kompletní distribucí Debian. Že by to šlo i bez netu?

Nikde jsem netvrdil, že to bez netu nejde.

Prostě zase další BASIC - to mi přijde bez informační hodnoty, slabé i na flame

Systém distribuce aplikací na Linuxu a na Windows vychází z velmi odlišných předpokladů, takže pochopitelně pracuje odlišně.
Windows Installer podporuje instalaci s GUI i bez GUI, s možností volby adresáře, výběru komponent a custom dialogů a akcí (instalace servisu-daemona, zadání jména serveru a ověření jeho verze, vytvoření DB apod). Akce prováděné instalátorem se generují dynamicky podle voleb uživatele, seberou se do seznamu, zjistí se jestli je opravdu lze provést, a pak se aplikují, s možností vrácení celé instalace do předchozího stavu při selhání jakékoliv akce. SW se obecně distribuuje jako rozdíl mezi čistým OS a nainstalovanou aplikací, protože jinak by nebylo možné dodávat SW na CD/DVD.
Balíčkovací systémy na Linuxu umí rozbalit primitivní archiv do předem daného adresáře, spustit u toho shell script, a samozřejmě vynutit závislost na jiném balíčku. Funkčně je to nesrovnatelně chudší alternativa.

"Balíčkovací systémy na Linuxu umí rozbalit primitivní archiv do předem daného adresáře, spustit u toho shell script, a samozřejmě vynutit závislost na jiném balíčku. Funkčně je to nesrovnatelně chudší alternativa."

Aha, tak pán viděl jen nějakou první verzi Slackware. LOL

Rád se nechám poučit. Přišlo mi ale vtipné, že zdejší diskutéři ve všech diskusích hrozně bojovali za textové konfiguráky, a binární databáze systému rpm jim nevadí.

Jen do jednoho adresáře? Já bych řekl že do mnoha adresářů, podle toho co je kde potřeba, navíc bez povinného restartu. A díky závislostem neuvidí při spuštění programu jen okno s textem chyby, že jim něco v systému chybí :-D
Máte fakt hodně zastaralé informace, neexistuje zdaleka jen RPM...

Nic jako povinný restart není ani ve Windows. Pochopitelně pokud jsou soubory zamčené, bez restartu je nezměníte. To jde jen na Linuxu, kde to má velmi zajímavé (čtěte negativní) důsledky.
Ano, zdaleka neexistuje jen rpm. Mohli bychom aplikaci pro danou platformu jednou přeložit, zabalit do jednoho formátu, a fungovalo by to všude. Ale my jsme řekli ne. Pro 1% uživatelů přece nemůže stačit jeden balíček dané aplikace. Je třeba pěkně napsat víc nekompatibilních balíčkovacích systémů, a balíčky ať jsou pěkně závislé na konkrétní verzi konkrétního distra.

Jaké negativní důsledky má možnost změnit soubor za běhu aplikace, kromě toho, že v Redmontu nemají programátory, kteří by to dokázali napsat?

Mějme DB soubor a nad ním běžící engine, který používá worker procesy (tj. čas od času nastartuje nový proces). Teď nahradíme na disku soubory toho engine, nebo nějaké knihovny, které používá. Chvíli poté budete mít v paměti dvě různé verze, a aplikace o tom ani nebude vědět.
Mějme aplikaci typu Gimp nebo OpenOffice, která používá resources a dynamicky nahrává za běhu pluginy. Nyní nahradíme binárku, resources i pluginy novými verzemi. Pluginy mají novější interface, některé resource jsou přidané a jiné zmizely. Bohužel v paměti máme původní binárku, takže se nám aplikace sesype jako domeček z karet.
Takových situací jistě sám vymyslíte víc. Jak se tenhle problém na Linuxu řeší? Prostě se neřeší. Spoléhá se na to, že se zrovna náhodou nic špatného nestane. Pravda, Fedora to chce řešit pomocí... instalace aktualizací při restartu.
http://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/

Worker procesy se startují forkem (bez execu), takže ty procesy jsou pořád identické a používají staré verze knihoven. Jinak třeba DEB-based distribuce ve výchozím nastavení po aktualizaci všechny servery restartují.

Pluginy se nenahrají, tyhle aplikace totiž kontrolují verze rozhraní (mimo jiné tím i kontrolují, že to jsou vůbec pluginy pro ně). Ostatně si to můžete vyzkoušet, třeba po aktualizaci na novou verzi KDE mohou v dříve spuštěném Dolphinu přestat fungovat síťové protokoly s chybou, že jejich kio-slave nejde načíst, protože nesedí verze rozhraní. Nikde ale nic nepadá.

Fedora tím AFAIK řeší hlavně neschopnost komerčního RPM správně aktualizovat systém :-)

Bez zámku nemůžete s jistotou vědět, že/které aplikace je třeba restartovat. A týká se to samozřejmě i GUI aplikací. K čemu vám je opatchovaný browser, když vám zůstane běžet neopatchovaná kopie? Pokud rebootujete jednou za měsíc, můžete další měsíc běžet neopatchovanou binárku.

Není důležité jestli aplikace spadne, nebo přestane fungovat jiným způsobem. K problému by vůbec nemělo dojít.

Richard Hughes v tom blog postu zmiňuje, že když aktualizujete xulrunner a zároveň běží Firefox, nastanou problémy.

Vždyt jsem psal, že RPM neumí aktualizovat

To právě řeší balíčkovací systém, ten ví, co aktualizuje a tedy i kterým aplikacím to patří.

Po bezpečnostních aktualizacích vás Debian či Ubuntu upozorní, že je potřeba restartovat. Ale restartovat, když se to hodí vám, ne když si to vymyslí systém, jako to dělaly Windows (dělají to pořád?)

Že to říká zrovna někdo, kdo propaguje Windows, kde jsem se už několikrát setkal s tím, že po té super bezpečné offline aktualizaci už nenaběhl NTLDR :-)

Balíčkovací systém to samozřejmě neví, pokud nějaká aplikace není instalované přes (jeho) balíčky. To může být příklad Oracle, Lotus Domino a dalších.

Viděl jste někdy tyhle dialogy?
http://www.word-tips.com/image-files/uninstall-microsoft-office-3.gif
http://www.jervis.ws/wp-content/uploads/windowsupdaterestart.jpg
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/7848.A_2D00_fifteen_2D00_minute_2D00_countdown_2D00_timer_2D00_warns_2D00_of_2D00_the_2D00_restart_5F00_305505DA.png

Pokud Windows po aktualizaci nenaběhnou, tak to nebývá způsobem aktualizace, ale obsahem toho patche.

Takové aplikace ale ten balíčkovací systém samozřejmě neaktualizuje, ne?

Aha, tak je to pořád stejné, Windows si usmyslí, že bude restart, a pokud to včas nezarazíte, máte smůlu. Skvělé, když máte rozdělanou práci a jste zrovna na obědě nebo sedíte na záchodě, obzvlášť ve spojení s tím, že Windows ani neumí po spuštění obnovit předchozí relaci.

To ano, ale způsob aktualizace na to evidentně nemá žádný vliv.

To sice ne, ale zato může aktualizovat knihovny nebo resources, na kterých jsou takové aplikace závislé.

Windows to mají tak, jak si to nastavíte. Ve výchozím nastavení uživatel může reboot odložit. To výchozí nastavení je tam proto, aby uživatel reboot nakonec provedl.
Obnovení předchozí relace Windows samozřejmě umí. Koukněte se na Restart Manager. Umí restartovat jen aplikace a služby, které mají zamknuté resources, a navrátit je pak do původního stavu. Když je potřeba reboot, umí po něm opět navrátit aplikace do původního stavu. Samozřejmě to aplikace musí podporovat.

RPM je taky zvěrstvo jak MS Installer, typický komerční napůl fungující bazmek, ani se nedivím, že ho v Debianu nechtějí. Mimochodem proč existuje pro Windows třeba NullSoft Installer, když je ten MS Installer tak dokonalý?

Pokud píšete SW řekněme pomocí notepadu a nějakého free compileru, nejspíš postrádáte vyjma IDE, debuggeru, resource editoru a dalších features také způsob, jak aplikaci zabalit pro instalaci. Pak je čas použít NullSoft Installer. Sice není transakční, nejspíš neumí sdílené komponenty, neumí patchovací a upgradovací balíčky atd., ale má malý overhead a je zdarma. Existuje i freeware pro výrobu MSI balíčků, a podle mě je to lepší volba.

Myslíte, že je tak napsána Google Picasa? Anebo že tak píše svůj kompilátor Intel? Své ovladače AMD? Či svůj software Adobe? I když tam bych to vzhledem ke „kvalitě“ Flashe asi i chápal :-)

Zajímavé, že po odinstalaci (nebo přerušení instalace) software přes NSIS jsem nikdy neměl v systému takový bordel, jako tam zanechával ten úžasný transakční MSI, ke kterému se musely používat ještě dodatečné nástroje, aby systém vyčistily. Ale naposledy jsem používal XPčka, tak je možné, že od té doby na tom MS po těch letech konečně zapracoval.

Ty wogo, ja se nestiham divit .. nekdo tady nema ani paru o tom, co jak funguje v systemu ... neco jako brouk Pytlik asi :)

Nic z toho cos napsal neni pravda. Kazda jedna vec, cos napsal :) Ano, vcetne toho, ze nelze menit zamcene soubory ve Windows. Ale jo, jde to.

Ale debatovat s Tebou nehodlam .. jenom si dovolim Ti doporucit, nastuduj si vsechno o cem debatujes. Alespon v zakladech... skoda totiz zasirat forum nesmyslami.

To nejsou nesmysly, to je oficiální stanovisko M$ ;)

Ale tak zas ano, oficialni prohlaseni je oficialni prohlaseni. :D

Co konkrétně není pravda? Když to máte nastudované, rád se nechám poučit.

Jistě, existují techniky, umožní změnit i zamčené soubory. Soudný člověk je ale nepoužívá, protože to zamykání souborů má své důvody.

Mimochodem, soubory jdou zamykat i v Linuxu, ale moc se to nepoužívá. Proč? Asi hlavně proto, že je (na rozdíl od Windows) zvykem psát aplikace tak, aby se se změnou vyrovnali.

Jen taková zajímavost - prehistorický Turbo Pascal spouštím v DOSBoxu, ale zdroják upravuji přímo v Linuxu, kde je to pro mě pohodlnější. Potom ten program nechám zkompilovat a spustit, a zatímco běží, tak ve zdrojáku udělám nějakou změnu a uložím jí. Když program doběhne, tak mě TP varuje že soubor byl změněn, a ptá se jestli ho chci znovu načíst z disku.
Takže dobře napsaný program z dob MS-DOSu se v klídku vypořádá i s nečekanou změnou souboru, se kterým právě pracuje. Holt je vidět že to není crippleware z Redmondu :-D

Ve spoustě editorů si můžete zamykání nastavit.

Pár otázek pro zamyšlení: co se stane, když jiná aplikace změní nezamknutý zdroják třeba během kompilace? Co se stane, když provádíte debugging, a jiná aplikace vám změní zdroják pod rukama? A jak editor poznáva změnu souboru? Pokud podle času modifikace souboru, tak ten má omezenou přesnost. Na NTFS je to 100ns, na ext2 1sec, na FAT16 2sec. Možná znáte výraz race condition.

Stane se přesně tohle co jsem napsal, protože během kompilace je zdroják v RAM. Pak záleží na uživateli jak se s tím vyrovná, jestli bude vědět co s tím má dělat, nebo mu mozek hodí BSOD. Pokud nevěříte, vyzkoušejte si to, ale mějte v záloze někoho kdo by vás resetoval ;)

Z těch třech otázek máte odpověď na jedinou, a to ještě špatnou. Ve většině vývojových prostředí se kompilátor čte soubor z disku. TurboPascal je pravda asi výjimkou :)

Omyl, tohle je právě odpověď na všechny tři otázky, protože to je Pascal, který se kompiluje jednoprůchodově a disk k tomu vůbec nepotřebuje. Takže jste ukázal ukázkové nepochopení toho jak funguje :-D

Kromě toho, pracuje se v inteligentně navrženém IDE, takže dokud změny neuložím, jsou jen v RAM, kde si s nimi můžu dělat co chci, kompilovat, krokovat, ladit o oktávů výš... Toho zřejmě Visual Studio není schopno, nebo to redmondští odchovanci QBasicu nepobrali do svých deformovaných mozečků ;-)

Jistě, když jsem psal "ve většině vývojových prostředí se kompilátor čte soubor z disku. Turbo Pascal je pravda asi výjimkou", tak jsem určitě netušil, jak TP funguje :)

co se stane, když jiná aplikace změní nezamknutý zdroják třeba během kompilace?

Buď nic nebo kompilace spadne

Co se stane, když provádíte debugging, a jiná aplikace vám změní zdroják pod rukama?

Budete mít špatně čísla řádek

A jak editor poznáva změnu souboru?

Dostane notifikaci z inotify

1. To nic moc.
2. Také nic moc.
3. Jo, tak to je samozřejmě mnohem lepší, než koukat na file modification time.

Další otázka: co má uživatel dělat, když soubor upravil v editoru, zároveň ho změnila jiná aplikace, a on dostane hlášku o změně souboru? Provádět snad sloučení změn? Není daleko lepší ten editovaný soubor prostě zamknout, protože ho někdo edituje a tedy používá?

Co má uživatel dělat, když soubor upravil v editoru, zároveň ho změnila jiná aplikace, a on dostane hlášku o změně souboru? Provádět snad sloučení změn?

Ano, mnoho linuxových editorů jej umí.

Není daleko lepší ten editovaný soubor prostě zamknout, protože ho někdo edituje a tedy používá?

A když ho potom někdo jiný omylem nechá otevřený a odjede na dovolenou, tak ho bez restartu serveru (když je to zamčené přes síť) nezměníte. Opravdu daleko lepší.

A umí to i office aplikace, editory fotek, videa, DB enginy? :)

LOL. U vás kvůli tomu musíte restartovat server? A utilitu openfiles, případně net file, neznáte? Vyměňte adminy.

"a binární databáze systému rpm jim nevadí."
A proč by proboha měla? Textové konfiguráky jsou dobré, protože je můžete snadno upravit textovým editorem. K čemu by mi byla manuální úprava databáze rpm fakt netušim.

Mě také není jasné, k čemu je dobrá manuální úprava konfiguráků OpenOffice (které jsou dlouhé jak týden), Gimpu, nebo nakonec /etc/passwd.

"OpenOffice"
Ten kdo to dělá je idiot.

"Gimpu"
Ten kdo to dělá je idiot.

"/etc/passwd"
Ten kdo to dělá je idiot.

Ono je to jinak. Metaforicky řečeno udělali /etc/passwd v době předků velcí Otcové Zakladatelé, kteří stáli za zrodem a prosazením počítačů. Bohužel je dnes používání konfiguráku jako administrativního rozhraní asi stejně aktuální, jako automobily na dřevoplyn. Parsování - a hlavně zápisy - textových konfiguráků v nevím kolika formátech pomocí low level file API je prostě out. Proto vznikají snahy jako GConf, Gsettings, KConfig a další. Jde tradičně o "komunitní" vývoj, tedy o dekádu nebo dvě opožděný, stylem jeden krok vpřed a dva kroky vzad.

Autoři OpenOffice měli (a mají) problém s textovou konfigurací, protože její parsování zpomaluje startování aplikace. Nastavení Gimpu ani vytvoření účtu v KMailu už také neprobíhá pomocí editace komentovaného konfiguráku.

V New Yorku by teď za auta na dřevoplyn byli vděční.
Když se něco podělá, tak jsou i textové konfiguráky dobré, ale podle M$ by se musel NY celý zbourat a postavit znovu :-D

No jo, v New Yorku přece mají palivové dříví v každé kůlně :D

Když se něco podělá, tak Registry jsou transakční, mají automatickou zálohu a dají se editovat, exportovat a importovat i z recovery console (tedy po bootu z instalačního média na konzoli).

Viděl jste někdy, co leze z GConfu nebo KConfigu? Ne, registry to nejsou.

Ne, registry to nejsou. Ale alespoň to (snad) řeší vícenásobný přístup a thread safety. Jak jsem psal: jeden krok dopředu, dva zpátky.

"jeden krok dopředu, dva zpátky."

To už jsem z víc míst slyšel o M$ :-D

Vícenásobný přístup řeší zamykání souborů. KConfig není žádná globální služba, řeší věci jen v rámci jedné aplikace plus umí poslat broadcast, že se konfigurace změnila.

1. Změna jediné hodnoty v konfiguráku znamená nutnost jeho kompletního přepsání, takže je zámek držený poměrně dlouho. 2. Jaké procento aplikací ty konfiguráky opravdu zamyká a zámky respektuje?

1. Čekání nastává výjimečně, těch souborů je velké množství.
2. Ty, co používají KConfig nebo GConf, určitě.

KConfig a GConf píšou tuším by default XML soubory, takže konfigurák pak stejně není moc human readable. Minimálně jeden z nich umí ukládat data i do nějaké databáze. Dost mě překvapuje, že to není default. Přineslo by to daleko lepší výkon čtení, a řádově lepší výkon zápisu.

Nevím u GConf, ale KConfig používá INI soubory. Čitelné to docela je a hlavně se to na rozdíl od binárních blobů dobře verzuje.

Nojo, to měl kdysi dávno Windows také, to byl ještě relativně použitelný :-D