Vlákno názorů k článku Mnichovské kritice Linuxu chybí pádné argumenty od robert - docela bych chtel umet nahlednout jak to bude...

Bych rek ze jedine si flashnout komplet modifikovanej system. Idealne ve variante, kde je odparanej google a vsechny jeho "vymozenosti"

Zdrojáky komerční aplikace vám nikdo jen tak nedá, prokazatelně si vymýšlíte. Pokud ano, tak za řádově vyšší peníze.

U Widlí stačí otestovat tři verze a je vyřešeno. V Linuxu násobky. HW s tím moc nemá co dělat kromě her.

Prokazatelně si vymýšlím? :-D

"U Widlí stačí otestovat tři verze a je vyřešeno. V Linuxu násobky. HW s tím moc nemá co dělat kromě her."

Je zajímavé, že třeba Steam se testuje pouze na Ubuntu, přesto bez problémů běží i na jiných distribucích. Asi to dělají nejak blbě nebo co... Ale tak hlavně ze máte svůj názor ;-)

Ano prokazatelně. Zdrojáky komerčních aplikací jsou vždy za tučný příplatek.
Steam je pro úřednické desktopové aplikace mimo mísu.

"Zdrojáky komerčních aplikací jsou vždy za tučný příplatek."

Prokazatelně si vymýšlíte, zdaleka to není vždy.

"Steam je pro úřednické desktopové aplikace mimo mísu."

Stejně tak testování na více distribucích je pro úřednické desktopové aplikace mimo mísu, když používají jeden systém. Ale uhýbáte statečně, jen co je pravda ;-)

Ano prokazatelně. Zdrojáky komerčních aplikací jsou vždy za tučný příplatek.

Třeba takový RHEL 7 je také fest komerční aplikace a přesto na kompletní zdrojáky právě teď koukám. Dělám něco špatně já nebo Red Hat?

Steam je pro úřednické desktopové aplikace mimo mísu.

Proč? Je to aplikaci pro Linux? Ano. Má GUI? Ano. Je podporována pouze na Ubuntu 12.04 a 12.10? Ano. Funguje třeba na Arch Linuxu? Ano. Čím se tak zásadně liší Steam od jiných aplikací? Že k němu Valve dodává i runtime závislosti, aby to fungovalo všude možně? Na Windows se nezřídka dělá totéž...

To je zajimavy, ze sam velky M$ celkem standardne dodava svy appky (trebas Axapta (neboli Microsoft Dynamics AX) vcetne zdrojaku. Variantne se mi ti vali od Oracle BI. Oni ty zdrojaky totiz jaksi bez supportu stejne nemaji u vetsich projektu smysl, protoze ikdo si nebude najimat tym programatoru, aby se 20let ucili jak to funguje a pak mu to mohli zacit udrzovat. Zdrojaky maj smysl tak pro nejaky drobny upravy.

Kde konkrétně seženu ty zdrojáky Microsoft Dynamics AX? A co všechno v nich najdu?

Zeby sis to loliku musel nejdriv koupit?

Takže ještě jednou: kde ty zdrojáky zákazník najde, a k čemu všemu zdrojáky získá? Konkrétně, prosím. Vy rád píšete vágní nesmysly, které mají zakrývat, že nevíte o čem mluvíte.

Tovis ze jo, a k tomu asi tak 800 jazykovych mutaci ... protoze kazda se za jistych okolnosti muze chovat zcela jinak. Protoze v M$ neumej udelat multilang system.

Kdyz vemu tuxe, tak to prachsproste skopiruju na 1000 zcela ruznych HW ... na na 1000 stroju bez problemu nastartuje. Udelej to samy s widlema.

Zase nesmysl. Windows i Office mají dávno stejné binárky pro všechny jazykové mutace.

Ad vemu tuxe, tak to prachsproste skopiruju na 1000 zcela ruznych HW ... na na 1000 stroju bez problemu nastartuje - a nebo taky ne :)
http://www.root.cz/zpravicky/nektere-nove-notebooky-od-samsungu-nepreziji-instalaci-linuxu/

BTW schopnější admini znají Windows Automated Installation Kit. Vy ne? Hm, smůla.

Aha. Takže *Samsung* přidal rozbitej kód, kterej rozbíjí zařízení od *Samsungu*. To je jako kdyby NVidia vydala rozbitej driver pro svoje grafárny, kterej je přetaktuje a spálí. Byla by to chyba Windows? :-)

"To je jako kdyby NVidia vydala rozbitej driver pro svoje grafárny, kterej je přetaktuje a spálí. Byla by to chyba Windows? :-)"

Něco velmi podobného se v minulosti stalo. nVidia měla v jisté verzi ovladačů bug v regulaci otáček ventilátoru, který se i při plné záteži GPU nerozběhl naplno. V té době novinka Mass Effect 2 dokázala GPU vytížit natolik, že se v důsledku nesprávné regulace chlazení přehřálo. Některým lidem toto přehřívání zničilo grafickou kartu. Pokud by se stejná logika Samsung X Linux aplikovala na Mass Effect 2 X nVidia, byl za destrukci GPU odpovědný Mass Effect, který neúměrně zatěžoval GPU...

http://www.bit-tech.net/news/hardware/2010/03/18/nvidia-fixes-overheating-issue/1

A protože Mass Effect běžel na Windows, tak za to byly odpovědné Windows :-)

Autorem driveru nebyl Samsung, ale nějaký dobrovolník. Driver nebyl vůbec psaný ani testovaný pro daný model HW, používal nedokumentovaný interface, a používal ho (díky bordelu v kernelu Linuxu) i při EFI bootu, i když ten nedokumentovaný interface při EFI bootu neexistuje.

Příslušný ovladač napsal Greg Kroah-Hartman na základě jakési dokumentace přímo od Samsungu. Problém byl právě v tom, že onen interface při EFI bootu existoval (to ovladač kontroloval), ale jeho použití vyvolalo Machine Check Exception. Tu jádro zalogovalo do variable storage. Ta když se zaplnila nad kritickou mez (někde se uvádělo 50 % celkové kapacity), počítač umřel.

Jestli Windows logují MCE do variable storage také, stane se tam totéž třeba v případě, kdy se notebook se zaprášeným větrákem přehřeje.

Greg Kroah-Hartman napsal ovladač na základě nějaké neoficiálního mailu od zaměstnanace Samsungu, který se týkal konkrétního modelu před nevím kolika lety. Modul samsung-laptop provádí nějaké divoké a nepodporované modifikace paměti BIOSu, které s řadou modelů nebyly nikdy testované, a mohou a nemusí fungovat. Bohužel je provádí i když se zabootuje v UEFI módu, díky problému s funkcí efi_enabled, který je popsaný v třetím linku. A protože při UEFI bootu ta modifikovaná paměť BIOSu není k dispozici, skončí to crash dumpem. Crash dump se zapíše do UEFI storage space, a tam dojde k dalšímu problému. Samsung tam totiž má nějaký bug, díky kterému při zápisu většího počtu velkých variables dojde k bricknutí.
http://mjg59.dreamwidth.org/22855.html
http://www.codon.org.uk/~mjg59/scratch/brick_samsung.txt
https://patchwork.kernel.org/patch/2087041/

