Servisní balíček nemá moc smysl, protože změn v takové distribuci je tolik, že jedinou a rozumnou cestou je provést aktualizaci pomocí jejího životního cyklu (většinou 1/2 roku). Na mém Debianu mám cca 3900 programů, a kdybych mel řešit SP asociace a kompatibilitu tak bych nedělal nic jiného.
Takže si myslím, že na aktualizaci musí myslet aplikace samotná, a vlastni OS za mě řeší distribuce.
Servisný balík by sa mal týkať len OS, a mal by (okrem dôležitejších vecí) umožniť, že prípadný záujemca si bude môcť nainštalovať aj novšie verzie niektorých aplikácií. Súčasne by však nesmel spôsobiť, že prestanú fungovať momentálne naištalované aplikácie, čo je v Linuxe dosť problém. Myslím, že ani nie programátorský ako skôr problém modelu vývoja.
Ano, SP "by neměl způsobit, že některé aplikace přestanou fungovat". Moje zkušenost s MS Windows - po aplikaci SP některé aplikace ve spolupráci s dodavatelem vzkřísit jde, u některých to možné není a je třeba se vrátit k předchozímu SP.
To už naozaj niekto nevie vydržať 5 minút bez spomenutia Windows? Ja som písal o konkrétnom probléme Linuxu týkajúcom sa tých servis packov, o ktorých je článok aj príspevok, na ktorý som reagoval. Je tu dilema, či ten servis pack má obsahovať všetok softvér (potom by to asi bola nová verzia daného distra, však?), alebo len OS. Ak by však obsahoval len OS a ponúkal by nové verzie niektorých systémových súborov, určite by zlikvidoval väčšinu aplikácií. Taký Synaptic by zahlásil, že budú odinštalované tieto aplikácie ..., ..., ...a mali by ste síce nový systém, ale nič na ňom.
nechci vyvolávat flame, ale můžete být konkrétní? Ve své praxi jsem nucen intenzivně využívat a spravovat laboratoře s Win, Lin a Solaris a mám li být objektivní, tak musím bohužel říci že M$ jsou na tom s aktualizacemi zdaleka nejlépe.
Aplikace Report Builder (databázové sestavy) v některých kombinacích verze Windows a SP spolehlivě odstřelí databázový stroj. Dá se to řešit zakoupením nové verze aplikace. To ale podstatně zvýší TCO a nepřinese žádný užitek.
Aplikace PECOM (sledování strojů) nepracuje s posledními SP. Dá se to řešit zakoupením nové verze aplikace. To ale podstatně zvýší TCO a nepřinese žádný užitek.
Aplikace BESTKB (komunikace s bankou) používala pro každou kombinaci verze Windows a SP zvláštní sadu knihoven. KB to nyní vyřešila v aplikaci ProfiBanka přechodem na Javu a odstíněním se od knihoven Windows.
Pokiaľ sa problém dá vyriešiť zakúpením novej verzie aplikácie, znamená to to isté, ako to že výrobca priznal chybu. Čo s tým? Ak sa vám stane, že nejaká aplikácia typu Corel Photo Paint pre Linux prestane po nejakom update bežať, poviete, že je chyba Linuxu?
Tie aplikácie, ktoré spomínate nie sú práve bežné (a obávam sa, že pod Linuxom asi nebežia), z bežných aplikácií som za celé roky mal so servis packmi Windows problém len raz, keď mi necelých 24 hodín nefungoval antvír (Nod na čerstvom SP1 pre XP). Záplata vyšla obratom.
Na začátku vlákna tvrdíte, že Linux má problémy s modelem vývoje. Že správný SP by se měl týkat pouze OS a neměl by způsobit nefunkčnost již nainstalovaných aplikací. V posledním příspěvku naopak tvrdíte, že je normální kupovat nové verze programů po aplikaci SP.
Pokud se týká aplikací běžících na Linuxu. ProfiBanka pro přechodu na Javu chodí i pod Linuxem. Pokud se týká aplikace PECOM, konkurence dodává SW Press Monitor, který je také v Javě. Ten nejenom, že nemá problémy s SP ve Windows, ale běží i v Linuxu.
Netvrdím, že je to normálne, tvrdím, že dobrej aplikácii by sa to stať nemalo. Myslím však, že len výnimočne to je chyba SP. Pokiaľ je to tá, tak sa väčšinou vydá (MS to robí občas aj nenápadne :-) ) ďalšia záplata. Ale väčšinou ide skôr o to, že OS začne nekompromisnejšie vyžadovať dodržiavanie nejakého pravidla známeho už predtým (napr.v nastavovaní prístupových práv, umiestnení súborov). Alebo o to, že softvér využíval nejakú nezdokumentovanú vlastnosť či chybu OS. Vo Windows rozhodne nie sú bežné problémy ani so spúšťaním priam historických verzií aplikácií.
To, že softvér bežiaci v Jave nemá problém s SP je normálne - Java je korektne napísaná a preto nemá problémy s SP. Druhá vec je, že javovské riešenia väčšinou nie sú dosť výkonné. neviem si veľmi predstaviť prácu s naozaj veľkými databázami v takejto aplikácii. Obyčajný javovský Arc Explorer je nepomerne pomalší a padavejší ako staručký Arc View.
neviem, a neviem ani celkom na čo narážaš. Nie som nijaký guru. Ale viem si predstaviť prácu s relatívne veľkými databázami (600 000 viet) vo FoxPro alebo ArcGis. Prípadne v Grasse. A práve u tých GIS programov môžem sledovať pomalosť Javy.
