Vlákno názorů k článku Arch Linux jako základ moderního desktopu od Tyraenel - mozme si komplikovat zivot takto alebo s win 7 to...
-
Je povinná! (neregistrovaný)
Heh… komplikovat si zivot s Windows, nebo s Archem… ono je to jedno. Bez rozdilu skoncite u funkcni masiny. A brecet nad trochou nastavovani jednou za 3 roky je trochu mimo. Ja radsi Arch, protoze se aspon nemusim otravovat s hnusobama z prostredi Win… Premiru automatizace a bordel jako antiviry vazne nemusim.
Je ale otazka, jestli je potreba popisovat instalaci Archa, kdyz ma docela slusnou dokumentaci.
Navic – Current Release: 2010.05 (17-May-2010 10:43). Je to sice popis instalace ktera nekdy probehla, ale aspon by to mohlo byt zmineno. -
co to (neregistrovaný)
Tyraenel:co to meles? Nebo ti prijde ze operacni system je jen o instalaci? Snad na nem vydrzis dele nez dalsi 2h?:) Ja si nebudu komplikovat zivot majoritnim systemem vecne zavirovany a misty proste nerozsiritelnym a neohybatelnym. Jedu sice na ubuntu ale prechod na Arch bych mozna uvital, uz mi ty skopiciny v Ubuntu trosinku vadi.
-
no me vzdycky dostava, jak ubuntu/debian vsechno skriptuje a automatizuje…
ArchLinux funguje presne podle manualu/ucebnice/googlu/gentoo, protoze nema skoro zadny patche a vychytavky. v ubuntu se sice vsechno dela automaticky, ale nakonec to funguje jen ve vychozi instalaci a jakmile chce clovek neco zmenit, tak se to sype. pomalu kazdy konfigurak prepisuje nejaky skript, takze clovek nemuze ani nic rucne upravit. nejaka uplne trivialni vec, clovek vi jak by ji resil, ale nemuze, protoze by uplne znicil cely ubuntu…
Ale s Archem jsem nadmiru spokojen. Skvely distro, skvela komunita, spousta prostoru se realizovat pokud ma clovek zajem o vyvoj…
(i kdyz bych uvital nejaky rychlejsi init by default jako ma ubuntu) -
MarMax (neregistrovaný)
Ja jsem byl dlouholety uzivatel Gentoo, pak me prestalo bavit cekat na kompilaci (a taky resit bloky pri updatech), tak jsem presel na Arch… (tam taky obcas sice nesel update, ale dalo se to) – a ted jsem pracovne na windows (v praci), doma provozuju co mesic jinou distribuci
Co se mi osobne nelibi na Archu:
- Instalator
- chybejici nastroje k AURu
Btw., kdyz uz Arch, tak bych zmínil i projekt Chakra (http://chakra-project.org/) -
Jo instalator je nekdy otravnej, kdyz pada a nevis proc.. ale instaluje se prece jen jednou. ja tu mam porad stejnou instalaci na notebooku uz par let, pry ale uz je nejaky novy instalator, tak ho treba uz opravili (libi se mi hybridni obraz).
Taky nam bezi arch na velkem produkcnim x86_64 serveru a vse slape jak hodinky… akorat bych rad presel na LTS kernel (v testing uz je novejsi verze, takze zachvili bude stable), aby byla uplna jistota…
Nastroj k AURu neni, protoze to nejsou oficialne podporovany balicky a ArchLinux team se k nim moc nechce hlasit, protoze nema zadnou zaruku co v nich bude… je to proste takova neoficialni sluzba, ktera zatim funguje dobre… ale nastroje se daji sehnat bud primo v AURu a nebo v neoficialnich repozitarich. -
Arch v produkci? Jake mate zkusenosti?
Jak resite updaty? Instalujete uplne vsechny nove verze vseho? Da se to v produkci ustat?
Jak jsem tady psal jinde, na Archu mi citelne chybi neco na zpusob VuXML, aby clovek pripadne mohl updatovat jenom to, co je fakt updatovat nutne…
Predem diky za odpovedi, fakt me zajimaji. -
Jaromír VojtajZlatý podporovatelPokud to bylo na mne, tak jsem zatím zkoušel Arch asi měsíc na vedlejším stroji, takže ne v úplné zátěži. Aktualizace jsem dělal skoro denně a vždycky všechny, jak přicházely. problém zatím nebyl žádný. Uvidíme, jak to bude v zátěži
-
Jaromír VojtajZlatý podporovatel
S tím bych určitě souhlasil a Arch na server nedával. Proto se taky chystám na druhý stroj instalovat Debian Testing, ale až bude Stable…
-
jj (neregistrovaný)
Arch mi bezi na nekolika serverech (nekde klasika Apache/MySQL/PHP, nekde postgres, nekde jako podvozek pod Django projekty, jinde bezi jako postak s postfixem – radove tisice schranek, jinde jako DNS server)… a vsechno slape jak hodinky. Samozrejme musi clovek zapomenout na veci jako testing repo a aspon se podivat co se vlastne aktualizuje. Na desktopu bezne pouzivam testing repo a pacman -Syu treba trikrat tydne a NIKDY se mi za cca pet let nic nerozbilo – je to sice mozna divny, ale je to tak.
Debian je samozrejme naprosto OK, ale stable je obcas opravdu zoufale starej. -
Jaromír VojtajZlatý podporovatel
Já se chystám na LAMP a DB2-C Express a chci dát Testing v minimální konfiguraci pro daný účel. Ale možná bych uvažoval i o Archu – přece jenom jsem se s ním docela pobratřil…
-
Rivon (neregistrovaný)
To, že je Ubuntu založený na Debianu neznamená, že je Debian stejnej. Arch jsem zkoušel a ačkoliv obecně systém nebyl špatnej, tak mi tam blbnul hinting v prohlížeči (zvláštní že jen na některejch stránkách) a ač jsem se snažil jak jsem se snažil, tak jsem to nevyřešil. Debian prostě za 20min nainstaluju, tak 10min instaluju aplikace, rebootnu a mám hotovo ;)
-
hroch (neregistrovaný)
Jo ale to neni chyba Debianu (Ubuntu to zkopirovalo), ale tvoje, ze jsi zvykly na jiny zpusob :). Skripty zacinajici na update-neco jsou naprosto dokonale. Rozplyval jsem se blahem, kdyz jsem poprve rucne neprepisoval /boot/grub/menu.lst a zadal update-grub :).
Nyni bezim na ubuntu: root a home na btrfs (boot ext2) a nemuzu si vynachvalit, ze pridanim par konfiguraku tam kde maji presne maji byt se initramfs spravne updatuje s podporou btrfs, grub z toho oddilu nacte, ale hlavne funguji prikazy update-initramfs a update-grub, takze s instalaci noveho jadra nemusim nic prepisovat ani konfigurovat :) tohle je proste libova zalezitost …
Ale priznavam se, kdyz jsem potreboval vypnout zapinani nejake sluzby, tak jsem hledal neco s rc, protoze skripty v init.d mi prisly hodne pritazene za vlasy :)
btw. cekam kdy se ten btrfs zhrouti :) -
a nemuzu si vynachvalit, ze pridanim par konfiguraku tam kde maji presne maji byt se initramfs spravne updatuje s podporou btrfs, grub z toho oddilu nacte, ale hlavne funguji prikazy update-initramfs a update-grub,
Nemůžu se zbavit pocitu, že tímhle Linux „řeší“ jenom komplikace, který si sám zavařil.
Živě si pamatuju moje překvapení, když jsem poprvé viděl, jak startuje FreeBSD – minimalistický root oddíl, který je UFS a basta + zbytek na libovolných filesystémech.
Bezproblémové, čisté, funkční. Žádné zběsilosti typu initrd nejsou potřeba. Tím méně nějaké skripty, nad kterými by člověk žasnul, že geniálně řeší, aby systém vůbec nabootoval :)
-
Me teda vzdycky komplikovaly zivot spis windows… ani si nepamatuju, kolikrat mi (asi kvuli spatnymu driveru) na WinXP vyskocilo BSOD po kterym se system uz nenastartoval a data neprecetla, protoze byla prepsana tabulka oddilu…
Debian ma zastaraly balicky dobry leda tak na server a Ubuntu si imho hraje na HALa 9000, takze ArchLinux je pro me osobne nejlepsi volba… -
este nepocitam gentoo, ktery poskytuje pravdepodobne vic svobody nez arch, ale jeho kouzlo se projevi predevsim kdyz si vsechny balicky sestavujete sami, coz uz je na me moc geekovske… staci semtam sestavit nejaky balicek, coz ArchLinux imho zvlada na jednicku pomoci ruznych PKGBUILD a makepkg a pripadne ABS nebo AUR (AUR dělá z Archu neco jako wiki operační systém – každý může postovat zdrojové balíčky – sestavovat a instalovat si je samozřejmě nemusí nikdo a doporučuje se přečist si letmo PKGBUILD, než ho spustíte)
-
Jedine misto kde muze byt vandalismus je asi prumerne 20ti radkovy PKGBUILD… zdrojaky se stahnou ze stranek autora daneho SW a zkontroluji se podle checksumu (jsou podporovany ruzne algoritmy). pak je tam BASH funkce, ktera ten balicek sestavi a nakopiruje do fakeroot adresare… to je cely. vzdycky se jenom kouknu jestli tam neni rm -rf / nebo podezdrely obfuskovany kod.
PKGBUILD vypada asi takhle:
http://aur.archlinux.org/packages/pidgin-qip-decoder/pidgin-qip-decoder/PKGBUILD
(+ obcas jsou k nemu pribaleny este patche, .desktop soubory nebo post-instalacni skripty – ktery je v tom pripade taky treba precist. ale nastroje jako yaourt te taky nechtej moc snadno pustit dal, dokud si ho neprectes)
vice balicku zde:
http://aur.archlinux.org/
moje balicky zde:
http://aur.archlinux.org/packages.php?SeB=m&K=Harvie&O=0&PP=250&SO=d&SB=v
(pridavam tam obcas nejaky software ze sklizne, pokud nahodou este v AURu neni) -
jinak pokud myslis, ze by nekdo zamerne treba chtel smazat vsechny balicky, tak jednak jsou zalohy a druhak zatim kazdy balicek muze upravovat jen ten kdo ho vlastni. pokud nemas zajem ho dal udrzovat (pak ti chodi maily, bugreporty a out-of-date notifikace od ostatnich useru), tak se ho muzes zrict (disown) a nekdo jiny si ho privlastni. takze vandal by teoreticky mohl jen smazat vsechny sirotky (orphans), ale kupodivu vetsinu balicku nekdo vlastni.
-
Myslel jsem spíš že by mohl někdo nasadit do balíku keylogger nebo jiné svinstvo. Čekal jsem, že prostě jenom potvrdím co chci instalovat, nemusím se obsahem balíku vůbec zabývat (jako u APTu nebo RPM). Po disownu by si balík mohl přivlastnit „chytrý“ vandal a dát tam nějaké svinstvo. Já bych zavelel
yaourt -Syu –aur
a svinstvo by se mi nainstalovalo jako update. Nebo bych si prostě nevšiml, že to už udržuje někdo jiný (taky proč by nemohl, že) a nainstaloval bych si to.
AUR není oficiální repozitář, takže se asi nedá čekat že to bude stejně bezpečné – u Ubuntu je něco podobného getdeb – každý tam může dát balík. -
Vývojáři GNOME jsou důvěryhodní a navíc to nejde rovnou z upstreamu do ofic. repozitáře, ještě tam to projde kontrolou. Takže můžu víceméně cokoliv z ofic. repozitáře nainstalovat a nemusím to zkoumat. Horší je to v případě, kdy instalace něco poškodí neúmyslně, není žádný rollback. Až Fedora 13 s btrfs by to měla změnit. Windows „obnovení systému“ už pár let má (i zkušenosti s tím se různí).
-
>> Vývojáři GNOME jsou důvěryhodní
Na základě čeho si to myslíte?
Podle mě nejsou důvěryhodní žádní vývojáři – v tom smyslu, že by byla nulová šance, že se zblázní, nebo je někdo podplatí a vrazí do zdrojáků nějaký škodlivý kód.
Jediné řešení jsou dobře nastavené procesy auditu kódu.
>> navíc to nejde rovnou z upstreamu do ofic. repozitáře, ještě tam to projde kontrolou
Jste si jistý, že Linuxová distra dělají zevrubný audit (!) všech změn, které se udály v upstreamu?
Já bych řekl, že dělají jenom testy funkčnosti (a ani to často ne úplně dobře). -
Neříkám, že jsou naprosto 100% důvěryhodní, rozhodně je to ale velký rozdíl oproti situaci, kdy by nebylo jasné, kdo ten balík zrovna spravuje. Je pravda, že aby si někdo mohl balík přivlastnit, musí ho původní majitel disownovat, takže když si je toho nebezpečí vědom a balík nedisownuje, nebezpečí nehrozí.
Jistý si nejsem, myslím, že třeba ve Fedoře se bere kontrola balíků vážně (http://fedoraproject.org/wiki/Packaging/ReviewGuidelines), možná jsem naivní (ono by ale moc nedávalo smysl mít SELinux a všechny tyhle věci a současně umožnit kdekomu udělat si oficiálním updatem backdoor). -
No tak zrovna tohle, co citujete, jsou pravidla pro BALICKOVANI – o kontrole kodu tam (po zbeznym prohlidnuti) nevidim vubec nic.
Navic jak rika znamy bonmot bezpecnost neni stav, bezpecnost je proces. Musi byt jasne definovane, kdo kontroluje co, kam se vysledky kontroly zapisuji, kdo ma zodpovednost, kdo kontroluje, zda kontrola probehla atd.