Kdyby to ty prasárny (nepodporovaný interface, driver netestovaný na konkrétním modelu HW, použití interface BIOSu při EFI bootu) neskončily zrovna na MCE a na tom bugu ve firmwaru Samsungu, byl to by jen další "kvalitní" driver pro Linux :)

Modul samsung-laptop provádí nějaké divoké a nepodporované modifikace paměti BIOSu, které s řadou modelů nebyly nikdy testované, a mohou a nemusí fungovat

Proč mi tenhle popis jen připomíná generické ovladače ve Windows?

A protože při UEFI bootu ta modifikovaná paměť BIOSu není k dispozici, skončí to crash dumpem

Jenže ta paměť k dispozici je, ten ovladač to testuje, až při použití dojde k MCE. Prostě Samsung při UEFI bootu inzeruje něco, co neumí

Samsung tam totiž má nějaký bug, díky kterému při zápisu většího počtu velkých variables dojde k bricknutí

Takže je určitě chyba Linuxu :-P

Mimochodem když už sem hážete odkazy, zkuste si je přečíst:
Originally we assumed that the magic values we wrote were causing the problem, so the samsung-laptop driver was patched to disable it on UEFI systems. Unfortunately, this doesn't actually fix the problem - it just avoids the easiest way of triggering it.

Ad Proč mi tenhle popis jen připomíná generické ovladače ve Windows - to nevím, povídejte

Ad ta paměť k dispozici je, ten ovladač to testuje - na daném místě v paměti byl nějaký pointer, o kterém nikdo oficiálně neříká, kam má směřovat. A zápis na lokaci, na kterou ten pointer ukazuje, vyvolal MCE - což je naprosto v pořádku, protože driver nemá co psát po paměti kam se mu zlíbí.

Ad určitě chyba Linuxu - tohle byla chyba Samsungu, což jsem také psal.

Ad zkuste si je přečíst - zkuste si je přečíst vy. Po vaší citaci autor popisuje ten bug Samsungu při zaplnění UEFI storage space.

Jak jsem psa, jde o kombinaci problémů: použití nepodporovaného interface vytáhnutého neoficiálně kdysi od někoho ze Samsungu, netestování driveru s konkrétními modely HW, změna významu flagu efi_enabled, a bug firmwaru Samsungu (který jen ty ostatní prasárny vystavil světu). Závěr: špinavé hacky vedou k problémům, a Linux jich má požehnaně.

A co měl v tomto konkrétním případě autor ovladače řešit jinak? Ty špinavé hacky jsou totiž podle všeho oficiální způsob, jak na noteboocích Samsungu měnit jas, přepínat bluetooth atp. Iluze o tom, že se výrobci obtěžují své produkty nějak smysluplně testovat mi definitivně sebrala následující epizodka, týkající se pro změnu notebooků Toshiby:

Výchozí nastavení notebooků od Toshiby je v "Powersave" režimu snížit výkon CPU vkládáním prázdných CPU cyklů. Skoro nic to neušetří a výrazně to sníží výkon, ale aspoň se to dá kontrolovat voláním ACPI metod. Pro majitele těchto strojů je velmi nešťastné, že embedded controller v těchto zázracích nedeterministicky tento režim aktivuje, i když to uživatel v nastavení vypne. Pokud teplota CPU stoupne nad kritickou mez (dle mé zkušenosti 65 °C), CPU se přiškrtí a počítač se stane téměř nepoužitelným. Legrační je zejména to, že tento režim ve Windows nelze s použitím oficiálních ovladačů Toshiby nijak vypnout. Ve správě napájení je sice příslušné klikadlo, ale jeho přenastavení nemá žádný efekt. Bez ohledu na verzi ovladače, postupu při jeho reinstalaci a intenzitu klení není možné se tohoto režimu zbavit. Reset BIOSu také nepomůže, protože nastavení je zřejmě uloženo v nějaké interní paměti EC. Uživatelé Windows jsou odkázáni na 3rd party hacky. Ty sice např. periodickým voláním příslušné ACPI metody throttling vypnou, ale CPU se pro změnu začne přehřívat; EC totiž řidí i otáčky ventilátoru, který se v "Powersave" režimu spouští vždy jen na cca 2/3 výkonu.

Jedinou možnost, kterou jsem za snad 5 let operování s těmito krámy objevil je použití neoficiálního ovladače "omnibook" pro Linux. Funguje úplně stejně jako samsung-laptop - na nějakým způsobem odhadnutou adresu něco zapíše. Na rozdíl od oficiálního ovladače to ale funguje a do doby, než EC zase rupne v kouli je vše OK.

Ještě je třeba si povídat o tom, jak profesionálně se dnes dělá software spotřební elektroniky? S touto úrovní bastličství na straně výrobců a fatálním nedostatkem dokumentace se pak nelze divit, že dochází k excesům á la Samsung.

Změna jasu se pokud vím má provádět pomocí ACPI funkce _BCM, ostatní akce podobně. Pokud se jedná o vendor extension, je potřeba buď získat dokumentaci od výrobce, nebo to zjistit vlastním úsilím. Vendor extensions jsou ale specifické pro daný model HW, a pokud se mají použít na jiném HW, je potřeba opět získat od výrobce dokumentaci, nebo vlastním úsilím na daném HW funkce otestovat.

Pokud výrobce nechce dát dokumentaci, samozřejmě ho lze motivovat ke spolupráci. Autoři kernelu mohli dávno vytvořit databázi modelů HW a vendor extensions, a jednat s výrobci o jejím naplnění. Jistě by se někdo našel, a další by s časem přidali. Výsledkem by byla DB modelů a konkrétních postupů, jak se implementují různé funkce, kterou lze snadno zkompilovat do binární podoby. Pak už chybí jen ACPI driver, který bude ty funkce volat. Uživatel si může triviálně ověřit, jestli je jeho model HW podporovaný, případně co na něm Linux neumí. Samozřejmě by takovou DB mohlo vytvořit i UEFI Forum (které ACPI spravuje). Canonical, Red Hat i SuSE jsou členy, možná by tam měli dělat něco rozumného.
A co máte místo toho? Příšernou změť driverů psaných na koleni, které vycházejí z různých neoficiálních informací a debuggingu AMC a driverů pro Windows, které se používají pro HW, na kterém nikdy nevyly testované. Koupě notebooku s Linuxem je dál sázka do loterie. Pak se nelze divit ničemu.

