aj mne ale podla mna to tu uz malo byt davno. Ja osobne povazujem za najvacsiu slabinu linuxu prave instalacie programov. Vela krat sa baliky ani nainstalovat nedaju lebo chybaju niektore dependency. Zaujimalo by ma ale ci by sa dal tento system pouzit aj pri offline instalacii a teda, ze si stiahne vsetko potrebne napr. na usb kluc a po preneseny na iny stroj to spusti.
SOUHLASÍM JEN ČÁSTEČNĚ ŽE: Ja osobne povazujem za najvacsiu slabinu linuxu prave instalacie programov.
HLAVNÍ MINUS JE V DRIVER(S) = OVLADAČÍCH pro HW:
1) nejsou ovladače (dosti často)
2) nejsou kvalitní (velmi často)
3) nemají tolik přídavných/přidaných vlastností jako od výrobců HW pro MS-Wind... (téměž vždy, i takový podporovatel HP má pro své tiskárny pro o.s. MS mnohem více fičurek)
tak tuto by som si dovolil nesuhlasit. Okrem mojho stareho scanneru mi moja mandriva vzdy zatial vzdy rozpoznala uplne vsetko (ten scanner mi ale stara mandriva rozpoznavala v pohode tak uvidim co urobi ta najnovsia). Praveze linux je velmi dobry v ovladacoch. Casto ho instalujem namiesto windowsu aj preto, ze windows na niektore zariadenia proste nema kvalitny ovladac (dokonca ani ked je od vyrobcu).
je naprosto super, jak jsou programy svázané s OS. To se jinde nevidí. Chcete v např. v UB9 upgradovat vlc? překopejte polovinu systému a úspěch stejně nezaručen.
je naprosto super, jak se pod linuxem software nainstaluje a nic - žádná hláška, žádná rada jak to spustit, žádný odkaz na nápovědu a většinou ani žádná ikona
je naprosto super, jak si pod linuxem člověk ani nemůže zvolit, kam se má cílový soft nainstalovat. Je jedno, že ti v /usr dochází míst, když máš v /home 1TB - máš smůlu - překopej celej systém abyst v usr místo mě...
...
nekompatibilita balíčků, nebo závislostní peklo už je jenom drobnost, nad kterou nezbývá, než se kysele pousmát.
PS: spusta lidí nenávidí bubuntu - buďme za něj rádi. Alespoň se člověk může spolehnout, že najde k sowtware minimálně debianí balíček
Treba v Debianu jsou backporty. V Gentoo mate system vicemene porad aktualni. Ano, je to svazane, ale spouste aplikaci to nevadi.
A od ceho je dokumentace? A k cemu je ikona, uz i Windows 7 maji integrovane vyhledavani tak, ze kliknete na START a zacnete psat nazev aplikace. Zadna ikonka neni potreba. A navic je to rychlejsi, nez pouziti mysi a ikony.
To je prave vyborne, protoze je jasne, kde co bude. A pokud mate problem s mistem, pouzijte LVM a je po problemu. Misto si upravite za behu.
A co se tyka zavislostniho pekla, taky bych nerekl, ze je to tak strasne. Ten system je proste tvoren spoustou malych casti, proto to musi byt provazane. Diky zavislostem se nemusite o nic starat.
Příklad nedostatečnosti:
Kyocera FS-C5020N nebo HP - ve Widlích se může proporcionálně (využití "pravého" laseru ne LED) zmenšovat a zvětšovat tisky, pro Linux se tisk velmi často například na některé stránce zadrhne (i při dalších nových pokusech) a konec, ve Widlích to jede přitom OK, ...
OKI barevné pro formát A3 (nejprodávanější barevné tiskárny v Česku pro A3) -
oficielně potvrzeno od českého zástupce, že pro Linux drivery nedělají
Mám pokračovat?
tych velkych slabosti linuxu je velke mnozstvo a je to velka skoda. napr nechapem preco nieje aspon moznost stahovat balicky aplikacii uz priamo so zavislostami. pri dnesnych rychlostiach netu a velkosti diskov nema vyznam zdielat kniznice. dalsia slabost su tie ovladace a dalsia slaba pouzitelnost gui a slaba kvalita softwaru. vyriesit tieto 3 hlavne oblasti, podiel microsoftu klesne o 70%
sdílené knihovny jsou už samozřejmě naprostý přežitek a kromě chaosu nepřinášejí žádné výhody, stejně jako monolitické jádro a spousta dalších ptákovin, co byla považována za spravnou cestu v 80/90. letech. Jenže nejsou lidi - tak s tím budeme muset ještě nějaký čas žít.
Škoda jen, že vývoj v linuxu je takový český rychlík M$ a aplle seděj v shinkansenu...trochu se nám ty nůžky začínaj rozevírat
Z clanku jsem to pochopil nasledovne, cekam, ze to nekdo uvede na pravou miru:
- uzivatel si vsechno instaluje sam pro sebe ve svem adresari
"Ty se následně rozbalí na disk a je konec. Tedy je nainstalováno."
takze, kdyz chci instalaci pro vsechny uzivatele, tak se musi kopirovat
- decentralizace uloziste znamena, ze v xml muze byt odkaz na adresu, ktera po roce uz nemusi fungovat, nebo tam muze byt jina verze odkazovaneho balicku, ne?
- zni to, jako ze se nekompiluje a nekonfiguruje - jak se ale naklada treba s dynamickyma knihovnama? Musim tedy mit uvnitr v programu odkazy do zeroinstall adresare, kde (duplicitne) instaluju vsechny potrebne .so knihovny?
- jak resim situace, kdy potrebuju infrastrukturu, ktera je zavisla na zvolene distribuci (nevim, neco v /etc treba). To asi nesmim, ne?
dik za vysvetleni
No z clanku nejako nepriamo vyplynulo, ze to asi prichadza bud so statickymi kniznicami alebo si to vytvara akysi dalsi strom. Kompilovat to nemoze imho, polka distier ani len nema kompilator (alebo hlavicky na crosscompile) a celkovo by sa to nedalo poriadne udrzovat.
Configy v hlavnom strome to asi neriesi, to sa imho ani neda (ak si ten package manazer nedrzi nejake profily, ale aj po tom by bol s tym problem, napriklad rc.conf ma distro dependent syntax, casto nie su kompatibilne ani len medzi verziami distra).
Ja som sa uz na binarky vykaslal uplne, ficim na Gentoo (automaticka kompilacia, resp nieco mam manualne pokompilovane).
Balíčky co jdou nainstalovat na jakýkoliv systém s RPM řešila tuším LSB specifikace, takže pro RPM by univerzální balíček měl jít vytvořit (nezkoušel jsem). DEB je co vím kompatibilní minimálně mezi Ubuntu a Debian. Takže stačí vytvořit DEB a RPM balík, a to už se dá. Je to výrazně lepší řešení než popsaný 0conf - používá standardní balíčkovač, neinstaluje duplicitní knihovny do nestandardních cest, které pak nikdo neudržuje, nedochází ke kolizi verzí v systému.
0conf je použitelný jen pro instalaci několika málo doplňkových programů - kdyby se jím instaloval celý systém, tak to nedopadne dobře. Nápad zajímavý, mělo by se to ale předělat tak, aby to spolupracovalo se systémovým balíčkovacím systémem, minimálně má-li uživatel administrátorská práva. Je-li v požadavcích programu třeba GTK, měl by se nejdříve zkusit nainstalovat přes systém. Pokud ne, měl by se stáhnout z dané URL a vytvořit z něj standardní balíček. Stejně tak by se měl vytvořit standardní balíček z instalovaného programu - když už je k dispozici XML s popisem, měl by z něj jít vygenerovat .spec soubor.
Možnosti tu jsou, záleží ale také na tom, odkud bude probíhat adopce*:
* Bude-li vše "tlačeno" pouze z 0install, asi nebudou mít chuť to udržovat pro více balíčkovacích systémů. V takovém případě bych tomu ale nedával moc velké šance na úspěch.
* Bude-li to "taženo" z nějaké distribuce, je otázka, proč tím nenahradit víceméně celý balíčkovací systém. Pokud to zvládne globální cache... Asi by teda bylo potřeba vyřešit věci jako kernel packages a případně napsat nějaký wrapper pro repozitář. Ale může to skončit na zpětné kompatibilitě se starými balíčky.
* Bude-li to tlačeno komunitou okolo distribuce nebo bude-li zájem o zpětnou kompatibilitu, může se skutečně něco takového objevit. Hlavní problém by ale mohl být v tom, že by bylo asi potřeba pro každý balíček udržovat informace o jeho náhradě zvlášť. Jinak v tom principiálně nevidím problém. Že může časem dojít k odinstalaci systémové knihovny? No a co? Tak si akorát uživatel při dalším startu chvilku počká na stažení.
Zajímavý by byl i nějaký 0linux založený víceméně jen na tomto systému, jak jsem naznačil.
*) Za návrhy lepší alternativy ke slovu "adopce" v tomto kontextu budu vděčný.
Bude-li vše "tlačeno" pouze z 0install, asi nebudou mít chuť to udržovat pro více balíčkovacích systémů.
To nebude potřeba - stačí backend pro RPM a DEB, který to XML přeloží do příslušného formátu.
Bude-li to "taženo" z nějaké distribuce, je otázka, proč tím nenahradit víceméně celý balíčkovací systém.
Protože v tom nejsou systémové balíčky. Nejspíš ani nikdy nebudou - autoři nemají ambice udělat vlastní distro. Pak je ale nutné spolupracovat s existujícími systémovými balíčkovači, jinak vzniknou nejen ty duplicity a nekonzistence, ale také to nebude umět vyřešit velkou část závislostí.
Hlavní problém by ale mohl být v tom, že by bylo asi potřeba pro každý balíček udržovat informace o jeho náhradě zvlášť.
Tomu úplně nerozumím - 0install primárně instaluje balíčky, co v systému nejsou, a ty se nahrazovat nebudou.
No hlavně tohle není moc zacílené na korporace. Ty mají svoje prostředky na to, jak spravovat software. Instalací do HOME je to vyloženě zacíleno na "koncáky". Ti nechtějí nic řešit.
Google Chrome se taky instaluje do profilu, ale k dispozici je DEB/RPM balík, který jde normálně do /opt.
Zero install jak to tak vypada tak je idelalni pro closed source software.
Pac co se tyce open source vyvojaru tak ty se moc o balicky rekl bych nestaraji.Proste nechaji at si vyvojari jednotlivych distribuci (debian,redhat,suse,archlinux ... atd) udelaji ze zdrojovych kodu svuj balicek sami a ten pak zaradi do repozitare.Urcite to usnadni zivot tem kdo chteji vyvijet a prodavat software i pro linux a nemaji silu vytvaret balicky pro x verzi distribuci linuxu.V praxi by to vlasne bylo asi tak ze mate naistalovany jakysi univerzni linux ve sve oblibene linuxove distribuci.Pokud by takhle sla napr Catia nebo Unigraphix namontovat do linuxu s radosti bych to uvital.To je jediny co u me prekazi prechodu desktopu na linux z konkurecniho prasteneho operaku.Pracovni zivot by se mi o dost zjednodusil. :-)
Tak tak. Když se to vezme čistě z praktického důvodu, je to zajímavý nástroj. Nicméně něco podobného už tu bylo před 3-4 lety. Už si nevzpomínám na název. Naprosto stejný koncept. Neuchytilo se to.
Spíš než univerzálním balíkováním se Linux na desktopu spíš vydá směrem do cloudu. Nebude se instalovat nic...
Když je tak inteligentní, tak co bude dělat, až se mi po standardním upgrade distribučním systémem změní verze knihoven?
Pokusy o podobné řešení jsem zažil už dva nebo tři a neujal se ani jeden. Protože se mi o verze programů a knihoven stará balíčkovací systém distribuce, tak považuji paralelní metodu, která s tou hlavní nekomunikuje, za zhovadilost. Vždyť to známe všichni - po upgradu přestávají aplikace instalované mimo distribuci chodit. A bordelem myslím soubory nainstalované mimo standardní souborový strom. Že je to v čitelném XML souboru, to mne fakt potěšilo. Až dočtu Knihy džunglí, tak se pustím před spaním do nějakého toho XML...
Namysli mám toto: Mám distribuci F, do ní si přes ZorroInstall natahám soft XX. Distribuce F se mi ale automaticky updatuje a upgraduje, včetně základních knihoven, a to i častěji než jednou za rok. Někdo tady tvrdil, že "soft XX" nebude duplikovat knihovny, protože si při instalaci zjistí, že má vhodné verze již na disku, ty použije, ostatní dotahá. OK. Jenže za rok už mám vyšší verze všeho, od glibc po GTK, a proto, že ZorroInstall nespolupracuje se systémovým správcem software, tak to způsobí, že "soft XX" na nových knihovnách neběží. V tu chvíli by to sice [cit]"principiálně by neměl být problém, když si to může stáhnout a doinstalovat cokoli a kdykoli, je-li to potřeba."[/cit], jenže!
To si vážně někdo myslí, že firma XX bude udržovat léta repozitory s upgrejdama knihoven a binárek? Za rok, nejpozději za dva, bude zdroj pro zeroinstall na webu XX mrtvý, budou tam ležet stejné staré soubory, jako tam byly od začátku, nebo to bude rovnou Error 404. Vaše Fedora nebo Ubuntu nebo Cokoli povýší co půl roku o verzi - myslíte, že někde v té firmě bude sedět chlápek a dělat up-to-date verze jejich softu? Když nebyl schopný udělat blbej rpm balíček?
Pravda pravdoucí. Tím ale končí představa pohodlného balíčkovacího nástroje koncového uživatele. Kdyby každý distribuční balíčkovací systém měl to co má Archlinux v ABS a pacmanu, bylo by po starostech - ze source nejprve stvořit balík pro svou distribuci a pak jej nainstalovat, popř. sdílet v repozitáři.
Nemuzu si pomoci, ale jedine co me napada je: prasarna, windows, neschopnost, amaterstvi.
Vidim podobne pristupy na spouste mist a ve zkratce bych je popsal jako: "Hmm.. to je prilis slozite, ja chudak bez zkusenosti tomu vubec nerozumim.. ale co kdybych to udelal tak jak to umim? To bude super! To bude jednoduche!"
Mam pocit ze 0install je koncept, ktery vznikl na windows, protoze tam to v podstate jinak lip nejde. Proc ale tahat to same do sveta linuxu, kde je diky balickovacim systemum odpocatku poradek, knihovny se neduplikuji a prumerny balicek s programem nema stovky MB ale maximalne par MB?
Takova vec linuxu bere jeho vyhody a zavadi do nej koncepty vznikle kvuli chybam windows, to proste neni spravne.
Navic mam pocit, ze jde o reseni v podstate neexistujiciho problemu - napsat skript ktery ze zdrojaku vygeneruje balicek pro libovolny balickovaci system je otazka desitek minut, maximalne par hodin. A pak se balicky generuji za par sekund.. takze pokud nekdo SW pro linux prodava, tak tech par hodin prace navic by nemel byt problem.
Jenom doufam ze se tohoto zpusobu nechytnou treba vyrobci pneumatik.. ti by treba mohli zjistit "velky problem" - kazde auto ma jina kola.. takze by vytvorili specialni UNIVERZALNI 0install podvozek s UNIVERZALNIMI koly, na ktery se polozi vase auto.. sice to zhorsi prenos energie z motoru, zvysi hmotnost o pul tuny, totalne rozbije tlumeni, vase auto bude vypadat jako hromada srotu, ale bude to prece UNIVERZALNI!!!
Jednak musím souhlasit s názorem belzebuba, a druhak: Lidi proboha, bezpečnost vám neříká nic?
"Navíc to funguje i v systémech, ke kterým nemáte administrátorská oprávnění."
Co to jako je??? To znamená, že instalované programy budou přímo přístupné bez znalosti hesla. Chápete vůbec, jak moc to je nebezpečné? Jedna z klíčových bezpečnostních vlastností Linuxu je právě nemožnost zásahu uživatele do systému bez znalosti rootovského hesla. Zero install tohle ale zcela kazí a tím otevírá cestu malwaru, který by se šířil například po paměťových USB médiích.
Myslím, že je načase začít myslet.
Jakým způsobem otevírá cestu malwaru? Já si mohu spustit bez administračních práv nějaký malware. Ale kam se ten malware dostane? (Nepředpokládám teď díry v kernelu apod.) Tak nanejvýš do globální cache. A co si tam může? Dokud ho jiný uživatel nespustí, tak celkem nic moc. A pokud ho jiný uživatel spustí, tak by ho nejspíš spustil tak jako tak. Nebo mi něco uniká?
Na desktopu není pr*ser, když se zkompromituje systém, ten se dá přeinstalovat za dvacet minut, na desktopu je pr*ser, když vám nějaké zakuklené "rm -rf $HOME" smaže vaše drahocenné fotografie a nezazálohovanou seminární práci večer před deadline. A to takový Zerroshit může způsobit velice snadno. Ano, máte pravdu, stejně snadno, jako kdyby to spustil "tak jako tak". Proto by uživatel neměl být lákán ke stahování a zerroinstallování kdejakého softu, který se válí po netu. Na soft máme v linuxu repozitáře. Zerroinstall je první krok, poslední bude dohadování, zda Avast nebo NOD.
Myslím, že ano, uniká.
Dokud je například webbrowser umístěn /usr/bin, knihovny má v /usr/lib, tak je slušná šance, že se k nim žádný malware nedostane. Pokud je tohle všechno umístěno v HOME, tak kdejaký zákeřný kus SW může snadno změnit chování webbrowseru tak, aby například logoval vaše hesla a posílal je útočníkovi.
0install je zajímavá věc, ale doufám, že je linuxová komunita dostatečně konzervativní na to, aby se to neprosadilo na úkor současných balíčkovacích systémů.
Při povolení sdílení aplikací to už možné není.
Navíc je to pak spíše otázka způsobu provedení útoku. V takovémto případě zase je možné uživateli například nahradit spouštěč aplikace. Stejně úprava prohlížeče bude dělaná prohlížeči na míru.
Jinak postřeh je to zajímavý, ale na to, aby to mělo reálný význam, by se musely udělat v současných distribucích i aplikacích (Python, Java, Firefox, Chrome, ...) celkem rozsáhlé úpravy...
Jo, to je pravda: když jsou programy v místě, kam se nedá normálně zapisovat, vir bez práv roota mi je nemůže nakazit. To je výhodat. Na takové věci, jako kradení dat a odposlouchávání hesel ale práva roota potřeba nejsou, to může klidně dělat i program běžící pod mojím uživatelským účtem.
Neumožňuje 0install instalovat i normálně do systému (ne jenom uživatelům do jejich adresářů)?
Malware se může šířit i bez administrátorských práv. 0install to nijak nekazí, jenom nemá zbytečné omezení, že instalovat může jenom root. Tohle omezení ve skutečnosti nemají ani jiné balíčkovací systémy, je možné si nainstalovat RPM balík, který je tzv. relocatable, někam do domovského adresáře. 0install z toho jenom dělá úplně běžnou věc, která funguje sama. Žádná bezpečnost typu "jenom root může nainstalovat a spustit nový program" na Unixu/Linuxu není a nebyla, je to jenom nešikovnost balíčkovacích nástrojů, která vytváří takový dojem.
Četl jsi článek? Balíky 0installu jsou podepsané taky. Na nainstalování není potřeba repozitář, to je pravda. To je výhoda, ne nevýhoda. Proč bych mě měl systém nutit instalovat jenom z repozitáře? Nejlepší je mít možnost instalovat cokoliv. Nebezpečné to není. Spustit můžu jakoukoliv binárku, která může udělat cokoliv, tak proč mi měl někdo bránit si i cokoliv nainstalovat?
uz to tady myslim padlo.
1/ stahnu si zeroinstall FreePornPlayer ...pustim si ho a pohoda, kdyz po me bude chtit heslo k bankovnimu uctu, asi mu ho nesdelim :)
2/ pouziju firefox z root-only zapisovatelneho adresare, FreePornPlayer nic nenadela a ja spokojene delam internetove bankovnictvi a pritom si poustim porno.
3/ NEBO ..nainstaluju i ten firefox pres 0install, takze muj oblibenej FPP(free porn player) pusteny pod mym uid si pekne muze opatchovat soubory FF a tomu pak uz to heslo k bance reknu..a budu koukat.
Proste stejne jako viry ve windows. Zabranuje to elementarni bezpecnosti pres pristupova prava.
Zjednodusene..
A myslím, že tu padlo i to, že je to nesmysl:
* Když povolíte sdílenou cache, tyto problémy odpadají.
* Je celkem prasárna si spouštět nez jakéhokoli sandboxu nějaký nedůvěryhodný program na účtu, ve kterém zadávám citlivá data. A to za jakýchkoli podmínek. Zmíněný FPP může změnit spouštěče nebo upravit $PATH v .bashrc apod. A může taky (v případě Firefoxu) doplnit něco málo do userContent.css a máte po ptákách. (Teda po penězích...)
Mít uživateslký účet kompromitovaný malwarem pohoda rozhodně není, kradení dat nebo sledování čehokiloliv, co dělám, je velice snadné. Ano, je výhoda mít program nebo obecně jakákoliv data, která si chci chránit, na místě, kam případný malware, co mi např. spustí z prohlížeče, nemůže zapisovat.
> 3/ NEBO ..nainstaluju i ten firefox pres 0install, takze muj oblibenej FPP(free porn player) pusteny pod mym uid si pekne muze opatchovat soubory FF a tomu pak uz to heslo k bance reknu..a budu koukat.
Bohužel, nefunguje to tak, že říkám věci jen jednotlivým programům a ostatní o tom neví. Realita je taková, že kterýkoliv proces může poslouchat, co kterému programu chodí v Xkách za události.
Netvrdím, že je dobré mít všechny programy nainstalované pod uživatelským účtem, pod kterým je používám. Co se mi na 0installu líbí, je:> Bohužel, nefunguje to tak, že říkám věci jen jednotlivým programům a ostatní o tom neví. Realita je taková, že kterýkoliv proces může poslouchat, co kterému programu chodí v Xkách za události.
Tohle je pravda?! O fungovani Xek toho moc nevim, ale cekal bych neco jako, ze zaregistruji input, najdou aplikaci, ktera ma fokus a te ho predaji. Ostatni by meli videt houby.
Ano, tohle je pravda. Xka se drží hesla <i>mechanism, not policy</i>. Cokoliv se objeví na vašem displeji, může kterýkoliv kód, který k němu má taky přístup, sledovat a ovládat. Aplikace běžící pod vaším uživatelským účtem může bez problémů sledovat dokonce i co děláte v okně patřícím aplikaci běžící pod rootem, není v tom žádný rozdíl. Doporučuju si vyzkoušet xinput
podle tohoto článku: The Linux Security Circus: On GUI isolation
Dekuji za novinku, tohle jsem fakt necekal! V tom pripade se divim, ze linux neni uplne stejne zavirovany jako windows. Prece jen, kdo nekdy nezkusil nainstalovat program mimo repozitar(a procet cely zdrojaky):P
Vyplnil jsem bug na xorg, ta slecna se sice tvari, ze je to deffective by design, ale za zminku vyvojarum to myslim stoji.
https://bugs.freedesktop.org/show_bug.cgi?id=38517
Diky.
Už se stalo: https://answers.launchpad.net/ubuntu/+source/xorg/+question/159596
Rozhodně je dobré o tom šířit povědomí a souhlasím s tím, že u budoucího nástupce Xek (Wayland) by stálo za to se nad bezpečností hlouběji zamyslet. Jeho vývoj ale IMHO směřuje jiným směrem: k maximální modularitě, jednoduchosti implementace "cool" efektů a bez ambicí překonat Xka v bezpečnosti.
Linux a Unix obecně není až tak bezpečnostně na výši, jak se může z keců lidí kolem něj zdát, a je zcela reálné, že ho v bezpečnosti budoucí OS Microsoftu hravě strčí do kapsy (viz projekt Singularity - každý program má OS před nainstalováním staticky ověřit; nevýhodou je ale omezení na jedno runtimové prostředí (CLR), nejde spustit libovolnou binárku).
Netvrdím, že z hlediska bezpečnosti je jedno, jestli mám program nainstalovaný ve svém domovském adresáři, nebo v systému, kam jako uživatel nemůžu zapisovat. Tvrdím, že je z hlediska bezpečnosti jedno, jestli mám program nainstalovaný (ať už v domovském adresáři, nebo jinde) 0installem, nebo klasickým balíkovacím systémem (např. RPM). V instalování nebo neinstalování bez práv roota IMHO hlavní myšlenka 0installu není. Ta je v decentralizovanosti, nezávislosti na repozitářích. Jestli se bude instalovat do domovských adresářů uživatelů nebo pod rootem do systémových adresářů, je vedlejší, a obě možnosti můžou fungovat jak s centralizovaným (repozitářovým) balíkovacím systémem, tak s decentralizovaným 0installem.
Pokud utocnik dosahne spusteni zakerneho kodu na cilovem systemu, patchovani konkretnich binarek nejakymi patchi je asi nejpitomejsi zpusob jak dosahout toho o cem mluvite (v zasade spusteni jineho zakerneho kodu).
Vy si kdykoli muzete do obyvaku dat casovanou bombu a ted nadavate na to, ze nekdo udelal pasovy dopravnik, na ktery tu bombu muzete nalozit. Zamyslete se nad tim.
tak nevim, jestli jsem takhle pozde paralelu pochopil, ale ano rikam, ze neni dobre si do obyvaku zavest pasovy dopravnik z ulice, protoze mi po nem lide mohou poslat bombu snaz.
Patchovani muze byt blbost, ale jiste souhlasite, ze soubory do kterych nemuzu zapisovat nejsou nebezpecnejsi nez zapisovatelne.
Myslim, ze pro bfu by to prineslo dlouhodobe vic skody nez uzitku (bezpecnost, tahani knihoven..), imho napsat balicek neni takovy problem(aspon v archu a gentoo ne)
Tak ja to zkusim jeste jednou bez paralely (mela jen naznacit, ze se zjednodusil zpusob instalace, ale nezmenila se uroven zabezpeceni, na dopravnik porad nakladate vy a vy ho spoustite).
Takze, berte jako fakt, ze kdyz se vam v systemu spusti zakerny kod pod vasimi pravy, tak je s vasim uctem konec - nez zjistovat co se kde napachalo, tak je lepsi ho smazat. Ten kod mel mraky snazsich cest, jak se dostat k heslum nez to patchovani. Co se tyce zapisovani - staci jediny vas soubor ktery se pousti a bezpecnost tohoto druhu je v haji. Tak at nechodim daleko, co treba .bashrc?
Takze pokud neuvedete jiny scenar, tak mi pripada, ze 0install bezpecnost nesnizuje.
0install může instalovat někam do $HOME nebo obecně kamkoliv, stejně tak třeba RPM může tzv. relocatable balíčky instalovat kamkoliv. Rozdíl je v tom, že 0install to defaultně dává do $HOME, zatímco RPM si defaultně vyžádá práva roota a instaluje do systému, na nainstalování jinak je potřeba psát nějaké "podivné" příkazy do konzole. V tomto si oba systémy můžou podat ruce. Defaultní chování 0installu se nejspíš dá jednoduše změnit a jak jsem říkal, v něm jeho podstata a hlavní rozdíl oproti ostatním balíkovacím systémům nespočívá.
0install nainstaluje závislosti (nemusím je shánět sám) a přitom nepotřebuje centrální repozitář. S takovým systémem už nebude Linux roztříštěný v tom, co si kde můžu nainstalovat za balík, kdo používá jaký balíkovací systém a jaký repozitář. Prostě si budu moct najít balík a nainstalovat ho a nechat aktualizovat přímo od výrobce, nebudu závislý na tom, aby mi to distributor správně ubalil pro moje distro a zařadil do repozitáře. Tahle svoboda a decentralizovanost podle mě do světa Linuxu zapadá dobře. Ve Windows už to takhle nějak funguje, ale žádný balíkovací systém tam není, je potřeba to řešit primitivními způsoby: binární instalátory, aktualizace si každá aplikace musí zařídit sama. 0install spojuje svobodu jednoduše instalovat cokoliv přímo od výrobce jako je u Windows s pořádkem linuxových balíčkovacích systémů.
Jako troll se chováš spíš ty. Vysmíváš se 0installu, protože ti připomíná Windows a vymýšlíš nesmyslné důvody, proč je špatný. To, že nespolupracuje s balíkovacím systémem beru, to může být problém. Zbytek jsou kecy a snaha šířit paniku mezi lidma, co se čehokoliv připomínajícího Windows bojí jako čert kříže. "Přípomíná to Windows" není platný argument, proč je to špatné. Ne všechno, co je ve Windows, je špatné. Kromě toho, 0install je jiný než instalace ve Windows. Myslím, že 0install je přínosem pro Linux i pro Windows.
Souhlas s PM.
Nejvetsi sranda ale je, ze Windows vubec zadny balickovaci system nemaji, takze nechapu, jak to muze pripominat Windows. K instalaci SW pro Windows nejsou potreba zadne http servery, definice konfiguraku atd. Cela koncepce obou systemu je diametralne odlisna, protoze i vyvoj SW je celkem dost odlisny. Z tohoto pohledu nebude nikdy Linux pripominat Windows a naopak. Cely tento flame je typicky projev linuxaka do 14let veku, ktery rozjel doma Ubuntu a nyni travi veskery volny cas tim, ze se na diskuzich snazi kohokoliv presvedcovat, ze jedine Linux.Presne lide tohoto typu delaji komunite jenom ostudu, kdyz uz musite pismenkovat takove kokotiny, tak prosim nepsat do prohlizece, ale piste to do vimu a ukladejte do dev/null.Dekuji.
No hovorit o poriadku v repozitaroch by som si zasa nedovolil hovorit. Celkovo ma tento koncept zacina dostatocne hnevat. Niektore balicky si proste svoje dependency niesu schopne stiahnut same a tak som vela krat donuteny hladat po nete co vlastne to mam nainstalovat aby som si naistaloval svoj program. Podla mna sice myslienka to moze byt dobra ale v konecnom dosledku, kazdy spravcovia distribucii musia urobit rovnaku pracu a pripravit balik do svojho repozitara. Celkom nerozumiem preco neexistuje v linuxe jednotny sposob. Tento 0install podla mna tiez nieje dostatocny ale aspon sa niekto snazi rozvirit hladinu instalacii v linuxe, ktore ak si povieme pravdu su hlavny dovod jeho neoblubenosti. Videl som to na ludoch co s nim zacinali. Neboli si schopny pomoct v instalaciach programov. Aj ked si stiahli prislusny balik tak si neboli schopny nainstalovat program. Tato myslienka z windowsu je podla mna velmi dobra. Myslim tym to, ze ked si instalujem program tak sa k nemu nainstaluje vsetko a vacsinou nemusim mat pripojenie do netu ale viem si vsetky dependency preniest v jednom subore. Podla mna linuxu chyba nejaka podobna filozofia a koncept instalacii, inak je to hroza. Ludia proste nemaju cas a ani nervy na to aby stravili hodiny nad instalaciou nejakeho programu. Rovnako treba povedat, ze v repozitaroch vacsinou nebyva novsi soft a tym nemyslim soft vydany pred par dnami. Napr. v zakladnych repo. mandrivy doteraz nieje firefox 4 ale caka sa az na nove distro. Ludia zo starym distrom si mozu bud ist piskat alebo ff nainstalovat manualne .
"vše funguje normálně, akorát binárky, co mám v $HOME/bin nejdou spustit "
To se krapet vylučuje ne? Normální fungování je aby binárky v /home spustit šly, ne? Na co je uživateli vlastní adresář, ve kterém si třeba napíše program v c++, přeloží, ale nebude si ho moct zkusit spustit???
přátelé co tento systém haníte (protože bezpečnost, protože bordel v systému atd.) doufám, že už se nedivíte, proč firmy tak nějak moc nechtějí vyrábět software pro linux. Protože kdyby měli udržovat balíky pro všechny možné kombinace HW/SW, distribucí atd., tak nebudou dělat nic jiného. Takže to obvykle řeší tak, že:
1. - linux nepodporují vůbec a ani nepíší SW pro něj
2. - podporují pouze pár majoritních distribucí RHEL/Ubuntu/Mandrivu/OpenSuse/Debian, s tím že balíky pro RHEL obvykle fungují i ve Fedoře.
3. - použijí něco takového jako je 0install a pak mají reálnou šanci, že si SW koupí/nainstaluje třeba uživatel Arch Linuxu, Gentoo a jiných nemainstreamových dister.
ad 1. to nebude tím, že neexistuje 0install
ad 2. ano, tak se to dělá, a je to OK. Pokud je někdo takový geek, že mu nestačí RedHat, Debian nebo Suse, pak je určitě dostatečně schopný použít rpm nebo deb i na své platformě
ad 3. to si tedy nemyslím
Problém linuxových distribucí není v tom, že neexistuje 0install, ale v nekompatibilitě specifikace balíčků u distribucí. Osobně nevidím důvod, proč například distribuce používající rpm nejsou s to dojednat jednotnou specifikaci. U balíčků specifických pro danou distribuci to chápu, ale proč není možno rozumně sestavit balíček rpm pro program třetí strany tak, aby mohl být instalován v RHEL, Suse, Fedoře i Mandrivě? Pokud by byl rpm formát dostatečně specifikován a dodržován, byla by i konverze do deb jednodušší a nebylo by zapotřebí vymýšlet nesystémové bastly a la Windoze.
On už něco podobného používá např. POVRay, který se dá taky nainstalovat jednak bez práv roota a jednak instalerem nezávislým na balíčkovacím systému.
Faktem také je, že zatímco rpm balíček se dá nainstalovat po stažení ze stránek výrobce programu a nainstalovat z místního disku (buď rpm - volby název_balíčku, nebo spuštěním z MC), u jiných balíčkovacích systémů to tak snadno nefunguje. deb balíček se mi takto nikdy korektně nainstalovat nepodařilo, přes veškeré studium manuálů a dokumentace. Někdy se to dá rozbalit a rozkopírovat ručně (po půldni práce se mi to podařilo např. s novou verzí flashplyeru), ale pokud instalace ještě potřebuje třeba pozměnit systémové proměnné, tak se program zprovoznit nepodaří (jistě to může být i "jenom" nekvalitní dokumentací, kde to prostě není popsáno). Takže balíček deb, který není v originálním repozitáři, jakoby nebyl. (S ostatními balíčkovacími systémy zkušenost nemám.) Tohle může zero install změnit a uživatel může provozovat i programy, které v oficiálních repozitářích nejsou.
Právě že nainstalovat nějakou aplikaci z deb balíčku v jakékoliv jiné než deb distribuci je celkem snadné. Deb balíček je klasický archív rozbalitelný pomocí "ar x balicek.deb" stačí rozbalit třeba do /opt/nazev_aplikace a případně doinstalovat nějaké chybějící knihovny a je to. Běžně jsem si tak vypomáhal, když jsem používal LFS a chtěl jsem nějakou aplikaci jenom vyzkoušet, jestli se mi ji vůbec oplatí kompilovat, prostě jsem si ji takto "půjčil" z repozitářů Debianu či Ubuntu. Fungovalo to prakticky se vším co jsem takto zkoušel bez problémů.
Včera jsem si chtěl nainstalovat novější verzi evolution - 3.0, protože aktuální mi nějak přestala fungovat. Je to jen jeden balík, zkusil jste to? To je prostě nepopsatelné peklo, které zanechalo systém v tak rozbitém stavu, že rychlejší by bylo ho přeinstalovat načisto načisto. To samé v bledě modrém při pokusu o downgrade na starší verzi, která fungovala. Závislosti na knihovnách jsou někdy prostě vražedné a ne vždy jsou všechny programy kompatibilní. (samozřejmě si můžeme hrát s LD_PRELOAD, ale to není zrovna systémové řešení).
Bohužel, mnoho věcí se u různých distribucí liší, takže není obecně možné udělat pro libovolný program balíček fungující na každé distribuci. Tady vidím hlavní důvod, proč se vydávají zdrojáky a každá distribuce si to při balíčkování upraví dle potřeby.
Také je důležité si všimnout, proč je potřeba porušovat LSB. Problém je v tom, že při instalaci více verzí (nebo konfigurací) toho samého balíčku by vznikaly kolize. 0install to řeší virtuálními cestami k programů (URI), ale to je poněkud nepraktické - funguje to jen pro programy, apod. Pokud jste se ještě nesetkali s potřebou se podobné kolizi vyhnout, pak vám to závidím.
Jaké je tedy řešení? Já jsem ho hodně dlouho hledal (používal jsem gentoo) a vyzkoušel různé možnosti. Pak jsem objevil package manager nix a nakonec jsem přešel na kompletní NixOS. Stručné shrnutí:Pokud vás to zaujalo, připojte se. Aktivních přispěvatelů je sice efektivně tak 10, ale celá distribuce je dobře použitelná (používám jako hlavní OS už mnoho měsíců). Hlavně je velmi snadné upravovat nastavení systému, balíčků a přidávání nových balíčků. Pokud se něco pokazí, lze se (skoro) vždy snadno vrátit zpět. Více informací na http://nixos.org (a mailing list, IRC), poradím i sám v rámci svých omezených časových možností.
Stejně musí developer vytvořit balíčky pro všechny ty architektury, verze jádra, knihoven apod. To je ta největší otrava, proto oceňuji spíš služby jako:
http://cs.opensuse.org/Build_Service