Kontaktovat podporu. Stejně jako se to dělá na Solarisu, AIXu, HP-UX, IBM i nebo MacOS X. A mimochodem i na RHEL, SLES a dalších.
To je pravda, to udelat mohu. Bohuzel jak ukazuje praxe v komercni sfere, Problem je v tom, ze se nikomu nebude chtit hrabat v molochu, pokud z toho nebude mit profit, ci jej nebude cekat vyrazny postih. Napriklad, pokud mi hypoteticka chyba nezpusobi skodu za nekolik milionu, kterou potom budu po poskytovateli vymahat - a i v tomto je uspesnost dost diskutabilni. Takze se musim pripravit na velmi pravdepodobnou variantu, ze se nikdo nebude mym podnetem zabyvat, ci az za hoooodne dlouhou dobu. Myslim, ze afer treba kolem flas playeru, MS IE nebo samotnych Widows, bylo vic nez dost a mnohe dost zavazne chyby pretrvaly i nekolik verzi (ci pretvavaji dodnes).
Kdybyste to totiž opravoval sám, tak bude hledání chyby, její oprava, testování a dokumentace trvat velmi dlouho, a navíc tak opravíte jen svůj systém.
Ale ja nikde nepisu, ze to nutne musim opravovat ja sam. Znalost internich mechanizmu pod API mi muze umoznit (mimo jine) te chybe predejit. A i kdybych to chtel resit sam - pokud by mi to za to stalo, mozna by me to vyslo i casove a nervove levneji, nez to zadat po technicke podpore. Ve svete opensource je pravidlem (ano existuji i vyjimky, ale tech je opravdu pomerne malo), ze jakmile se objevy chyba, velmi rychle se objevi i patch, ktery ji opravuje . Takze poslu patch a chybu tim opravim pro vsechny.
To je naprosto nesmyslný argument. Vždyť na Linuxu nejsou aplikace kompatibilní ani mezi distry, natož abyste mohl spouštět dvacet let staré binárky. Možná to bude tím, že je to open source 
Pro vývojáře je důležité co API dělá, případně jak dlouho to trvá. Jak se to dělá je interní záležitost OS, a jak jsem opakovaně psal, může se to bez varování měnit mezi verzemi systému.
Zalezi na tom jak definujete kompatibilitu. Jste-li schopen uspokojit zavislosti konkretni aplikace, pak jsou kompatibilni. Ale to je zase problem tvurcu dane distribuce, pripadne jejich uzivatelu. To plati jak pro nejnovejsi aplikace, tak i pro ty stare, protoze presne (jak pozadujete) zaklad je stejny vsech distribucich (jadro, C knihovna, popr. shell, XServer). Je jasne, ze na distribuci bez XServeru KDE nepojede, ale to je preci o necem jinem, nez u monolitickych Windows (ktere maji pry vse potrebne), a presto na hru jedouci na W98 na W7 nerozjedete ani za Boha (treba Return to castle Wolfenstein) :-P Na distribuci bez XServeru je treba staci doinstalovat. Na Widlach se muzete stavet na hlavu, odrikavat mantry , modlit se k velkem Billovi a nepomuze nic. Ne. Ani svecena... ;-)
Na prvním místě pokud nechcete s produktem šířit zdroják (což by nejspíš zabilo váš business), tak musíte najít knihovny s nějakou méně agresivní licencí než GPL. Na druhém místě zjistíte, že autor knihovnu před pár lety opustil, nikdo jiný se projektu neujal, a že bohužel knihovna nedělá co by dělat měla. Na třetím místě řešíte nedostatek dokumentace. Když nějakou vůbec najdete, tak je tragicky stručná. Na čtvrtém místě řešíte nedostatek API systému, protože pokud potřebujete například založit uživatele, zjistit jaké máte v systému daemony, zjistil jestli běží, nebo je dokonce spustit/zastavit, tak zjistíte akorát že API neexistuje.
Srovnejte s tím když najdete na MDSN podrobný popis API, popis konceptu, většinou i příklad, a nezřídka dokonce tutorial. Navíc najdete školení i v malých vesnicích jako je Praha nebo Brno, na trhu je spoustu vývojářů se znalostí věci, a na netu najdete ohromnou komunitu vývojářů se kterými se můžete poradit.
Blbost. Vetsina knihoven - pokud je uvolnovana pod licenci GPL, tak jeji variantou LGPL, ktera umoznuje vyuzit jeji API v propertialnim projektu. A existuji a pouzivaji se i jine. Navic, poskytovat zdrojove kody ke svemu produktu, nemusi bussines ublizit praveze vubec. To za prve. Pokud autor knihovnu opustil a nikdo jiny ji dal nevyviji, pak dela presne to co delala kdyz autor projekt ukoncil, bo zavislosti jsou staticke, libc prekryva zmeny v jadre. To jakoze za druhe
V tom poslednim vam musim dat za pravdu. Na spoustu veci opravdu neexistuje ekvivalentni knihovna. To se treba netyka dneska deamonu (v pripade ze pouzivate systemd), ale to opravdu neni neresitelna situace. Mnoho veci je ovladatelnych pres aplikace/systemove nastroje a vrstvy. Muze jit vsak do tuheho. Nedavno jsem resil, ze nektery z mych projektu potrebuje pristup k urcite skupine deb baliku v repositarich a analyzovat o nich informace a dale je zpracovavat. knihovna libapt je interni a neni doporucovano ji vyuzivat (bo jak sam rikate - muze se bez varovani zmenit), apt, dpkg (a dalsi, vcetne debtags) nevyhoveli jak jsem potreboval. A presto jsem si uspokojive poradil. Cim to asi je?
No tak, jako ta, jak to souvisi s tim, ze na to aby jste rozjel starsi aplikaci na Linuxu Vam stci sehnat jen vyzadovane knihovny v potrebne verzi a pro danou archytekturu? A jak s tim vlastne souvisi MSDN? :-D
Zobrazit příspěvky