Jak další dva katastrofické příklady jsem v minulých diskusích uváděl CD-ROM mechaniky LG, které měly bohužel navěšenou funkci pro update firmwaru na funkcích, které používají běžně CD-R mechaniky. A nějakého exota nenapadlo nic lepšího, než typ mechaniky "experimentálně" ověřovat tak, že mechanice pošle příkazy specifické pro CD-R, a koukne jestli to vrátí chybu. Wow, bricknutý HW, kdo to mohl čekat? Špinavé hacky vedou ke špatným koncům.

Dalším příkladem je bricknutí karet Intel. Ftrace prováděl nebezpečnou techniku modifikace živého kódu. A protože se prováděla asynchronně, mohlo dojít k modifikaci paměti programu, který už neběžel. To bylo vyřešeno pojistkou ve formě ověřování, jestli se program už neukončil, která ale díky bugu nefungovala. Jako poslední záchrana tam bylo srovnání cílové paměťové lokace s instrukcemi skoku (tedy jestli se opravdu přepisuje, co se přepisovat má). Ovšem na paměti zařízení srovnávací operace nemají definovaný výsledek, takže ani to nezabralo. A špatný zápis shodou okolností skončil zápisem no NVRAM síťové karty. Samozřejmě ke špatným zápisům docházelo na spoustě systémů, ale shodou okolností se nestrefily do ničeho kritického. Chyby na straně Linuxu: nebezpečná technika a dva kritické bugy. A znovu, špinavé hacky vedou ke špatným koncům.

Databáze podporovanáho hardware samozřejmě existují. spousta distribucí má informace týkající se funkčnosti různého HW na svých Wiki stránkách atp. Problém je, že spousta výrobců hardware pod jedním modelovým označením často nabízí různý hardware, odlišné verze firmwarů a BIOSů jsou jinak zabugované takže ani tyto databáze nejsou zdaleka samospásné. Navíc neřeší situaci nových zařízení, která se ještě nestihla dostatečně otestovat.

Problém LG mechanik lze interpretovat i obráceně. Výrobce inzeruje hardware jako ATAPI kompatibiliní a přitom se v některých verzích firmwaru rozhodne tuto specifikaci porušit. Ovladač předpokládájící ATAPI kompatibilitu pak provede něco, co mechanika nezbaští. Nedodržovaní standardů kupodivu také vede ke špatným koncům.

Jo, databáze podporovaného HW existují. Na prvním místě je ten humus s nedokumentovanými interface, na koleně psanými a nedokumentovanými drivery, který jsem popisoval. Na druhém místě to autoři distra zabalí do ISO image. Na třetím místě pak někdo doma zkusí, jestli mu to funguje. Samozřejmě to nezkouší nijak metodicky. A výsledkem je informace, že Frantovi cosi doma zafungovalo. Informace je to naprosto nespolehlivá, a samozřejmě se týká jednoho distra v jedné verzi. V jiném verzi nebo jiném distru to může dopadnout úplně jinak. Je to prostě bažina, navíc plná krokodýlů :)

Problém s mechanikami LG se má trochu jinak. Driver nemá co posílat CD-ROM zařízení příkazy, které nejsou ve specifikaci. Pánové z LG museli někam pověsit interface pro update firmwaru - specifikace ATAPI to nijak neřeší. Typicky se to dělá tak, že update firmware navěsíte na nějaký kód příkazu, který na zařízení nikdy nepřijde. To že si v LG vybrali zrovna kód který u CD-R mechanik znamená flush buffer není nic proti ničemu, i když je to dost nešťastné. Ale kdo ví, jestli to nepsali ještě před vedením toto příkazu ve specifikaci ATAPI. Každopádně detekce toho, jestli jde o mechaniku CD-ROM nebo CD-R, se provádí pomocí nějakých flagů popisujících zařízení. Pokud to někdo zjišťuje posíláním příkazů, které zařízení podle specifikace nemá umět, tak je to prasárna, a koleduje si o šlápnutí do lejna. Což se také stalo.

Není žádná oddělená specifikace ATAPI pro CD-ROM. ATAPI navíc explicitně zakazuje používat ty kódy pro jiné akce, než které specifikuje ATAPI.

Ale samozřejmě za to může Linux :-)

Ad Není žádná oddělená specifikace ATAPI pro CD-ROM - vizte http://www.bswd.com/sff8020i.pdf
Samozřejmě tam nenajdete ani slovo o příkazu flush buffer.

Autor driveru pro Linux může za to, že místo aby detekoval CD-R mechaniku podle flagů, tak zařízení posílá příkazy které podle specifikace nemusí vůbec znát, a čeká na chybu. To je zcela zjevně špatný postup, aka prasárna. S tímhle souhlasíte, nebo to rozporujete?

Ano, to je standard z roku 1996. V roce 1998 byl nahrazen ATAPI-4, které nemá žádnou oddělenou část pro CD-ROMy.

Tam je otázkou, jaké modely mechanik to byly, a kdy k nim byl psaný firmware.

Rád bych zopakoval otázku z druhého odstavce:

Autor driveru pro Linux může za to, že místo aby detekoval CD-R mechaniku podle flagů, tak zařízení posílá příkazy které podle specifikace nemusí vůbec znát, a čeká na chybu. To je zcela zjevně špatný postup, aka prasárna. S tímhle souhlasíte, nebo to rozporujete?

Tam je otázkou, jaké modely mechanik to byly, a kdy k nim byl psaný firmware.

Problém se objevil v roce 2003 a šlo o mechaniky, které byly ještě v záruce.

Autor driveru pro Linux může za to, že místo aby detekoval CD-R mechaniku podle flagů, tak zařízení posílá příkazy které podle specifikace nemusí vůbec znát, a čeká na chybu. To je zcela zjevně špatný postup, aka prasárna. S tímhle souhlasíte, nebo to rozporujete?

Nesouhlasím, protože máte špatné informace.

Specifikace ATAPI:
This command is mandatory for devices not implementing the PACKET feature set

Jestli zařízení používá PACKET feature set, si ovladač testoval.

Ad máte špatné informace - samozřejmě se rád dozvím další informace. Nalinkujete mi prosím nějaké zdroje?

Co se ATAPI-4 specifickace týče, píše se v ní toto:

FLUSH CACHE je volitelný příkaz, pokud není podporován, má zařízení vrátit chybový výstup s nastaveným bitem ABORTED. Totéž platí pro IDENTIFY PACKET DEVICE. Zda zařízení podporuje packet writing by měl ukazovat word 82/bit 4 vrácený příkazem IDENTIFY DEVICE. ATAPI-4 dále specifikuje příkaz DOWNLOAD MICROCODE, který se má pro nahrávání firmwaru použít.

