docela bych chtel umet nahlednout jak to bude vypadat treba za 10 let, ani bych se nedivil ze kralem desktopu, zejm. domacich uzivatelu ale i ve firmach bude namisto win android (uz dnes tablety od samsungu galaxy tab pro, galaxy tab s ktere maji 12,2" uhlopricku umoznuji pohodlnou praci, jen k tomu pichnout BT klavesnici a mys), jde uz asi jen o historicky relikt vendor lock-in kdy proste je vsude spousta win aplikaci na ktere bude potreba udelat napojeni na android klienta.. mozna bude vetsina "velkych" aplikaci klient server a penize uz pujdou vydelat jen na te strane server resp. v enterprise prostredi, ja linuxu fandim ale home user nebude chtit dat za support ani vorla, jedine firmy, tam pujde vydelat ale ty uz si nechaj zpracovat TCO analyzy na migraci, implementaci konkretni funkce, portaci, vyvoj ... anebo bude budoucnost hybrid vseho se vsim takova entropie vsech moznych platforem coz by mozna teorii spontanniho chaosu nejlip odpovidalo ...
Android na domácích počítačích v podobě kusu mastného skla, to je opravdu hrůzná představa. Určitě podíl něčeho takového stoupne, ale dominovat to nemůže - lidi přece jen nejsou tak blbí....
Vedle toho zlaté PC s Windows, která můžete vyhodit a nahradit je třeba Ubuntu nebo OpenSUSE, chcete - li.
Existuji nastroje, kde lze nastavit, co ma pri bootu startovat a tak. Ale Android na to z vysoka ...... Jeste existuje sance, ze by to chodilo na rootnutem zarizeni. Az nebudu liny, zkusim vygooglovat, jestli se da rootnout muj sestakovy tablet, protoze opravdu nestojim o to, aby se mi tam sama spoustela ctecka epubu, kterou jsem uz mesic nepouzil a nejmene mesic nepouziji nebo nejaky manager archivu, ktery jsem jeste ani nezkousel pouzit a je tam jen proto, ze by se teoreticky nekdy mohl hodit.
No, to by teda byla výhra. Android, kde je pánem taky zcela nepředvídatelnej Google, vycházející vstříc různejm šmejdům:
http://www.zive.cz/bleskovky/google-zrusil-moznost-zakazat-aplikacim-pristup-k-osobnim-informacim/sc-4-a-171760/default.aspx
Hlavně, že má ve smlouvách, jaká jeho nepoužitelná aplikace má bejt vždy jako výchozí, ale že na rok starym smartphonu nejde nikdy upgradovat Android na novou verzi, protože výrobci pro nový verze bezdůvodně tlačej vždycky i novej hw, to ne.
Fujtajxl.
google se nechova dobre, to je fakt, jenze android a cela komunita na xda-developers.com uz nabrala takovy grady ze ho to semele s jeho manyry ... i na stary stroje s 512 ram jde dat kitkat 4.4, vsechno je resitelne (lbe privacy, nastavit defaultni aplikaci jinou nez od googlu taky jde atd ..) at vyrobci smartfounu, tabletu chtej (poskytujou ota update) nebo ne ...
tady je dalsi aplikace na omezeni toho sdileni privatnich udaju
https://play.google.com/store/apps/details?id=biz.bokhorst.xprivacy.installer
Firmy mají oblíbené Windows zejména pro jejich zpětnou kompatibilitu, schopnost spouštět i 10 let staré aplikace, což je v Linuxu sci-fi. To umožňuje ochranu investic do software, do školení zaměstnanců a podobně.
Také vývoj aplikací pro Windows je zásadně levnější, nejméně o 30 %.
V nejbližší době se nic nezmění a rozhodně Android neovládne korporátní sféru. Může se ale stát, že zaměstnanci budou mít počítačů více kusů na osobu.
Firmy mají oblíbené Windows zejména pro jejich zpětnou kompatibilitu, schopnost spouštět i 10 let staré aplikace, což je v Linuxu sci-fi.
Jejda, na to jste přišel jak? Já tedy rozhodně nemám v Debianu problém pouštět aplikace staré, co deset let, ale třeba i dvacet let! Nehledě na to, že nejsem ani omezen HW architekturou, jako v případě M$.
Také vývoj aplikací pro Windows je zásadně levnější, nejméně o 30 %.
Můžete uvést nějaký zdroj? Nebo podobnými výkřiky trpíte často? Nedívají se na Vás lidé v metru divně?
S GUI aplikačkou máte v Linuxu problém bez rekompilace často i po půl roce a moc dobře to víte. Zdrojáky ke komerčním aplikacím pochopitelně nedostatene, to je doufám jasné.
Je to tvrdá realita, nemá smysl o tom diskutovat. V Linuxu spousta věcí chybí a musí se různě dolepovat a jako bonus je nutnost testování na mnoha distribucích a verzích. Opět to moc dobře víte.
"S GUI aplikačkou máte v Linuxu problém bez rekompilace často i po půl roce a moc dobře to víte."
Hm, já používám některé GUI aplikace i několik let staré a žádný problém nemám.
"Zdrojáky ke komerčním aplikacím pochopitelně nedostatene, to je doufám jasné."
Vážně? U OSS to bývá běžné i u komerčních aplikací. A u státní správy to považuji za samozřejmost.
"nutnost testování na mnoha distribucích a verzích."
A u widlí se tohle jako neděje? Tam to pravda není až tak moc o těch verzích, zato je to např. o HW. BTW o testování se většinou starají maintaineři dané distribuce, nikoliv vývojáři, pokud už je tedy nějaké zásadní testování potřeba.
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 ;-)
"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.
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/
"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
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.
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?
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.
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).
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=3582entry42809). 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.
Aaaaa, uz tu zase mame notebooky od Samsungu s defektnim firmwarem. Na to se vzdy tesim. No, kdybyste daval pozor, tak na foru se resil nejaky notebook od Lenova, ktery se Linuxem take da bricknout, i kdyz z jineho duvodu. Zda se, ze od doby, kdy nas vyrobci v bratrske spolupraci s Microsoftem a dalsimi borci, obstastnili UEFI, jsou defektni firmwary docela modni.
> Je to tvrdá realita, nemá smysl o tom diskutovat.
A z toho důvodu, že to jde tak dobře, má každá druhá verze Windows nějaký "kompatibility mód", pod kterým se mají staré aplikace spouštět, aby možná (nezaručeně) v nové verzi fungovaly?
Na unixoidním systému, když bych to nakrásně potřeboval řešit (jakože jsem nikdy nepotřeboval), není problém si udělat chroot s jakoukoli verzí systému. Prostě něco jako ty Windows kompatibility módy, akorát na steroidech. Přesto to skoro nikdo nepoužívá, protože to prostě není potřeba :)
Jsi vážně komik! Na 64bitových sedmičkách nepustím ani Visual Studio 6 od téže firmy!
Windows je takový omyl IT. Na profi práci absolutně nevhodný, na amatérskou práci naprosto zbytečný - ani ryba, ani rak. Ouřadové by si dodnes vystačili s T/C602 a FoxPro na 286kách s DOSem a neviděl bych na tom nic špatného. Aspoň by ten HW nevyužívali jen na 5%, ale na celých 10 a my bychom ušetřili stovky miliard korun. Peníze naházené do IT ve státní správě jsou vyházené do kanálu. Aby mi z města poslali dopis vyzývající mě k dodání papírů ze stavebního, který sídlí patro nad nimi, zatímco já sídlím 180 kilometrů od obou - tak na to by jim stačil i psací stroj a cyklostyl, když ani v jednadvacátém století, přes všechny ty dvougigové procesory se čtyřmi gigy RAMky a statisíci kilometrů optik, nejsou schopni si to tam vyřídit mezi sebou.
VS6 na Win7 není podporované, ale samozřejmě ho můžete naprosto triviálně nainstalovat. Je potřeba použít setup.exe a spustit ho jako admin (pravá myš na souboru, Run as administrator). Ještě se doporučuje pro IDE nastavit compatibility mode.
Ad ouřadové by si dodnes vystačili s T/C602 a FoxPro na 286kách - sice jste jejich práci neviděl ani z rychlíku, ale zato víte, jaké nástroje jim musí stačit :)
Ad z města poslali dopis vyzývající mě k dodání papírů ze stavebního, který sídlí patro nad nimi - záleží na legislativě, kdo má nárok si údaje ze stavebního vyžádat. Podobné "detaily" samozřejmě nevidíte.
Ad VS6 na W7 64b - Samozřejmě, že takové blbiny, jako run as administrator, compatibility mode, různé kombinace service packů apod. jsme zkoušeli, to opravdu nepotřebujeme od nikoho radit. Oficiální stanovisko z Microsoftu, jehož se nám dostalo, je: NEJDE TO. Jenže íkváci z této firmy asi netušej, že je třeba udržovat i starší projekty, takže jediná schůdná cesta je vmware s WinXP. Tím to samozřejmě nekončí - samovolné updaty způsobují náhodnou nefunkčnost ovladačů apod., kdy jedinou radou z Microsoftu je reinstalace PC, čili zabitý manday, nekompatibila mezi jednotlivými verzemi MS Office je taky úžasná vlastnost, takže vzhled dokumentu je vždycky sázkou do loterie a jeho dodatečná úprava další zbytečný čas a tedy i peníze; co chvíli nefungující Outlook, o Lyncu ani nemluvě! Vedle toho neexistence standardního použitelného systémového shellu, takže automatizace čehokoli vždy velmi problematická; nikdy není jasné, jak a kdy se projeví jaká skrytá nefunkčnost na nástroji vyvinutém pod XP ve W7. K tomu navíc různá chybová hlášení, která jsou sama jakási zabugovaná - ve stylu "Error: ;;@" - jako třeba u toho VS.
Zkrátka jedním slovem - peklo! Jelikož jsme velká firma s dominantním postavením na trhu, přechod na něco jiného se nevyplatí. Ovšem pro menší firmu by obdobné řešení mohlo být smrtící. Netvrdím, že pro nějaké menší projekty s životností pár let ve firmách s pár lidmi by to nebylo vyhovující řešení, ale v našich podmínkách je to opravdu neuvěřitelné množství zbytečné práce a vyhozených peněz navíc. Vzhledem k tomu, že se sám s pár dalšími chystáme založit vlastní firmu zabývající se vývojem specializovaného HW/SW, je tato moje stávající zkušenost k nezaplacení. Raději si měsíc hrát s vymazlováním konfigurace linuxového pracoviště a pak to 10 let v klidu používat, než mít za den vše nainstalované a každý druhý den řešit nějaký problém nebo stupidní vlastnost, která se rozumným způsobem vyřešit nedá vůbec.
Pokud jde o práci úředníků, tak ještě jako student jsem na úřadě brigádničil, takže o jejich práci tak nějak povědomí mám. Jak jsem řekl - T/C602 by jim bohatě stačily - a mnozí z nich na ně také s láskou dodnes vzpomínají.
Pokud jde o zákony - pokud by si tentýž dokument v jiném městě běžně nepředávali, tak bych to i chápal. Tady ale nejde o nic jiného než lenost a zkostnatělost. 20 let dělají neustále totéž, jen k tomu potřebují každé 2 roky nový HW a SW, který jim tu práci nijak nezrychluje ani nezjednodušuje.
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/kontroly.
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.
Hlavni je, ze vzdy rikate, ze Widle spolehlive spusti SW i z doby Widli, kdyz Bill Gates jeste mel deset uhru na cm2 a ted najednou prohlasite, ze SW z roku 88 je zastaraly. BTW, kdyby upgradovali vyvojove prostredi, tak by jim sice na novych Widlich asi bezelo, otazka ale je, jestli by jim pak jeste bezel jejich produkt nebo kolika dosud nevidanymi bugy by trpel a jak dlouho by to davali dohromady.
"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 CreateDialogIndirect, 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.
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.
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 :-)
Krizovým řešením může být http://sourceforge.net/projects/sudowin/.
Na novějších Windows jsou s tím ale prý nějaké problémy (např. http://sourceforge.net/p/sudowin/discussion/480629/thread/45d5d2a0/), což je mimochodem modelový příklad, jak "bez problémů spustím dvacet let staré aplikace"...
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.
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/firefox/... 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.
Tuhle věc taky nechápu. Např. velká lahůdka je, že pánové v MS vymysleli, že hesla v AD se nebudou ukládat do LDAPu. Asi jakože "bezpečnost" nebo nevím. takže oficiální způsob, jak hesla vydumpovat, není.
Ovšem samozřejmě protože admin je admin, tak to může obejít - např. tak, že si vytvoří shadow copy toho volumu, příslušný soubor si vykopíruje a hesla pohodlně louskne, protože o nějakém SHA2 hashi se Windows nesnilo, že.
Prostě klasický příklad, jak znepříjemnit práci legitimnímu adminovi, aniž by to mělo jakýkoli dopad na útočníka.
Ach jo, vy se z te horecnate PR prace jednou sedrete z kuze :) Rikam jasne, ze hesla jdou LOUSKNOUT, cili zjevne v plaintextu nejsou.
A i kdyby byly, tak nejsou v LDAPu, pokud se nepletu, takze nejdou normalnim zpusobem z LDAPu dumpnout a totalne zbytecne otravuji admina tim, ze to musi obchazet.
Pokud o nejakem podporovanem zpusobu, jak dumpnout hesla z AD vite, budu moc rad, kdyz se podelite.
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 :)
> Z bezpečnostních důvodů ani ve formě hashe.
Je zbytecne s vami diskutovat, kdyz vubec nectete, co pisu.
Da se to cele snadno obejit, takze to bezpecnost nezvysuje ani o pid. Cili pokud slo o nejake "bezpecnostni duvody", tak se to nepodarilo naplnit.
> BTW proč se pouštíte do věcí, které zjevně neumíte?
Psal jsem, ze jsem si ty hesla (ve forme hashe) vytahl a rozlouskl. Takze na zaklade ceho se poustite do tohodle utoku ad hominem?
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.
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.
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
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á.
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
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.
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.
Scifi ses tu leda ty, appku napsanou pro XP na vyssi widlich bud nespustis vubec, nebo ji musis hodne poupravit. Appku napsanou pred 20ti lety pro tuxe spustim na libivolnym soucasnym distru, staci ji bud prekompilovat ... nebo si doinstalovat dobovy verze knihoven.
Vyvoj aplikaci stoji presne totez.
Ad appku napsanou pro XP na vyssi widlich bud nespustis vubec, nebo ji musis hodne poupravit - to je samozřejmě nesmysl. Aplikace psané pro WinXP lze na vyšších verzích spouštět naprosto bez problémů. Výjimek je pár - převážně firewally a antiviry (tam se měnilo API) a mizerně napsané aplikace.
BTW jak konkrétně se ty aplikace musí "hodně poupravit"? To by mě fakt zajímalo.
Ad vyvoj aplikaci stoji presne totez - jak a kterých. Zkuste si napsat aplikaci používající skenování a OCR, nebo transakční zpracování dat nad DB a FS.
Nove modernizovane DPI GUI funkce spolehlive rozbiji spoustu aplikaci. Oprava neni uplne trivialni diky totalne domrvenemu designu DPI ve Win32 na W Vista/7/8. Stejne tak filesystem redirection, oboji to vymyslel opravdu s hlavou v (_,_) .
Staci se podivat na obdobne problemy jak je resi OS/X ...