Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Windows má sice něco jako jednotný balíčkovací systém (msi), ale jeho použití pro instalátory je spíše vyjímkou :)
Ve Windows je dnes naprosto běžné, že programy si nesou všechna potřebná DLL s sebou a nepoužívají (a při instalaci nepřepisují) ty systémové. A nanejvýš spoléhají na přítomnost běhového prostředí (.NET a pod) a pokud jej nenajdou, vyžádají jeho instalaci.
Neustálé přepisování systémových knihoven instalacemi byl mor, způsobující většinu nestabilit ve starých verzích Windows.
Balíčkovací systém ve Windows neexistuje (asi bych řekl naštěstí), .msi je jen verze instalátoru, připraveného podle MS normy, se kterým umějí pracovat základní prostředky centrální správy softwaru v MS doméně.
Ale porad ve Windows funguje to, ze jakmile se natahne prvni dllka, tak uz tam zustane , a pokud by jiny program chtel tu samou ale starsi verzi /nebo novou/ ta ma smulu, pujde na objekty stavajici.
To neni (tak uplne) pravda :) Tady jde o lenost /duveru v budouci verze/neznalost programatora. Kazdy spustitelny soubor na windows muze obsahovat SxS manifest (xml data jako soubor nebo embednuty v exaci), ten obsahuje blbosti typu "spoustet pouze jako administrator", a pak muze specifikovat verze knihoven se kteryma to funguje. Pokud manifest existuje aplikace dostane od windows presne tu verzi knihovny kterou tam ma napsanou. Jo a tahle moznost existuje minimalne od Win2000 (pokud me pamet neklame tak uz od Win98, ale nechce se mi to hledat).
To ze se nenatahne automaticky novejsi by se teoreticky mohlo stat, kdyz aplikace nespecifikuje verzi knihovny a instaluje si sama novejsi verzi nez je aktualne v systemu. Nikdy sem se s tim nesetkal, takze bych si tipnul, ze je to nejak osetreny. Kdyby nebylo tak to kazdopadne resi restart :)
PBI To čo autor popisuje je static linking a z dôvodu nárokov na diskové miesto sa moc nepoužíva
A aj Linux má univerzálny kolíčkovací systémy napr. zero install
...the Linux philosophy is "laugh in the face of danger". Oops. Wrong one. "Do it yourself". That's it. Linus Torvalds
Ako obvykle ponúknem zopár riešení
- Alien konvertuje dokáže konvertovať RPM a DEB balíčky...
- Kompilácia zo zdrojákov viem vyzerá to odstrašujúco ale ťažké to nie je prakticky sa jedná o ./configure make make install
Ono bohužel nejde o formát balíčku, ani o složitost kompilace, ale o "dependency hell". Jak píše Anička v článku: najde RPM pro Fedoru nebo Suse, ale nejde použít kvůli závislostem. I když to má stejný formát, liší se v distribucích názvy a verze balíčků s knihovnami. V systému s velkou pravděpodobností má vyhovující verzi knihovny, ale protože je jinak označená, nenajde ji to.
Pokiaľ viem s tou spätnou kompatibilitou tých knihovien to nie je najružovejšie
PBI pouzivam vo svojom FreeBSD a rozhodne sa o static linking nejedna. PBI balicky si z portov kompilujem sam, obcas(nginx, uWSGI) sa zide pridat nejake compile-time moduly, cize s portami sa mi pracuje perfektne.
PBI funguje nasledovne, vytvori sa cez chroot komplet cely obraz cisteho OS(skompiluju sa zdrojaky a tak dalej). Potom v tomto chroote sa skompiluje vsetko co treba pre ten dany PBI a odstrania sa veci, ktore patria OS. Toto vsetko sa zabali do uhladne maleho balicka nginx.pbi a da sa to nainstalovat behom par sekund. Cela apka bezi v tom chroote, ktory sa nachadza v /usr/pbi/nginx-amd64/. Tam sa daju najst vsetky konfiguraky, kniznice a podobne one rovnako ako kebyze sa to nachadza v OS len s tym rozdielom, ze to nezasiera system. Doslova to funguje tak ako virtualenv v pythone. A oba systemy su perfektne kvoli dependency hell a v pripade serverovych apps to ma tu vyhodu, ze ci to zaberie 5MB alebo 100MB tak to velmi na 1TB disku nikoho nesere.
Kdyz by bylo vse staticky linkovane a vsechny zavyslosti v kazdem extra balicku (programu) tak by linux mel 30GB jako Windows 8, takova predstava se me teda hodne nelibi ...
Mimochodem jako vzor takovehoto balickovani si brat zrovna Windows neni dobry napad, vzdyt to si uz nepamatujete klasicky windows bordel efekt ? Po roce fungovani bylo treba reinstalovat cely system z duvodu jeho zasvineni ruznyma zbytkama ?
Anička uvedla to největší Win svinstvo, které bylo (a je) - totiž instalaci starých zabalených verzí komponent, aniž by program tušil, že v systému je novější nebo aktuálnější verze. To pak nainstalujete program a stahujete deset záplat. Čili v aktuálním systému se udělá nepořádek, který se pak záplatuje. A takové programy jsou pořád, i na vysoce profesionální úrovni - SONY Sound Forge apod.
jj, a je to i u her, jsou takové, například UT3 nebo MoH co třeba striktně chtějí instalovat tu svou verzi softwaru a když zjistí že už v systému ona komponenta je novější tak se instalace prostě bez jakékoliv hlášky ukončí. Pomůže jen odinstalovat novou verzi, nechat instalátorem nandat starou a po ukončení instalace ji opět smazat a nahradit nejnovější... Kdo tohle vymyslel by si nasloužil pořádně nakopat...
Ano windows je cvalik, jenze microsoft proste nemuze zariznout kompatibilitu, tak neni moc jak to zmensit. Ubuntu bere po instalaci kolem 5GB a to obsahuje jenom x86_64 verze knihoven:/
1)Windows 8 ma po vic jak pul roce pouzivani 20GB. Z toho tak ctvrtina budou hardlinky knihoven z program files :). Zbytek z tech 30GB je swap a soubor pro hibernaci (jdou vypnout). (k tomu pokud vim na linuxu bejvali vycleneny cely oddily, takze to nebylo videt v zabranym mistu na primarnim disku...)
2)Windows 8 obsahuji 4 generace UI (GDI,GDI+, WPF,Metro) knihoven. Nemluve o tom, ze vsechny API jsou tam v x86 a x86_64 verzich najednou.
3)Aby sli spustit binarni aplikace napsany pred 15 lety windows ma pribalene spousty a spousty zbytecnych knihoven a ovladacu, ktere vetsina lidi nikdy nebude potrebovat.
4)Windows bordel efekt, je s windows 7 prakticky neznatelnej (rek bych ze uz od vist, ale to me pak bude kamenovat 2x vic lidi). A v Windows 8 mas dostupnej "reset do tovarniho nastaveni" bez reinstalace. Takze u 12 let staryho sytemu je bordel efekt fakt znat, ale zase jde odinstalovat vsechno vcetne vsech service packu :) Ukaz mi nejakyho linuxovyho blazna co jede na 12 let stary verzi distribuce (nebo dejme tomu 5 let od SP3)
Zákazníci RHEL mají oficiální podporu mnohem delší:
https://access.redhat.com/support/policy/updates/errata/
takže jich bude opravdu hodně. u SUSE bude situace podobna.
pekny to sem netusil :)
"Je škoda, že je linuxový svět tak rozštěpený."
Neni.
...uživatelé linuxových distribucí, kteří nevědí o kompilování či tvorbě deb/rpm balíčků nic (jako já),
Koho problem.
No v podstate Linuxu. Jestli se ma linux nekdy rozsirit k normalnim ne IT uzivatelum tak to nekdy nekdo bude muset vyresit :)
Faktom zostáva že normálnym užívateľom (BFU) spravidla ich IT problémy riešia IT užívatelia a ak nie...
Ak nie, tak si tem BFU raději nainstaluje Widle, protože každý nemá žaludek na to doprošovat se pomoci od arogantních linuxáků ;-)
Toto není flame. Ale mockrát jsem se setkal s odpovědí "RTFM" nebo "Už jsme to tu někde někdy řešili, tak si to najdi..." nebo dokonce "Proč se na to ptáš tady, když už jsi se na to ptal na jiném fóru?"
Lebo seci "windowsáci" su ludomili a kade chodia tade rozdavaju vedomosti, rady a pomahaju ako len mozu.
To je reakce na úrovni ZŠ...
Když chci pomoct, pomůžu. Když nechci nepomůžu. Když potřebuju dělat z někoho debila protože něco neví, jsem ubožák...
Reakcia absolutne adekvatna tvojim kecom.
Sranda je ze nepripustas, ze te otazky sa naozaj daju riesit RTFM.
Videl som to milion krat, a este sa to milon krat stane.
Je naky problem, je dokonale popisany na wiki ako ho riesit, a aj napriek tomu dojde typek, a zacne sa dotazovat na dany problem, pricom je zjavne ze na wikinu ani nepách. Zasivnuje fora, spamuje kanal, a ked ho poslu do prdele tak je urazeny a flamuje dalej.
Co takemu povies? A ked taych mas XY denne? A musis uzdrzovat cistotu a informacnu hodnotu daneho fora/kanalu/atd aby to bolo hodnotne prave pre tych, ktory hladaju naozaj nieco co sa inak zistit neda ?
RTFM.
Nechápeš to. Nevíš, jestli ten kdo se ptá si ten manuál přečetl nebo ne. Není to vždycky trouba. Ale každý nemá půl roku na to, aby si to mohl nastudovat a řešit si problémy sám. Mnohdy ani nevíš, na co se máš vlastně zeptat nebo co hledat. Tak jdeš na nějaké fórum, prohledáš ho, ale vlastně nevíš pořádně co máš hledat, pak položíš dotaz a "bagr" ti napíše RTFM. A po pár pokusech se na to prostě vykašleš, protože potřebuješ, aby to fungovalo a šáhneš po windowsech. A třeba to za rok zkusíš znova. A nebo taky ne. Protože lidi jako ty prostě nový uživatele odpudí...
Link na tú RTFM diskusiu? inak je toto sťažovanie na aroganciu linuxákov len prázdne trolovanie
Linux má už v sebe integrovanú pomerne slušnú nápovedu v sebe man,info a dá sa v nej hľadať pomocou man -k "výraz" alebo apropos "výraz" bez úvodzoviek
Čo keby sme to obrátili ak by autor prišiel na Windows stránku a boli by k nemu arogantný prestal by používať Windows?
Zajímavý názor...
Já teda používám (na rozdíl od Aničky) "Debian-like" systémy, měl jsem *buntu, debian testing a teď mám LMDE (Linux Mint Debian Edition) což je vlastně Debian testing s prostředím cinnamon.. ale abych se dostal k tomu co chci napsat...
na linuxu je divná ještě jedna věc. I když už si nakrásně chcete něco kompilovat (třeba jako já včera - linux kernel) a stáhnete si source přímo od zdroje, postupujete podle návodu, který napsali "linux odborníci", tak to třeba stejně nefunguje. Jo, někdo může říct něco jako "když to neumíš, tak to nedělej".
Mě šlo o to, že mi nešel nainstalovat oficiální driver AMD grafik (teď verze 13.1), vždy už pak systém nenabootoval. Tak mne napadlo nainstalovat si novou verzi jádra (momentálně 3.8.3), ale to nebylo v repositáři dostupné.
Tak jsem ho stáhl, nakonfiguroval (správně, včetně "kernel-debug" a podobných blbostí), zkompiloval, nainstaloval, restartoval systém a ... ejhle... systém po začátku bootu zamrzl. Fakt super... Ještě že jsem si nechal "staré" jádro.
Tak jsem se nakonec musel smířit s tím, že budu mít v systému obstarožní jádro 3.2 a relativně staré ovladače fglrx verzi 12.6....
Tohle je prostě na Windows jednodušší... většina těchto věcí prostě funguje (myslím ty ovladače)... Na druhou stranu kvůli tomu nebudu instalovat windows (nehraju, teda hraju ale hru s názvem "linux a jeho zákoutí")... :)
Používal jsem zprvu Ubuntu, pak jsem přešel a zakotvil na Debian testing.
Problém ATI/AMD grafik je znám dlouhodobě, proto je při stavbě stroje de novo preferována nVidia z těch výkonných. Co se týče chipsetových grafik, tak tam jsem moc problémů neviděl.
Je to u Windows možná jednodušší asi tak v tom smyslu, že je to systém tolerantní vůči chybám v návrhu HW, takže lze bez problémů rozjet příslušenství z asijské tržnice oproti Linuxu. Setkal jsem se ale s opačnými problémy. TV karta Hauppauge 1100 mi na Linuxu jela prakticky hned po instalaci, zatímco na Windows to šlo napřed s obtížemi, později to nešlo vůbec. Další zajímavostí je laserová tiskárna, stará dobrá HP-5L, polofunkční windowsovské ovladače neumí hospodařit s pamětí tiskárny, na Linuxu bez větších problémů.
Mi chces tvrdit ze keby si kompiloval jadro windowsu (ak by si mohol) tak by to dopadlo inak? Zly zly linux, nic nanom nefunguje, ani jadro si neviem skompilovat, sux!
Ked nechces catalyst pouzivaj otvoreny ovladac.
Troufam si tvrdit ze situace, kdy system pri aktualizaci jadra zcela ignoruje moduly jadra, jako jsou treba ovladace od Nvidie, a proste je vykopne, by na Windows nejspis nebyla umoznena. Ve vysledku Ubuntu po zmene jadra (coz udela automaticky) uz nedokaze nabootovat to grafickeho rozhrani. Uzivatel co si to neumi spravit je samozrejmne v koncich.
Je ale třeba si uvědomit, že Debian není pro začátečníky / běžné uživatele určený. O Ubuntu a jeho derivátech můžou jejich uživatelé nakrásno povídat co chtějí, ale v uživatelské distribuci se tyto věci prostě nedějí. Dlouhodobě tvrdím, že Ubuntu není uživatelskou distribucí. Nedávno jsem dával dohromady instalaci Ubuntu jednomu známému, protože se mu po aktualizaci sesypala. Bez znalosti Debianu by to nešlo. A to zdaleka není ojedinělý případ, stačí se zeptat strýčka Googla. Je třeba nepodléhat radám a instalovat uživatelské distribuce.
To je pravda, na Windows byste skoncil s BSOD a nefunkcnim systemem.
Tyjo... Další takovej...
Chce říct, že na windowsu nemusí kompilovat jádro, aby pak zjistil, že to stejně nefunguje.
A reakce "Ked nechces catalyst pouzivaj otvoreny ovladac." je přesně to, co v očích ostatních dělá z linuxářů sektu arogantních machýrků...
Chce povedat, ze sa pusta do pokrocilejsieho ukonu bez zjavneho vedomostneho zakladu.
Chce povedat, ze ked nieco robi prvy krat, tak to vsetko musi hned fungovat spravne.
Chce povedat, ze to neni jeho vina ze to nevie, ze nieco nespravil ako bolo treba, ale ze je to chyba toho systemu.
Chce povedat, ze miesto toho aby to skusal dovtedy az to fungovat bude, zisti kde spravi chybu, nauci sa vsetko potrebne a dostuduje dane informacie, tak sa nato radsej vydlabe.
Chce povedat, ze ked si pobreci nekde na foru, tak magicky sa riesenie zrazu najde alebo ho niekto vycuca z prstu, kde spravil chybu.
Pouzivat otvoreny ovladac je realna alternativa. To ale asi nepochopis.
Som velmi stastny ze som clenom nakej sekty, vzdy som chcel byt v nakom krutoprisnom spolku. Akorat si nepametam ze by som sa niekde hlasil.
papá
Tak kernel není o kompilaci, ale o konfiguraci.
AMD ovladače se zpožděním podporují nové verze čehokoliv. Takže ve výsledku si dáš něco novějšího(třeba to jádro nebo xserver) a ovladač nefunguje. Ale to tam má AMD někde v readme psaný, aby byli z obliga.
A jakou máte grafiku? Budu hádat, buď máte HD 3200 nebo max HD 4XX0. Pak se smiřte, že máte podle AMD "legacy" HW a musíte používat oficiální "legacy" ovladače, max kernel 3.2 a Xserver 1.11. Verze 13.1 mi nešla pro Kubuntu 12.04 nainstalovat.
OSS ovladače z https://launchpad.net/~xorg-edgers/+archive/ppa pod Ubuntu fungují velmi dobře. Pokud chcete nový OS s novým kernelem a Xserverem, nemáte jinou možnost (ABC/buntu 12.10+).
To: hor410
Tak zrovna s ovladači (grafárnami) i ve Windows jsou nehorázné problémy. Stačí novější či starší grafárna, monitor... a už je to šišaté, poblikávající, "prostřihnuté"...
Je fakt ale, že pokud něco z HW dokupuji do Ubuntu (dříve RH, SuSE, Mandriva), tak se vždy mrknu na databázi kompatibility.
Nojo nic není dokonalé, jenže v jaké míře jsou ty nehorázné problémy na Windows a v jaké na Linuxu, v porovnání s počtem jejih běžícíh instalací. :)
A máme aj dáke čísla alebo dôkazy o tých problémoch?
A skúšal autor upgradovať ovládače grafickej kary pomocou WU?
Vzhledem k tomu, že Windows nepodporuji ani 10% hardwaru co Linux, tak bych to moc nesrovnaval. Dokonce i kdyz to zuzime na "bezny PC hardware" veskera podpora u Windows konci se zajmem vyrobce, takze posledni dodany driver je treba pro Windows Vista.
Mimochodem nekde jsem videl od Microsoftu podrobnou statistiku puvodcu BSOD. S podilem pres 40% byly ovladace nVidia :-)
Uvítal bych na Linuxu jednotný propracovaný balíčkovací systém, asi tak na způsob DEB. Ale to by bylo dvojsečné v tom smyslu, že by se mohlo třeba stát to, že by mohly být nesmyslně nakombinovány systémové složky z různých distribucí. V případě systémových složek bude muset být jejich konzistentnost ošetřena. U aplikací by byla výhoda jednotného balíčkovacího systému.
Zase bych ale nerad vývoj Linuxu zcela centralizovaný, to by se z Linuxu staly druhé Windows. On třeba ten výběr pracovních prostředí je výhodou, že si uživatel může vybrat, jaký způsob práce mu vyhovuje. Já preferuji KDE nebo LXDE, prostředí Windows podobná, co do používání. Jiní třeba preferují GNOME, někomu zase přišlo dobré Unity.
Ono by uplne stacilo, kdyby ty dva rozsirene systemy - deb a rpm - opravdu fungovali tak, ze staci mit jedno deb a jedno rpm a na kazde distribuci pujde alespon jedno z toho nainstalovat.
(Netreba psat proc to nejde, duvodu je hromada a vetsina se toci kolem zavislosti)
Tak i ja se pridavam k hlasum z komentaru, pouzivam Mint, Ubuntu, driv jsem jel i pod Debianem, balicky jsou kompatibilni, DEB je skvelej balickovaci system a menit to rozhodne nechci, ze nekdo pouziva Mageiu je jeho (jeji) problem. Jinak nevidim problem proc si holka to BSDecko nevyzkousis - Virtualbox a hned tam to PC-BSD nahod, ja ho provozuju pod Vmwarem a tudiz ti muzu rici, ze PBI je pekna zhovadilost, kdy kvuli kazde aktualizaci tahas misto treba 10MB rovnou vsechno znova teda treba 150MB, navic servry na kterych to maji ulozene jsou vecne nedostupny a pomaly, fakt hnus. Takze ne ne, soucasny system instalaci a aktualizaci pres DEB je to nejlepsi co muze byt a nejake Windowsy nebo cokoli jineho se na to absolutne nechyta!
Balicky jsou kompatibilni protoze to je porad maskovany Debian - tey jeden system. S DEB to nema spolecneho vubec nic. Navic je otazka, kdyz uz je ten DEB tak svely format, proc ho nikdo krome Debianu z nezavislych distribuci s nezavislym vyvojem nepouziva. (klony se nepocitaji, protoze kdyz chteji cerpat z Debianu, musi pouzivat to co Debian)
Kdyby Debian pouzival RPM, fungovalo by to uplne stejne. Prakticky totez plati u RPM, pokud ma nejaka distribuce svoje klony.
Ty sis ale vlastne odpovedel - ti co vychazeji (klidne i historicky) z Redhatu pouzivaji Redhat Package Manager, tedy RPM a ti co vychazeji z Debianu pouzivaji zase jeho format.
Kdyby Debian pouzival RPM, tak by to nedopadlo stejne, protoze, alespon co si pamatuju, kdysi davno RPM neumel (a mozna dodnes neumi) totez co DEB*. A nejspis i naopak, proste kazdy mel asi jine priority.
*) Nevim jaka je soucasna situace, ale kdysi jsem se dopracoval k Redhatu a s udivem jsem se (tehdy) koukal na to ze to vubec nezna zavislosti typu "doporucene"(recommends), "navrhovane"(suggests). Cokoliv z toho bylo u RPMka jako "vyzadovane"(depends). A ty zase mely svoje zavislosti. Instalace takrka cehokoliv tak sebou tahla neuveritelny mnozstvi dalsich veci, ktere jsem nikdy nevyuzil. Krome toho, ze nektere zavislosti byly moc pekne zacyklene.
Já si přisadím trochu z jiného soudku. Přesto, že ke kompilaci běžných programů de facto stačí minimální znalost systému, soubor README a zapojit hlavu, není pro běžné uživatele možností. Myslím si ale, že autorka, stejně jako většina lidí píšících o této problematice, zapomněla zmínit důležitou věc. Lenost uživatele. Distribuce může mít desítky či stovky baličů, ale pokud si uživatel nepostěžuje, že mu chybí nějaká konkrétní aplikace v repu, pak se to nezmění. Z vlastní zkušenosti mohu říct, že pokud jsem si napsal jeden (zdůrazňuji jeden) mail s prosbou o šoupnutí aplikace do repa, netrvalo dlouho a objevil se tam. Samozřejmě ne vždy je to možné - program může být mrtvý, vyžadovat konkrétní verzi staré knihovny apod., což je spíše u aplikací, které v repu asi spíše nechceme :). Pak to samozřejmě nejde.
Ano, u větších dister je nabídka aplikací větší, u menších zase reagují na tyto žádosti podstatně rychleji. Osobně toto vnímám jako bublinu, která se nafukuje zcela uměle. Uživatel je líný napsat mail, ale rozmáznout to na několika fórech problém není.
;-) Lenost uživatele ... Správný výraz. Když mne ještě bavilo vrtat se do distra (už nemám čas, musím produkovat), tak jsem často vyžádal vytvoření balíčku. A světe div se, ono to dost dobře fungovalo. Sic občas jsem narazil na oficiálních stránkách. Ale měl jsem odkaz na nějakou skupinku australanů (nějaká high school) a ti zpravidla do týdne vyhověli, ač někdy mne "proklínali", protože ne vždy to bylo snadné. Potom jsou zde ještě "neoficiální" zdroje, ale ty je, když už, prubnu jen ve virtuálu. Většinou jsou dost nestabilní.
Ještě dodatek. Někdy balíček byli ochotni vytvořit/zajistit samotní autoři zdrojáku.
Ano, funguje to poměrně dobře. Pokud se aplikace do repa jednou dostane, bývá zvykem, že je udržována. Proto nechápu situaci, kdy uživatel chce program a nenapíše si o něj.
Neoficiální zdroje je pojem pro ne ne moc konkrétní. U různých dister bývají komunitní repa, většinou národní a ty bývají udržovány. U nás jich pár taky je (Mageia - Peťoš, PCLinuxOS - Mank atd.) Za neoficiální je považováno i Pacman repo a to je pro openSUSE a Fedoru tuším. A to bychom mohli pokračovat asi dlouho. To jsou repa z mé zkušenosti stabilní. Určitě najdeme různé zdroje, které přepíší systémové knihovny / konfy a tam problém vzniknout určitě může.
Zrovna systém repozitářů považuji, na rozdíl od Aničky, za velmi silnou stránku Linuxu. Stačí, když si jen vzpomenu na utrpění při update čerstvě nainstalovaných Windows, kdy aktualizace systémů, který se nainstaluje za půl hodiny trvá dva dny a Linux bych za nic neměnil.
Windows jsou prostě ohledně instalace a správy aplikací hell a sto let za opicemi proti moderním OS.
Jinak celkem se mi líbí způsob instalace aplikací na Mac OS X, který se zřejmě podobá BSDčkovému PBI, ale ani ten se pohodlí vyhledávání aplikací, instalace a upgrade z repozitářů neblíží (i když to částečně řeší App Store).
Můžu potvrdit, jak skvělý je systém repozitářů. Měl jsem tu čest na dvou strojích instalovat jak Windows, tak Linux. Ve Windows jsem musel aplikace jednu po druhé instalovat přes Next, Next, Next, Finish. V Linuxu tam je to o něčem jiném. Ve správci balíků si vyberu, co vlastně tam chci nainstalovat za aplikace a sjede se to klidně jedním vrzem.
Tahle diskuze je opět ukázkou, že internet snese úplně všechno :-) Ve skutečnosti žádný problém RPM vs. DEB neexistuje, protože i kdyby všechny distribuce používaly stejný formát balíčků, stejně by nešlo instalovat balíčky z jedné distribuce do druhé, protože problém jsou konkrétní zavislosti na konkrétních verzích jiných balíčků, odlišnosti v použitém softwaru i struktuře filesystemu.
Pokud tady někdo chrochtá blahem nad DEB balíky, pak si jaksi neuvedomuje, že DEB balíčky používá jediná distribuce - DEBIAN. To že existují další distribuce typu Ubuntu, které periodicky vykrádají Debian Unstable a Testing pak má za následek, že jsou z pohledu uživatele spolu kompatibilní. (i když u Ubuntu už to přestává 100% platit). Nijak to nesouvisí s formátem balíku.
+1 děkuju
Jiste, ale faktem proste zustava, ze Debian a jeho klony nemaji zadny problem, pricemz Debian neni uplne uzivatelsky nejprivetivejsi - pro BFU, takze tady je Ubuntu a komu se Ubuntu nelibi ma Mint. Diky kompatibilite balicku je instalace programu super jednoducha. Napriklad nahodim Mint, jednorazove pridam zdroje pro Ubuntu, nainstaluju co potrebuju a od te chvile uz se nestaram, vsechno se automaticky aktualizuje, uzivatele Windows mohou jen tise zavidet. Uznavam, ze na Fedore a balickovacim systemu RPM to takhle funguje taky a taky nepredpokladam, ze by si nekdo stezoval. Cely clanek je vlastne jeden velky nesmysl, kdy si autorka neuvedomuje nekolik zasadnich veci: 1. Oproti Windows neexistuje zadne zdlouhave NEXT, NEXT, NEXT a nekolika hodinove stahovani vsech aktualizaci nemicrosoft softwaru. 2. Oproti PC-BSD a jeho PBI tahate jen zlomek dat, zadne stovky megabyte ci gigabyty dat. 3. Kdyz se v linuxu nechci vrtat a resit zdlohave kdejakou cipinu, neinstaluju neznamou Mageiu. V Ubuntu diky jeho rozsirenosti vsechno funguje, temer vsechno uz nekdo resil a tudiz na to je nekde na netu navod, z toho samozrejme tezi i Mint, protoze je to vsechno podobny.
Při přečtení tohoto článečku mi na mysl opět vytanulo mé rozjímání o tom jak by se dal ten cloud konečně rozumně využít.
Přijdete s určitým distrem na stránky -> vyhledáte, program co potřebujete -> cloud si to přechroustá dle vaší detekované distribuce i se závislostmi a vyplivne rpm/deb/whatever -> instalujete jeden či více balíků :) A teď mne ukamenujte, ale pro ty co netuší, jak na rpm/deb/kompilaci ze source, pak by toto mohlo být jednodušší než jednotný balíčkovací systém
Mně by se naopak velmi líbilo kdyby windows nebylo prolinkované DDLkama skrz na skrz. Z historických důvodů to chápu - tuším u win 3.0 bylo vykládáno jak je super když programy používají stejné knihovny a tím se ušetří místo.... jenže od dob win 3.0 se toho hodně stalo. Například je jedno jestli mám kopii toho samého DLLka na disku 15x - prostě místa je dost. Stejně tak i RAMka - doby 2MB jsou opravdu pryč. Mně se velmi líbí portable verze programů kdy vše potřebné je v jedné složce a nikam jinam program nezasahuje. Když chci tak si portable verzi Corela nakopíruju na jiný počítač a prostě ho pustím. Nemusím nic instalovat a ani nastavovat. A to ušetří spoustu času. Stejně tak se dobře zálohují programy. Prostě jednou za čas nakopíruju celou složku s programy na externí disk... tedy tak by to fungovalo kdyby byly všechny programy portable - což bohužel nejsou. Odpadly by i problémy s různými verzemi toho samého DLL. Klidně by mohly pro každý program být jiné verze. Ono nová verze neznamená vždy lepší varianta že. Velmi mi vyhovoval systém který byl v MS-DOSu. Prostě jste měli složku s programem a tam bylo vše. Složku (tenkrát adresář) jste prostě skopírovali a šmitec. Ano - v roce 1992 když přišla win 3.0 bylo sdílení super nápad ale dnes to je zbytečné. Dnes není možné mít absolutní přehled o souborech na disku a to mne dost štve.
To je zajímavé představa, nicméně chybná. Sdílené knihovny se nedělají kvůli nějaké úspoře paměti, ale jsou to soubory nesoucí různé (v dokumentaci popsané) procedury, zdroje, objety atp. Na Windows je v nich API Windows, nikdo nepíše nějaké speciální rozhraní pro komunikaci s uživatelem.
Programátor prostě obsluhuje fukce systému a ty jsou "v těch knihovnách". Je to čisté, šetří to práci (nikdo se nestará o to jak "namalovat okno s gadgety"a jak snímat události, když přes to někdo šmrdlá myškou).
No jenže tady nikdo nemluví o systémových službách ale právě o konfigraci která je kdovíkde v registrech a přitažených DLLkách která sice třeba obsahují to samé co původní systémová jenže z nějakého důvodu si program přinesl s sebou svoje verze. Což se ale vůbec nemusí líbit jiným programům které si zase přinesly svoje verze toho samého. Není to uplně běžné ale občas se to navzájem popere tak, že to nikdo nedá dohromady. Takže NE - opravdu tu nešlo základní API. Prostě co není v systému už od základu by mělo být extra a samotný systém tím nezaplevelovat. Nové verze systémových DLL by si měl stahovat pouze systém a ne kdejaká aplikace která tam nasype kdoví co. Koneckonců - místa je na disku dnes už opravdu dost.
Odpovezeno proc je to co bys chtel logicky nesmysl uz ti bylo, dodam jen, ze vetsinou ta prenositelnost programu neni o DLL, ale o tom, ze si ten program neco zapise do registru pri instalaci a pri spusteni kontroluje, jestli to v tom registru je. Jinak to, ze konfiguraky programu jsou ve windows vsude mozne je bordel Microsoftu, v linuxu vis, ze konfiguraky jsou v home a lehce si je dohledas a muzes prenyst na jinej PC.
První větu nechápu - nějaká divná posloupnost slov. Jinak samozřejmě konfugurace v registru je nevídaná zhovadilost tuším od win95. DLLka všude možně a konfugurace v registru je největší zhovadilost windows. Jak by to bylo super kdyby každý program měl vše co potřebuje k svému chodu (krom systému samozřejmě) ve své složce. Manipulace s takovým programem by pak byla pohodička. Prostě kopírovat a nazdárek. Opravdu ty výhody by tam byly. Mi co vyrostli na MS-DOSu a takovou práci s programy pamatujeme víme o čem to je.
Ehm, jen podotýkám, že dynamické knihovny rozhodně nejsou výmysl Microsoftu pro Windows. Knihovny funkcí jsou staré jako multitaskové systémy vůbec, Unix, měla je i Amiga svého času. Ber to prostě tak, že než vymýšlet vymyšlené, programovat naprogramované je výhodnější vědět jaká knihovna danou funkci nabízí a využívat jí. Podle mě je to skvělý systém. Když chci zamíchat polívku, nevymýšlím a nezhotovuji něco vlastního co bych tam vrazil, vezmu měchačku a obvyklým způsobem použiji.
Co poněkud vázlo (vázne) je dozor Windows nad knihovnami do systému přinášenými pomocí instalací programů třetích stran. Obzvláště dříve si programy zcela svévolně přepisovaly knihovny, již dříve instalované, bez ohledu na verzi a občas to dokáže přinášet nepříjemné problémy. To ale není chyba systému knihoven, ale chyba jeho aplikace.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.