Dále je třeba říct, že tímto problémem trpěla jen distribuce Mandrake 9.2. Její vývojáři se totiž rozhodli do jádra zařadit v té době experimentální patch pro podporu packet writingu. Použití FLUSH CACHE bylo z verze nakonec zařazené do mainline jádra odstraněno (http://osdir.com/ml/linux.suse.packet-writing/2003-10/msg00028.html). Pokud tedy kromě LG někdo selhal, byli to pouze vývojáři Mandrake.

No jo, jenže ještě v roce 1997 ve specifikaci ATA-3 příkaz FLUSH CACHE nebyl. A pokud pánové z LG psali firmware podle ATA-3, tak o něm nevěděli. IDENTIFY DEVICE words 82 a 83 mohou podle ATA-3 vracet 0000h nebo FFFFh, pokud zařízení nemá podporu command set notification.

S DOWNLOAD MICROCODE máte sice pravdu, ale až od ATA/ATAPI-4.

Na prvním místě byl kód napsaný v rozporu se specifikací, na druhém místě autoři minimálně Mandrake udělali závažnou chybu (ovšem zahrnutí nejrůznějších divokých patchů je v komunitních distrech běžné dodnes).

ATAPI-4 je z roku 1998. Ty mechaniky byly o pět let mladší. Že zrovna tady vám takhle starý standard nevadí, ale u ODF by to byla tragédie?

Ad "ty mechaniky byly o pět let mladší" - modely poškozených mechanik jsem nenašel. Pokud vy ano, dejte sem prosím zdroj.

Ad zrovna tady vám takhle starý standard nevadí - jistě se shodneme, že driver pro packet writing by měl korektně fungovat i mechanikami staršími než pár let. Nemusí na nich umět zapisovat, ale neměl by jim posílat příkazy, které nejsou podle specifikace podporované.

Seznam mechanik, které mohou mít problematický firmware jsem objevil zde (http://forums.scotsnewsletter.com/index.php?s=747a0e2943aaf5bac3a27b38f8c1b12b&showtopic=3582&#entry42809). Pokud se dá z data zveřejnění elektronické verze návodu k obsluze něco vyvozovat, byla nejstarší postižená mechanika z roku 1999, více jich bylo vyrobeno po roce 2000. Seznam je celkem obsáhlý a všechny modely jsem se nedíval, takže tam možná je nějaký ještě starší model.

ATA standard samořejmě umožňuje ovladači kontrolovat, jakou verzi standardu zařízení podporuje, takže ovladač měl možnost si ověřit, zda zařízení zná ATAPI-4. Nějaká verze patche pro podporu packet writingu pro jádro 2.4.22 je třeba zde (http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.22-packet-1.patch), ale těžko říct, jestli Mandrake 9.2 obsahoval přesně tento kód. Příkaz DOWNLOAD MICROCODE je ale obsažen už v ATA-2 z roku 1996. V dokumentu týkajícím se ATA specifikace pro CD-ROMy, který jste odkazoval se v abstraktu píše toto:

"This specification supplements the definitions of an ATA mass storage peripheral found in the ATA document. The ATAPI and CD-ROM interfaces described in this document are compatible with existing ATA hard-ware without any changes or additional pins."

Tato specifikace je tedy pouze rozšířením v té době platné ATA, nikoliv samostatným standardem určeným pro CD-ROM. Pokud byly postižené mechaniky aspoň ATA-2 kompatibilní, měly pro update firmwaru používat DOWNLOAD FIRMWARE nebo nějaký vendor-specific opcode. Už podle ATA-2 je povolený rozsah hodnot pro vendor-specific příkazy 9Ah, C0h - C3h, 8xh a F0h - FFh. FLUSH CACHE má opcode E7h.

Máte pravdu, v ATA-2 už je DOWNLOAD MICROCODE. Ovšem ty modely mohou vycházet z daleko staršího firmwaru.

Ten patch se mi nechce celý číst, ale na první pohled to vypadá, že například pkt_flush_writes() netestuje návratovou hodnotu pkt_flush_cache(). Tenhle kód zjevně neměl být zahrnut do žádného distra.

Ad Už podle ATA-2 je povolený rozsah hodnot pro vendor-specific příkazy 9Ah, C0h - C3h, 8xh a F0h - FFh. FLUSH CACHE má opcode E7h - rozsah vendor-specific commands je určený už v ATA-1, a zbytek rozsahu je popsaný jeko reserved. Takže pokud byl ten upgrade firmware opravdu pověšený na E7h, buď psali firmware podle specifikace IDE (tu nemám), nebo šlo o porušení specifikace ATA-1.

Tím pádem to vypadá, že sešel zjevně špatně napsaný driver s pravděpodobným bugem ve firmwaru mechaniky.

Díky za všechny informace, byla to fajn diskuse.

To vizejo loliku, a proto se cesky widle chovaj jinak, nez anglicky widle s ceskym balickem ...

Jak souvisí vadný HW Samsungu, který se dá umrtvit softwarem, dodaným původně také od Samsungu s tím co píšete vy a také ten co na něj reagujete? Argumet pro argument mimo téma? Nebo uděláme kompromis a snížíme číslo 1000 na 999 a budeme všichni spokojeni? :-D

Přesně tak se to dělá - a já osobně k tomu používám chroot na steroidech - schroot :-)

Oficiální stanovisko MS je takové, že VS 6 je z roku 1998, a tedy dávno nepodporované. To jste fakt za posledních deset let neměli čas zmigrovat projekt na novější verzi VS? Jinak VS 6 jsem na Win7 měl nainstalované. Chtělo to trochu přemlouvat, ale rozběhal jsem ho.

Aktualizace mi ještě nikdy nerozbily drivery, i když samozřejmě nevylučuji, že se to někomu mohlo stát. MS Office je zpětně kompatibilní, takže byste se vzhledem dokumentu neměl mít problémy. Samozřejmě pokud nemáte v dokumentu nastavenou kompatibilitu s Wordem 95, což se bohužel dodnes vidí. Dalším problémem mohou být fonty s nekompatibilní metrikou, což není problém produktu (ale můžete je vložit do dokumentu).

Pokud vám nefunguje Outoook nebo Lync, jde nejspíš o problém konektivity nebo serveru, nikoliv produktu.

Pokud hledáte použitelný shell, zkuste se naučit PowerShell. Je to velmi silný nástroj.

Víte, pohybujeme se v oblasti technologií, konkrétně telekomunikací, a i tady, stejně jako v jiných technologických oborech, existuje cosi jako inženýrský konzervatismus. Pokud 15 let ladíte nějaký rozsáhlý systém, čistě statisticky každý rok z něj odstraníte jisté procento chyb. Takový systém sice není nějaký výkřik poslední módy, ale má jednu podstatnou vlastnost, kterou naši klienti oceňují, neboť jim (potažmo nám, na smluvních pokutách) šetří peníze - spolehlivost. Klienti našich klientů nemají vůbec tušení, jakými technologiemi jsou jejich služby zprostředkovávány, naše produkty nejsou vidět, takže není důvod je co dva roky inovovat, naše produkty musejí hlavně spolehlivě fungovat a k upgradu je důvod jedině tehdy, když jsou po nich vyžadovány nové vlastnosti - a i tehdy se vždy pokud možno volí ta nejminimalistič­tější varianta, protože když něco dobře funguje tak do toho hlavně co? No nehrabu! Migrace by byla jednak nákladná časově i finančně, jednak by šlo jen o údržbu stávajících řešení, ale hlavně - v životním cyklu produktu by nás to vrátilo zpět do beta fáze, což je naprosto nepřijatelné. Navíc nejde o jeden projekt, je to celá generace velice rozsáhlých projektů.

Stručně a krátce - proč migrovat projekty do nové verze vývojového prostředí s naprosto nejistým výsledkem, když stávající kombinace se osvědčila, funguje a jediné, co je čas od času třeba, je změnit/doplnit pár desítek, maximálně stovek řádků kódu a celé to prohnat tisícovkami testů? To by nedávalo smysl.

Word dokumenty sice načte, ale formátování absolutně nesedí. Žádné externí fonty v nich použity nejsou, veškerá firemní loga apod. jsou samozřejmě součástí souboru. O problémech v mnohastránkovém dokumentu ale navíc není autor nijak informován, takže když se třeba část tabulky schová za okraj, snadno se to přehlédne - zvláště, vyjde-li to náhodou na vertikální dělící čáry. Jediné řešení je používat vedle sebe více verzí MS Office, ale ani to není bezproblémové, spíše naopak, takže opět raději volíme cestu vmware. Připadám si opravdu jak v době kamenné - přečíst dokumentaci, připravit si vhodnou virtuální mašinu a v ní provést potřebné změny/testy/kon­troly.

Nejsem ajťák a tak neřeším, co způsobuje problémy Lyncu nebo Outlooku. Dost možná tedy máte pravdu, ale z mého pohledu to zkrátka nefunguje, ačkoli určité nepříjemné vlastnosti se na konektivitu ani server shodit nedají, jako jejich řešení historie, omezení délky zpráv apod.

Mluvil jsem o standardních nástrojích. Nemohu si na pracoviště nainstalovat, co se mi zlíbí, ani nejsem oprávněn k administrování svého počítače. Jaké aplikace jsou povoleny je poměrně striktně vymezeno.

Pokud vydáváte aplikace psané ve vývojovém prostředí z roku 1988, tak jste to s tou konzervativností zjevně trochu přehnali :). Ale jak jsem psal, ve VS můžete pracovat i ve Win7 64-bit.

