> Remote Desktop a X11 si naštěstí nejsou příliš podobné. X11 protokol je totiž příšerný, a API
> na tom není o moc lépe. VNC je ještě horší protokol. RDP nemusí exportovat celé desktopové
> prostředí, i když běžně je to tak nastaveno.
X11 narozdil od VNC i RDP umi napriklad na vzdaleny stroj posilat i OpenGL prikazy, je proste historicky urceny na neco uplne jineho nez RDP.
WinAPI co se tyce prace s GUI taky neni zadny zazrak. V tomhle si muzou podat ruce. Ciste tyto API nepouziva moc lidi, vetsinou nad tim mate nejakou jinou vrstvu.... nastesti.
> Pokud není třeba signál pro uložení stavu aplikace, jak tedy aplikaci řeknete, že má uložit
> stav, a ne se jen ukončit? A jak jí později řeknete, že si má stav znovu natáhnout? Chápejte,
> že nějak tuto akci musíte iniciovat. Takže jak aplikace tu informaci dostane?
TERM rika korektne ukoncit, bez ztraty dat, pokud se opravdu bavime o session, uz jsem rikal, ze GNOME i KDE to podporuji a musi to nekdo implementovat do aplikace. Stejne jako ve win.
(Pak je tu jeste dbus na tento typ zprav a to vcetne zprav pro konzolove a serverove aplikace.. I ten xserver uz ho podporuje)
> A jak jsem psal, Vista má Restart Manager, který podporuje při patchování a instalacích
> restart aplikací se zachováním jejich stavu.
Stejne jako vsechna bezna distra maji balickovaci system, ktery, pokud si to autor aplikace/balicku preje, muze v pre/post install fazi poslat pozadovane signaly a ulozit/pozastavit/restartovat aplikaci. Jen to musi aplikace podporovat. Stejne jako na win, jen o zhruba 10 let driv.
> Ano, možnost odstranění souboru je jiný design. Špatný a nebezpečný.
Nebezpecny? A to jak? Az budou windows podporovat opravdu skutecny multiuzivatelsky pristup pro stovky uzivatelu soucasne, tak zjistite, ze to je nutny pristup. Jinak by se vam nikdy nepodarilo zadny dulezity soubor vymenit bez docasneho odpojeni vsech uzivatelu. Takto proste jen nove otevreny soubor uz bude mit nova data. A aby si to uzivatele neprepisovali schvalne hlidaji samozrejme prava na filesystemu.
Krome toho je to i zpusob jakym se oteviraji docasne soubory.. tj vytvori se, otevre a okamzite se smaze zaznam z adresare. Ve chvili kdy s nim aplikace prestane pracovat pak automaticky zmizi i fyzicky (protoze pocitadlo hardlinku kleslo na 0).
> Zkuse si MSI balíček představit jako všechny RPM balíčky nutné k instalaci dané aplikace,
> plus GUI (třeba výběr komponent, jméno serveru, kontext ve kterém pojede služba), plus
> možnost unattanded instalace, plus možnost repairu aplikace, plus možnost automatické
> odinstalace závislostí používaných jen danou aplikací.
Fajn, vsechna ta plus skrtnete, protoze vsechno tohle samozrejme balickovaci systemy umi (debiani urcite, u rpm si nejsem jisty s automatickou odinstalaci nepouzivanych zavislosti, protoze ted vysla/vyjde nova verze)
> K tomu, kterou knihovnu aktualizovat. MSI balíčky s sebou tahají buď sdílené
> knihovny/komponenty/etc, nebo privátní. Sdílené věci se jedním patchem pochopitelně
> aktualizují pro všechny aplikace, které je používají.
A jak vyresite konflikty typu aplikace na novou verzi knihovny neni stavena a jeste ji nepodporuje? Nerikam, ze si to MSI nesleduje, jen me to zajima... a s tim souvisi i vice verzi knihoven v systemu.
> Hm, jak zjistíte, kterou aplikaci máte restartovat? Ve Windows se alespoň dozvíte, že je
> třeba restartovat. Samozřejmě můžete restartovat jen danou aplikaci;
Ale kterou? Kdyz vymenim sdilenou knihovnu (coz neudelam prave diky tomu jak funguje mazani), kdo mi rekne, ktere aplikace ji vyzaduji a je potreba je restartovat? Centralni balickovaci system tuhle informaci proste ma.
A to nemluvim o tom, ze Windows doted nema zadny system na udrzovani vice verzi sdilene knihovny zaraz. Jedina moznost je opravdu mit tu knihovnu u kazde aplikace zvlast. Ale pak jste odkazany na aktualizace od vyrobce aplikace a ne vyrobce knihovny.
> Návaznost na centrální systém aktualizací neexistuje, protože takový systém nemáme. Nemáme
> ho proto, že aplikace připravují a šíří nezávislí vývojáři, nikoliv autoři Windows. V
> Linuxu máte centrální systém aktualizací, ale pouze pro balíčky šířené v rámci distra (tedy
> připravené pro správnou verzi správného distra). Ve windows umožňuje MSI tahat aktualizace
> z místa, které si vybere autor aplikace (to často použvají firmy).
Nezavisli vyvojari maji samozrejme moznost vytvoreni nezavisleho repozitare, ktery spravce proste jen prida mezi seznam zdroju. A spousta z nich to taky dela.
> Initskripty jsou sice pěkné, ale bohužel nejde o API, navíc jsou ty skripty různé v různých
> distrech (a na různých unixech). Když chcete z aplikace zjistit či nastavit, jaké služby
> jsou nainstalované, v jakém jsou stavu, na čem jsou závislé, v jakém kontextu se spouštějí
> apod., tak máte prostě smůlu. Nebo můžete spouštět skripty v závislosti na tom, na jakém
> jste unixu, v případě Linuxu na distru a jeho verzi. Děkuji, nechci. Autoři něco silně
> zanedbali. Na unixech vůbec chybí spousta API pro správu systému.
A kdyz chcete na windows zjistit tyto informace o sluzbe, ktera to nepodporuje, tak jste na tom uplne stejne. Na linuxu taky existuje neco jako "/etc/init.d/sluzba status". Obsah init skriptu vas nemusi zajimat, o ty se stara autor aplikace a distra. Proste to berte jako soucast aplikace a nereste, ze to je skript.
Ze se to v kazdem distru dela jinak? Zas takove rozdily tam nejsou a kdyz porovnam Win 2000 a XP, tak je to taky v kazde verzi jine. XP s Vistou uplne stejny priklad.
A informace o tom co vsechno bezi samozrejme ziskate snadno. /proc/ znate? Aneb vsechno je soubor.. mate tam pro kazdy bezici proces informace o ceste k binarce, pouzivane pameti, aktualnim adresari, otevrenych deskriptorech, promennych prostredi, ....
Myslim, ze ty API tam proste jsou, jen vy o nich nevite, nebo si neuvedomujete co se s temi prostredky co mame k dispozici da vsechno delat. A vsechna (no.. velka vetsina) ta informacni api jsou pristupna pomoci cteni souboru. Pripadne moderni distribuce jeste pouzivaji HAL databazi pristupnou pres DBUS a informace o zarizenich z /sys.