Zkusím vysvětlit. Word 95 (a starší) používal layout dokumentů podle metriky tiskárny. Jde o to, že při rastrování křivkových fontů vám třeba písmeno "m" vyjde široké 7.25 pixelu, což na tiskárně jaksi nedáte, takže to musíte zaokrouhlit (navíc často jinak než prostě matematicky, protože písmeno musí zůstat symetrické apod). Aby se tyhle chyby nekumulovaly (může to být cca délka slova na jednom řádku), rozvržení dokumentu na obrazovce tehdy vycházelo z velikosti fontů na tiskárně. Od Wordu 97 je to jinak, a chyba se rozkládá po řádku, což je možné díky tomu, že se v té době přestalo tisknout na jehličkových tiskárnách s nizkým rozlišením.
Pokud se vám layoutu rozpadá, nejspíš je to proto, že ve vlastnostech dokumentu máte nastavené compatibility options pro Word 95. To nastavení se vám přenese například ze šablony, kterou kdysi někdo vytvořil a od té doby stokrát upravil. Stačí si tu compatibility option vypnout, a dokument bude vypadat všude stejně.
Problém s fonty je v tom, že mají více verzí. Například se do nich přidávaly národní znaky, takže ve Wordu 2000 na Windows 2000 nevidíte řekněme čínské znaky, a ve Wordu 2013 naopak zabírají místo. Méně absurdním příkladem jsou aktualizace fontů, které mění velikost znaků - takových je málo, ale několik jich proběhlo. A pokud má stejný font na různých strojích různou šíři písmen, ani nejlepší aplikace dokument s tímhle fontem nevyrastruje bez rozdílů.

Pokud nejste ajták, ta vězte, že Lync i Outlook ve většině firem fungují zcela bez problému. Obraťte se na vaše oddělení, a doufejte, že tam nepracují někteří ze zdejších diskutérů, kteří váš problém "vyřeší" tím, že restartují server :D

PowerShell je součástí Windows 7. Pokud ho tam nemáte, kontaktujte admina. Předpokládám že když byste měl na Linuxu adminem zakázaný bash, asi byste nevinil Linux.

"Pokud vydáváte aplikace psané ve vývojovém prostředí z roku 1988, tak jste to s tou konzervativností zjevně trochu přehnali"

Vy jste to zase poněkud přehnal s tím letopočtem. Jinak si představujete migraci velké aplikace do novějšího VS jak Hurvínek válku. Ono to totiž může být tak pracné a nákladné, že se to prostě nevyplatí.

"Ale jak jsem psal, ve VS můžete pracovat i ve Win7 64-bit."

Tak on napíše, že vyzkoušeli kdeco bez výsledku, a vy zase jak kolovrátek, že může... prostě ROFL :-D

"Word 95 (a starší)..."

Jak jste přišel na Word 95? On nic takového nepsal.

V praci jsem kamenovan za to, ze pouzivame VS2005 (nebo 2003? uz nevim). Nedavno jsem s nekym resil neco tusim v VS2012 a musim rici, ze bych v tom opravdu nechtel programovat. Pominu to, ze spousta binarek nejde spustit na starsich systemech (to uz snad opravili), ale pri vyvoji se resi milion necekanych problemu, ktere ty starsi Visual Studia jednoduse neznaji.

A Win7/8 vs. konsistence Win32 API je kapitola sama pro sebe. Treba dialogy a DPI. Kazdy system (XP/Vista/7/8) se chovaji JINAK. Nakonec jsem zacal reverse engineerovat jak funguje CreateDialogIn­direct, protoze si jej musime implementovat sami (to nakonec tedy po nekolika prekvapenich funguje konsistentne). Jenze ten MS kod je protkany hromadou ruznych ifu ktere lezou do ruznych fieldu struktury dialogu a podle toho vselijak cahruji s bity.

Linux ma take sve mouchy, ale toto mi prijde jako docela zasadni problem. Kdyby alespon ta binarni kompatibilita skutecne fungovala.

Loliku a M$ zaplati par mega za migraci ty appky? Ty zjevne vubec nechapes, ze tu appku nejspis pouze udrzuji => par drobnych zasahu rocne, mozna nejake prizpusobeni legislative. Jop, na to se vyplati to cely prepsat, gratis ... ale v tom pripade rovnou do tuxe. Tam si totiz muzou bejt jisty, ze to skompilujou i za 20 let.

Jedno, vy zřejmě nechápete, že migrace projektu na novou verzi VS je poměrně triviální akce. Překlad aplikace na Linuxu často vyhodí deset obrazovek chybových hlášek i u aktuálních zdrojáků, natož u těch 20 let starých.

Jiste, tak trivialni akce, ze tu appku mozna ani nezkompilujou, a se 100% jistotou nespustej.

No, vzhledem k tomu, jak mizernou VS mívalo (a u C++11 stále má) kompatibilitu se standardy programovacích jazyků, to půjde tak maximálně u C#, které si MS píše sám. Případně se to zkompiluje, ale bude to dělat něco úplně jiného, než u starší verze.

Překlad aplikace na Linuxu vyhodí deset obrazovek chybových hlášek, pokud vám chybí nezbytné knihovny, popsané většinou v README. Ve chvíli, kdy je máte, to zkompilovat půjde.

Zato třeba gcc jde v bezchybné podpoře standardů příkladem :D. Navíc je to pěkná poznámka, ale u migrace projektu ze starší verze VS naprosto mimo.

Ad chybí nezbytné knihovny - koukněte se, kolik open source projektů bylo dávno opuštěno.

To není tak úplná pravda to s tím README. Existuje sice pár projektů, kde autoři svědomitě tyto informace do README zahrnou, ale těch je výrazná menšina. Ve většině případů tam člověk najde pouze vágní instrukce pro ./configure, make, make install a tím to hasne. V lepších případech se ta informace dá ještě najít na jejich webu, případně se dá použít info z balíčkovacího systému. Už jsem ale instaloval i věci co neměly dostupné vůbec žádné info a to pak byla celkem sranda, odhadovat na základě výstupu z configure co tomu vlastně chybí :)

> Jinak VS 6 jsem na Win7 měl nainstalované. Chtělo to trochu přemlouvat, ale rozběhal jsem ho.

Ale vždyť na Windows se takhle přece věci řešit nemusí - zkoušet jak něco rozběhat, ono to přece funguje klik klik klik hotovo... Nebo přece jen ne?

> MS Office je zpětně kompatibilní,

Teorie je krásná věc a věčně zelený je strom života...

> takže byste se vzhledem dokumentu neměl mít problémy.

Mezi "byste neměl mít" a "nemáte" je v podání MS často nepřekonatelná propast...

> Outoook nebo Lync, jde nejspíš o problém konektivity nebo serveru, nikoliv produktu.

A tohle už je LO klasika, vaření vody :-D

> Pokud hledáte použitelný shell, zkuste se naučit PowerShell. Je to velmi silný nástroj.

Ale vždyť jedna ze super features oproti Linuxu je, že se dá vše naklikat a příkazová řádka patří do šedesátých let...

Stačí spustit jako admin setup. Vista a vyšší používají UAC, a setup packages musí mít v manifestu řečeno, že se mají spouštět pod adminem. Starší setupy manifest vůbec nemají (tehdy se nepsaly), takže se spustí vždy s právy běžného uživatele, která na setup nestačí. Proto to spouštění pravou myší Run as administrator.

Mno, dobré je to k tomu, že když to člověk nainstaluje, tak zjistí, že se to pod adminem musí i spouštět, protože pod userem to funguje nějak divně nebo vůbec. Případně musí procházet pekelnou adresářovou strukturu zaplevelenou tisíci linky od čerta k ďáblu, aby zjistil, kde se co vytvořilo, a nastavoval tomu práva. Prostě má o zábavu postaráno :-)

Coz je o to vetsi posusnani, kdyz to potrebuje nainstalova par stovkam useru, kterym z pochopitelnych duvodu admina dat nechce.

O to mi právě šlo - jak se to řeší ve větší firmě, kde uživatelům z principu admina nedají.

To ti muzu celkem slusne popsat.

1) po par dnech/tydnech souboje, se ti povede oddebugovat kam vsude ta appka leze/neleze ... a vytvorit nekolikaset radkovej script, kterej nastavi prislusna prava.

2) prijde prvni patch aplikace, a ty zjistis, ze to leze jeste nekam jinam, alternativne, ze se appka zcela random hrouti.

3) prijde druhy patch ...

4) ohlasis managementu, ze bud aplikaci vymeni, nebo necht rezignuji na jakoukoli bezpecnost, neb des dat vsem userum admina a tudiz zaroven davas zcela ruce pryc od jakehokoli zabezpeceni.

5) management rozhodne, ze ses spatnej admin, a najme jinyho, kterej se na nic nepta a toho admina vsem da rovnou.

6) M$ vymysli, ze admin nebude admin.

Ono byla řeč o instalaci, nikoliv provozu aplikace. K instalaci vám stačí napsat manifest a umístit ho do adresáře se setupem. Bohužel existují admini, kteří manifesty neznají. Čí je to chyba?

Pokud jde o provozování aplikací, které jsou špatně napsané:

1) No jo, spustit Process Monitor a zjistit kam aplikace leze, to může být pro neschopného admina i na pár dní. Pokud jde o debuging, tak si tipnu, že jste debugger v životě neviděl.

2) Ono to možná chce nastavovat zjištěné přístupy na adresáře a větve registry, nikoliv na konkrétní soubory a klíče. Kdo by to čekal? ;)

5) Jo, pokud management takového admina vyhodí, udělá firmě službu.

Chvála bohu, že takové věci na linuxu řešit nemusím.

Jestli ono to nebude tim, ze ten zaostalej tux precijen odjaziva fungoval v user rezimu, aniz by uzivateli porad hazel klacky pod nohy. Takze trebas nepotrebuje roota, kdyz si chce zmenit casovy pasmo, nebo obrazek na plose.

Ke změně časového pásma už nějakou dobu není potřeba admin. Na změnu obrázku na ploše nebyl potřeba nikdy.

Jiste loliku, nejjednodussi je nastavit pristup na "linuxovych" 777 na /. To vyresi vsechny potize.

Takhle to děláte u vás? No jo, profík se hned pozná :D

Tohle nam loliku doporucuje ten slavny support M$.

Hele, a to je jeste vetsi prdel o to, ze ani jako admin spoustejici veci jako admin ... nemuzes nektery veci delat. Nato musis ziskat prava "system", na coz musis pouzit nektery z obskurnich postupu, pricemz ... trebas aktualizacni servis co si naistaluje chromajzl/fire­fox/... pod tim systemem bezi - tedy neco o tak 10 radu nebezpecnejsiho.

Kdyz se v tuxovi prihlasim jako root, a preju si killnout kernel, tak system bez kecu kernel zabije.

Windows neukládají hesla v plain textu, pokud si to explicitně nenastavíte, což se nedoporučuje. U vás to asi máte nastavené.

Windows sice hesla hashují, ale dodnes se nenaučily používat sůl, takže pro zjištění originálního hesla stačí jedno hledání přes Google.

Windows skladují by default hesla ve formě hashe, takže je přes LDAP fakt nedostanete. Z bezpečnostních důvodů ani ve formě hashe.Samozřejmě můžete použít Active Directory Migration Tool, nebo udělat nějakou lobotomii, například DB "implantovat" jinému stroji se stejným SID. Záleží samozřejmě na tom, čeho se snažíte docílit.

BTW proč se pouštíte do věcí, které zjevně neumíte? Já se také nesnažím hrabat do vnitřností instalační databáze RPM nebo tabulek SAPu, protože to není moje specialita. Pochopitelně bych pak narazil na limity svých znalostí, a musel se učit. Daleko jednodušší je práci svěřit člověku, kdo ví co dělá. Sobě ušetříte nervy, a ostatním vaše výkřiky o tom jak to celé nefunguje :)

Jak už tu pan Prýmek psal, Windows vás sice oficiálně nepustí ani k těm hashům, ale bez problémů vás pustí ke stínové kopii disku, a z ní ty hashe dostat je už hračka. Prostě security by obscurity.

To samozřejmě není security by obscurity, ale bezpečnost. BTW nechcete kritizovat, že u Oracle DB můžete louskat soubory uložené na disku? :)

Nikoli loliku, bezpecnost je to, kdyz si admin ty hashe muze klidne cist, ale neni z nich schopen behem par vterin dostat hesla.

Pokud mi systém hází klacky pod nohy při pokusu o nějaký standardní způsob a zároveň mi umožní ta samá data získat postranním kanálem, to asi nic jiného není. Oracle DB nemá problém někomu, kdo má přístup k jeho souborům, také vydat data, co tam jsou.

Přece byste netvrdil, že například permissions nad DB nezvyšují bezpečnost, protože můžete data vydumpovat ze souborů DB.

Nejde mi o útok ad hominem. Jde o to, že jste podle všeho nedělal žádnou migraci ActiveDirectory ani další pokročilou administraci Windows (BTW jak to dopadlo s těmi kvótami?). Na tom přece není nic negativního. Já také nemigroval SAP R/3 na nový stroj se změnou hostname (což je BTW lahůdka). A buď se do toho můžu pustit, nadávat u toho jako špaček, strávit nad tím spoustu času a učit se to na zákazníkovi, nebo k tomu prostě pustím někoho, pro koho je to denní chléb a zvládne to bez problému. A přesně k tomu mířila moje otázka: proč se mordujete s něčím co není ve vašem poli působnosti?

Pokud máte přístup k souborů DB, tak každé normální databázi můžete říct, aby ty soubory načetla a permissions ignorovala. Permissions totiž slouží k tomu, aby uživatelé, kteří nemají přístup k těm souborů, mohly alespoň do jejich části zapisovat nebo je číst (prostřednictvím databázového serveru). Pokud ale má někdo přístup k těm datům, je zbytečné se tvářit, že tam nejsou.

Oficielne si naisntalujes sambu jako sekundarni AD a dumpnes si to z ni? ;D

Hele, cet si nekdy papirovej postup na tema downgrade widli? A zkusil si to nekdy realizovat? Ja kolegovi rikal ze tam volat nema, ze to je zbytecny, ale o mi neveril a zavolal. Citace: "tak si nekde, treba na ulozto, sezente instalacku a cislo nekde opiste". Kolega z toho byl celej den nejakej spatne ... ;D

Takze M$ ti klidne i takovejhle postup zcela oficielne po telefonu doporuci.

Pro downgrade potřebujete instalační médium té starší verze a jakýkoliv platný licenční klíč. Pokud jste používal starší verzi Windows na jiném stroji, měl byste obojí mít.

Obojí? Vážně?

1. Pro downgrade NEPOTŘEBUJETE mít žádné starší widle na jiném stroji.
2. Instalační média pro widle se s notebookama nedodávají!
3. Instalační média nelze sehnat žádnou oficiální cestou, nejsou ke stažení na webu M$.

1. Omyjte si ruce (a přirození) vlažnou vodou, a NEKŘIČTE na mě capslockem! Pro downgrade potřebujete média starší verze OS. Pokud máte starší verzi Windows na jiném stroji, máte i instalační média.
2. Instalační média se s některými notebooky dodávají, jiné umožňují jejich vyvoření.
3. Instalační média jsou ke stažení, pokud jste si licenci koupil přes web MS. Dále jsou je stažení v multilicenčních programech, v MSDN atd. A samozřejmě se dají vyžádat DVD na kontaktním centru.
http://support.microsoft.com/kb/326246/en-gb

Ses zjevne DEBIL. Instalacni media ke stazeni NEJSOU, ke stazeni je VYHRADNE koupena verze! Nehlede na to, ze pravo na downgrade ma kazdy, kdo si koupi Pro a vyssi verzi, nepotrebuje na to mit MSDN.

1. "Pokud máte starší verzi Windows na jiném stroji, máte i instalační média." To NENÍ PRAVDA!

2. Řeč je o čistých widlích, ne o vytvoření instalačního DVD plného toho samého crippleware, který se snažím z kompu vykopat. BTW instalační médium dodává k PC snad jen dodavatelé ve vašem vesmíru, v tom našem jsem se s tím nesetkal.

3. Jo, při požadavku o instalační médium dostanete rady sehnat si jej na torrentech, prosě LOL :-D

Ceskej support doporucuje ulozto ... ;D, a samozrejme, ani je nenapadne se zminit, ze by bylo aspon dobry porovnat hash, natoz aby aspon poslali odkaz na web, kde je. A SN k serverovym widlim se taky shani moc dobre, to je na kazdym desktopu co se valej kolem nalepeny zcela bezne ...

BTW: Pro zajimavost, resil sem zprovozneni terminal serveru na 2k8, a chtelo to (narozdil od starsich widli) licencni server ... tak sem mu ho teda dal, a pak chtel nejaky sileny hausnumero s licenci, ktery sem samo nemel (tu licenci sem mel). Tak sem chvili zkoumal ... a pak sem tam proste flaknul, ze chci 100x a dal tam zcela random cislo ... a ono to proslo ... lol. Takze je to jen dalsi bloatware, kterej stejne nedela vubec nic, jen zere vykon a zdroje.

Jinak si taky celkem dobre pamatuju, jak M$ onehda "vyresil" jakymsi patchem "piratske" widle, a to tak dokonale, ze 80% firemnich stroju se co 5 minut restartovalo, s hlasenim, ze system neni legalni ... samo, vsichni s upiratenejma widlema nemeli vubec zadnej problem.

Lole, tys nikdu necet web microsoftu na tema downgrade? Pro downgrade (na ktery mas pravo) mas zavolat na support M$, kde ti na zaklade cisla tvy verze maji rict SN pro ten downgrade. Ale nereknou, nejspis proto, ze nevedi kde by ho vzali.

Jinak vazne nevim, kde mam vzit placku se serverem 2k8, kdyz se koupil 2k12 ... ke kterymu projistotu neni placka taky, tu si mam od M$ sosnout. Tak nejak bych ocekaval, ze pokud mam pravo na downgrade, tak ze budu mit u toho M$ zcela automaticky k dizpozici i nalezeta iso vsech nizsich verzi. Ale jaksi ... nemam. A proc potrebuju 2k8? No protoze widle jsou tak uzasne kompatabilni, ze 80% aplikaci na novsich nefunguje.

Drahý Jiříčku, na rozdíl od vás jsem tu proceduru četl. A píše se tam celkem jednoznačně, že potřebujete médium starší verze a její licenční číslo. Kdy neprojde aktivace, máte zavolat MS support, a ten vám dá *aktivační* kód, což *není* totéž jako licenční klíč.
http://www.microsoft.com/OEM/en/licensing/sblicensing/Pages/downgrade_rights.aspx

Ad widle jsou tak uzasne kompatabilni, ze 80% aplikaci na novsich nefunguje - to je samozřejmě nesmysl. BTW tenhle problém je typický pro Linux: balíček je určený pro konkrétní verzi konkrétního distra, a instalace na jiné verzi nebo jiném distru je potenciálně silně problematická.

A odkud toto médium a licenční číslo máte vzít se tam už nepíše, že?

Downgrade je určený pro firemní zákazníky. Pokud potřebujete downgradovat, zřejmě to bude proto, že máte spoustu strojů na Windows verze X, a nechcete instalovat na nové stroje verzi X+1. V takovém případě máte instalační média starší verze i licenční číslo.

Navíc už jsem linkoval, že si instalační média můžete objednat na kontaktním centru MS. Pokud máte multilicenční program, MSDN apod., můžete si je i stáhnout.
http://support.microsoft.com/kb/326246/en-gb

Jak uz sem psal, stahnout si muzu leda kulovy. Nehlede na to, ze mi M$ na tom svym hruzawebu zobrazuje tak 1/4 realne koupenych licenci.

a instalace na jiné verzi nebo jiném distru je potenciálně silně problematická

Balíčky obsahují závislosti včetně čísel verzí knihoven. Pokud ty knihovny jsou k dispozici, instalace projde bez problémů a program bude fungovat. Pokud nejsou, instalace selže a řekne vám, jaké knihovny vám chybí. Poté, co ty knihovny nainstalujete (např. ze starší verze toho distra nebo z backportů), tak instalace projde a program bude fungovat.

Ve skutečnosti nastane problém, i když si změníte desktopové prostředí v rámci jednoho distra a nainstalujete balíček vytvořený pro to distro. Ona totiž různá prostředí zakládají položky ve Start Menu odlišným způsobem.

Instalace balíčku určeného pro jinou verzi nebo jiné distro vede na dependency hell. V mnoha případech nelze závislosti vyřešit, a když se je pokusíte přerazit, výsledkem je systém rozdrbaný tak, že pomůže jen reinstalace. BTW instalace knihoven ze staršího distra je potenciální bezpečnostní problém.

Ve skutečnosti nastane problém, i když si změníte desktopové prostředí v rámci jednoho distra a nainstalujete balíček vytvořený pro to distro. Ona totiž různá prostředí zakládají položky ve Start Menu odlišným způsobem.

Opět nemáte pravdu.

Instalace balíčku určeného pro jinou verzi nebo jiné distro vede na dependency hell. V mnoha případech nelze závislosti vyřešit, a když se je pokusíte přerazit, výsledkem je systém rozdrbaný tak, že pomůže jen reinstalace.

A zase nemáte pravdu. Knihovny na Linuxu mají ve svém jménu verzi ABI, stejně jako jména balíčků s těmi knihovnami, takže klidně můžete mít všechny verze dané knihovny jednu vedle druhé. Občas k nějakým kolizím dochází (typicky v datových souborech, protože ty se na rozdíl od kódu neverzují), ale ty lze celkem slušně řešit, a pokud se něco nepovede, lze vrátit systém do předchozího stavu. Způsobem, který na rozdíl od windowsího Obnovení systému většinou dokonce funguje.

Mimochodem pokud by vám to opravdu nešlo, pořád můžete nainstalovat to jiné distro do chrootu a ten program spouštět odtamtud.

instalace knihoven ze staršího distra je potenciální bezpečnostní problém.

Potenciální bezpečnostní problém v té jedné aplikaci, protože jiné aplikace ty knihovny využívat nebudou (jelikož knihovny mají v názvu verzi ABI). Pokud ale instalujete takovou starou aplikaci, navíc staženou odněkud z internetu a ne z repozitářů, měl byste si být vědom příslušných bezpečnostních rizik.

Ad různá prostředí zakládají položky ve Start Menu odlišným způsobem - a co ti kdo se neřídí Desktop Entry Specification? Bohužel to není nijak neobvyklé.

Ad můžete mít všechny verze dané knihovny jednu vedle druhé - ano, se spoustou výjimek. Když vám závislosti propadnou například na verzi glibc, nebo na přítomnost PulseAudio/Open Sound System/ALSA apod., tak jste došel.

a co ti kdo se neřídí Desktop Entry Specification? Bohužel to není nijak neobvyklé.

Které obvyklé desktopové prostředí se tím neřídí?

ano, se spoustou výjimek. Když vám závislosti propadnou například na verzi glibc, nebo na přítomnost PulseAudio/Open Sound System/ALSA apod., tak jste došel.

Všechny minor verze stejné major verze glibc jsou zpětně kompatibilní a různé major verze můžete nainstalovat vedle sebe. Pulse Audio je normální program, takže si jej jako normální program můžete nainstalovat. OSS a ALSA nejsou knihovny, ale jaderné systémy, a jsou přítomné ve všech jádrech od 2.6.0. Problémy dříve nastávaly, pokud jeden program používal OSS a druhý ve stejnou dobu PulseAudio, případně pokud jeden program OSS exkluzivně zamkl, ale to PulseAudio umí už pár let řešit.

"balíček je určený pro konkrétní verzi konkrétního distra"

To samozřejmě není pravda. Kde jste takovou hloupost vzal?

Běží, ta technologie se jmenuje Windows XP Mode. Funguje to tak, že to spustí Windows XP ve virtuálu a v nich ten program. Takovou kompatibilitu umí ale i Linux ;-)

A navic to ani v tech virtualnich widlich behat nemusi. Presto, ze to pod nativnima XP bezelo - vyzkouseno.

To tam asi mají v té virtualizaci nějakou zmrvenou verzi. V tom případě má Linux lepší kompatibilitu s Windows XP než Windows 7 :-D