Názory k článku
Debian stable na serveru po letech a jak dál (2)

Nutno podotknout, že drtivá většina neoficiálních repository (včetně backports.org) podporuje pouze jedinou architekturu a to i386. Většinou sice není problém si balík zkompilovat ze zdrojových balíků (pokud se v repository nachází, jsou i takové, u kterých dohledání zdrojů je práce pro Austina Powerse), ovšem často je na to navázáno tolik dependencí a build-dependencí, že to pomalu nestojí za tu námahu (já jsem např. po rebuildu 20. knihovny vzdal snahu dostat elinks z bpo na muj sparc).

Pro kriticke veci pomuze snad volatile. Tam je soucasti i automaticke buildd. Obecny problem alternativnich platforem je v jejich slabsi podpore i mimo Debian. A zase, elinks zrovna serverovou aplikaci tak uplne neni.

Je pravda, ze Debian je asi posledni bastou nas heretiku, kteri pouzivame Linux na tak nemodernich platformach jako je sparc, alpha, mips ... :)

Na druhou stranu je myslim skoda, ze treba bpo nepouziva buildd a nepodporuje vsechny oficialni platformy. Snazil jsem se to Norbertovi navrhnout a je trochu nahlodany, slibil, ze to zvazi, az zacne pracovat na bpo pro Sarge.

Ad elinks a server ... zalezi na definici. Ja rikam "server" necemu, co je zavrene v serverovne a krome obcasne udrzby nikdo nesedi u konzole. Do teto definice mi spadne i viceuzivatelsky system se shellovymi konty, kde se elinks zatracene hodi.

Tse, co je nemoderni na Aplhe? :-) Intel ji kopirovat neumi, jedine AMD aspon nejake myslenky zvlada.

Jinak mas samozrejme plnou pravdu, co se tyce treba bpo. Proto jsem rad, ze volatile s tim pocita od pocatku. Ale bpo by to take prospelo, kazde ma trochu jine zamereni. a co se tyce elinksu, ja vim, ja vim, mas pravdu :-)

Ja vam to preju. Jenze to ma svou cenu a v posledni dobe dost vysokou. Prakticka nepouzitelnost Debianu na i386 v praxi znamena nutnost poohlednout se po jine distribuci. Tim padem obrovske repository vetsinou dobre zbalenych programu (pres 10 000 balicku) lezi ladem jenom proto, ze sefove Debian nejsou schopni zorganizovat release. Docela zajimavy pokus tohle nejak zachranit je Ubuntu. Dal jsem to na dva servery a drzim jim palce. Zatim pohoda.

Nelze zapominat, ze Ubuntu je pupecni snurou spojeno s Debianem, bez Debianu se Ubuntu samo asi neudrzi, i kdyz Mark Shuttleworth ma (zatim) dostatek financi na to, aby si mohl svou distribuci sponzorovat. Pravda je, ze v dnesni dobe koncovym nenarocnym uzivatelum Ubuntu doporucuji take, je to takovy Desktop Sarge se security. Ale server co pul roku? To ne, nic pro mne :-)

Na alphu patri TRU64 a nie nejaky amatersky projekt Linux. Okrem toho Tru64 uz nejaky rok obsahuje gcc, kopletne vyvojove prostredie od Red Hatu a skvelu emulaciu linuxu. Takze vsetky balicky s projektu Alpha linux pod nim idu bez potreby rekompilacie. A Linux je dobry akurat tak na desktop a nie na komercny server.

Ono nestaci, ze tady blabolej hovadiny Windows BFU, ted sem jeste lezou unixovy paka... Bezva. :-/

Na ten uzasny Tru64 se uz dost kasle a neni divu kdyz ma HP svuj vlastni HP-UX...
<flame>na Alphu patri VMS a ne nejaky amatersky projekt Unix :-)</flame>

Jo presne tak... VMS je skvelej system.

Prominte mi mou zabednenost, ale stale nechapu, jak je ten debian staveny a uz vubec ne jeho vyhody. Vyjde stable, ok, je vychytana, parada. A starne. Objevuji se bugy a bezp. diry. Zaplatuji, ok. A v ten moment uz nemam ten vychytanej stable a jsem v dost stejny situaci jako uzivatel jineho distra, nebo se pletu ?
A kdyz k tomu prictu skutecnost, ze vyvojari aplikaci
jedou jaksi v novejsim prostredi a do debianu se to dostává následným doohybáním, tak to tedy nevím. Proti tomu mi mé gentoo prijde jak kristalova studanka.
Za vysvetleni dekuji.

Debian stable starne, ale oprava chyb probiha tak, ze se pomoci security.debian.org opravuji jen kriticke chyby a kosmeticke se nechavaji bez vetsiho povsimnuti. Tyto kriticke chyby se opravi tak, ze jsou opraveny v dane verzi balicku a nemeni se minor verze balicku, tzn. ze napriklad ve woodym je posledni aktualni kernel 2.4.20(priklad) a v kernelu 2.4.27 se objevil local exploit. Tento exploit se opravi primo v debianim 2.4.20 a neuploaduje se nova verze 2.4.28. Vychazeji ze zasady, ze jakoukoli opravou chyb se zanese alespon jedna nova a to se snazi minimalizovat.

Jako velky problem s backporty vidim v tom, ze je vytvareji casto lide, kteri nejsou dostatecne fundovani(alespon z meho pohledu) a neodborne provadeji reseni zavislosti. Diky uploadu techto repository se casto stanou odladene zavislosti ve woodym(sarge) znacne nestabilni a snazi se mi to pak odinstalovat veci na kterych jsou zavisle dalsi sluzby na danem serveru. Po nekolika neblahych zkusenostech s backportovanymi balicky (jako priklad uvadim nefungujici kombinace qmail,vpopmail,courier a VELMI spatnou zkusenost mam s jednim backportovanym balickem mysql 4.0). Proto jsem se ja osobne rozhodl na serverech nenasazovat backportovane balicky, ale radeji pouzivat zdrojove balicky, pripadne si vytvarim .deb balicky sam. U tech se snazim o co nejmensi mnozinu zavislosti, stejne jako to delaji na www.backports.org.

diky za vysvetlenou, ale lepsi dojem z debianu ted nemam, docela me to prijde jako bastl nebo spis slepenec. Kdepak, strom portu je strom portu.Prosim nekamenovat, je to JEN muj dojem.

no, možná zde chybí zmínka o tom proč lidi do debiana jdou: stable verze je rozhodně nejstabilnější linux co existuje. Testing verze, mi dnes přijde též daleko spolehlivější než kdejaká jiná distribuce. osobně jsem zkoušel FC3 a kromě rychlosti mě taktéž zarazila spousta nedodělků, která by se do finálního produktu neměla dostat. velice rychle jsem se vrátil k testing debianu.
Druhým důvodem se velmi sofistikovaný systém správy balíčků, který vám nechá plnou kontrolu nad stavem systému. ostatní distribuce s k němu jenom přibližují

Sprava balicku je velmi propracovana (=sofistikovana pro anglicky mluvici Cechy) jak v Debianu, tak v Gentoo. Pouzival jsem obe a myslim, ze jsou na stejne urovni, i kdyz pouzivaji jinou myslenku (Debian=binarky, Gentoo=kompilacni skripty).

ahoj Oldium-lamo ;-)

s Gentoo máš pravdu, ale já bych řekl, že správa balíčků je na dost vysoké úrovni už i v jiných distribucích ... mám takový dojem, že někteří stále vychází ze stavu před x lety, kdy dselect byl ohromující vymožeností a redhatisté každou chvíli upadali do "dependency hell" - to už je ale fakt dávno; zatímco u .deb jsem pokrok nepozoroval, .rpm systémy jsou dnes úplně jinde ...

Tohle jsem cetl nekolikrat, usilovne se snazic pochopit, zda si opravdu myslite, ze .deb je zastaraly oproti .rpm, ktere ho predbehlo, nebo jen srovnavate .rpm s jeho predchozimi verzemi (kdy do tech novejsich byly proste pridany schopnosti okopirovane z Debianu, pripadne rovnou naportovane nektere Debiani aplikace). Ac uz je to mimo tema clanku, docela by me zajimalo, co vam na .deb chybi. Gentoo-like lokalni autobuildy jsou podporovany. Dselect, uzasna to vec :-), davno neni jediny frontend. Debian ma hromadu klikacich, cucavejsich GUI. Zaroven doslo k vyvoji pravidel u zavislosti do lepsi podoby. Takze bych rad vedel, co Vam chybi, pohledy jinych umoznuji rozsirovat pohled vlastni :-)

> Tohle jsem cetl nekolikrat, usilovne se snazic
> pochopit, zda si opravdu myslite, ze .deb je
> zastaraly oproti .rpm, ktere ho predbehlo,

ne, to si nemyslím - poukazuji na fakt, že ačkoliv u .deb jsem si velkých změn nevšiml, nelze podle toho soudit i ostatní systémy, že se v nich změny nedějí ...

> nebo jen srovnavate .rpm s jeho predchozimi verzemi

přesně tak, mám rpm 4.2.2 a urpmi 4.5, ale mám pocit, že někteří .deb-positivní stále shlížejí na .rpm s despektem, jako kdyby schopnosti odpovídali major číslu poněkud nižšímu ... a to samé nejen pro .rpm, ale portage a další, viz výše

> Zaroven doslo k vyvoji pravidel u zavislosti do lepsi podoby.

s .deb jsem se potkal poprvé cca před pěti lety a naposledy začátkem loňského prosince - možná za to může zčásti má chabá paměť, ale nezdálo se mi, že by se něco změnilo pro mě ... opět některé věci proběhly naprosto hladce a u jiných mi systém nutil balíky, které zcela jistě k provozu daného programu nepotřebuju (kde je to vylepšení?); u gcc jsem dokonce narazil na závislost na jiné verzi gcc-cpp, než byla dostupná (a gcc-cpp pro změnu vyžadovalo jiné gcc) - pravda, ve stable by se to určitě nestalo

... že mluvím o problémech neznamená, že považuji za špatné samotné .deb, nebo za zastaralé (zastarání přeci není přímo úměrné stáří)

Buď rád, že jsi nepochopil jen Debián, já nepochopil celý článek...

no presne :)

Z balicku ? proc

web server (apache + php + mysql/posgre) je opravdu jednodussi nainstalovat to ze src (podpurne knihovny - neni jich malo taky, ale nektere staci z woody distra)

a co se tyce qmailu (spise netqmailu) ten take instalovat ze src + samozrejme clamav + sa

horsi je to potom uz pri explitu v nejake knihovne - pokud je apache slinkovan staticky, tak se musi udelat znova cela procedura, ale i tak se to da

Jiste, a proc tedy vlastne Debian a ne rovnou LFS? Mam pod svou spravou roztodivne servery a tak nemam cas jim davat pravidelne mnoho hodin. Radeji do nich investuji ten cas na zacatku (vyhledani moznosti, overeni stavu) a pak uz je jen hlidam a opatruji. Navic, nektere ty stroje prosly uz nekolika Debian stable vetvemi a nemusely byt reinstalovany po cele roky. A, prekvapive, na nich stale neni chlivek.

ftp2.debian.cz za poslednich 11 mesicu:

grep <distname> xferlog | wc -l

woody: 32856 (stable)
sarge: 40670 (testing)
sid: 121482 (unstable)

Jasne, ze to muze a urcite castecne i je tim, ze unstable lide casteji updatuji (maji radi problemy nebo je to dostatecne stabilni? :-) a mozna take zastoupenim workstations vs. servers.

Ale i tak myslim, ze techto par cisel by melo byt dostatecnych k zamysleni se nad stylem a cilem vyvoje lidi kolem debianu. IMHO vyvojari jdou trosku jinym smerem nez nemala skupina uzivatelu.

To co je popsano v clanku osobne povazuji vice za uctivani woodyho at to stoji co to stoji nez za smysluplnou praci s distribuci.

Podle mne by debian mel zrychlit -- coz znamena delat nektere veci jinak. Mozna udelat nejaky "core" ktery bude obsahovat jen nejnutnejsi veci bez duplicit a bude vyvijen vyrazne rychleji (1/2 roku) a k tomu nejaky "contrib" kde budou tuny dalsich veci, ale vyvijenych pomaleji. Pak by stacilo obcas udelat nejaky milestone kdy se "contrib" stabilizuje na nejaky urcity "core" a vse se prohlasi za "full debian".

Zajimave je treba u fedory existence samostatnych repositories (dag, livna, apod..), ktere se vazou k celkem utlemu zakladu v podobe fedora core.

Ono to taky bude trosku o tom, ze kdyz clovek upgraduje stable debiana na serveru, tak to stahne treba jen 3-5 balicku za tyden (pri kazdodennim upgradovani) a to jeste ze security.debian.org, zatimco u sarge na workstatione upgradovani za tyden stahne tech balicku desitky a vsechny jedou z nastaveneho repository, a u sida jich nejspis bude jeste o dost vic, zvlast kdyz lidi upgraduji treba kazdy den.
Takze tyhle cisla imho nemaji zadnou vypovedni hodnotu o tom, kolik lidi pouziva jakou verzi debiana.

Podivejte se na to jak jsou balicky tahany. V ceste neni jmeno distribuce. Takze ta cisla __nejsou__ ovlivnena poctem stazenych balicku, ale meta soubory distribuce (Packages.gz, Release) apod. Takze "apt-get update". A verim, ze frekvence tohodle prikazu je vice mene podobna pro vetsinu adminu/useru bez ohledu na stable nebo unstable.

Trosku sum tam mohou delat balicky jako je kernel, ktery ma jmeno distribuce v nazvu.

Par detailu:

1) Znam nemalo testingaru/unstalbistu, kteri updatuji denne, to woody lidi to delaji jen, kdyz jim prijde oznameni o DSA

2) Jak poznate, kolik z toho jsou servery a kolik z toho jsou klienti?

=> zcela zcestny pokus o statistiku

No, jednou jsem si na unstable debian doinstaloval z experimental mysql 5 .... no, mel jsem pak co delat abych to dal zpatky dohromady, polovina DB aplikaci prestala chodit a nakonec jsem se vratil k mysql 4. Rek bych ze v experimental jsou veci, co jeste ani autori poradne naodladili (cili kdybych instaloval to samy nebo novejsi mysql 5 ze zdrojaku, bude delat kraviny taky)

Ale jinak to delam stejne - na serveru kde mam stable updatuju jen kdyz prijde DSA, unstable na workstation updatuju skoro denne ....

Ja patrim k tem castym updatovacum. Nedavno se tu psalo, ze CVS verze programu jsou navykove -- a to je pripad i unstable. Proste mame radi nove programy.

Jednak je to dostatecne stabilni (jeste pred unstable je experimental, tam se to asi vybubla), jednak bezvadne funguje apt-listbugs (vypise seznam odhalenych chyb pred instalaci - kdyz je kriticka, neinstaluju). Uz ani nepamatuju nejaky problem.

Cca pred rokem jsem spolupracoval s klukem s Mandrakem -- a mel jsem novejsi verze, ktere maji takove prima funkce... :-)

Rychlost update baliku Debianu byl presne ten duvod, proc me tato distribuce docela znechutila (na Desktop).

Me zkusenosti naposledy nekdy pred dvema roky mi definitivne zavreli cestu k Debianu. Nejednou se mi stalo, ze jsem musel reinstalovat cely system, protoze mi nejaky backport rozhodil kompletne zavislosti a uz nic neslo spustit (minimalne Midnight Commander, glibc problemy...) -- sem tam nejaky --force a slo to do haje. A nejlepsi je, ze stable verze je uz v okamziku uvolneni tak rok stara a kdyz potrebujete mplayer (jakoze nejnovejsi prehraje treba neco vic, nez stary), nebo KDE (nechtelo se mi obchazet stare chyby, ktere byly uz minimalne pul roku vyresene), tak nezbyva nez backport (problemy), nebo pozivat testing verzi Debianu, ale tam take vyvoj nesel prilis rychle. Nakonec se dostanete na unstable Debiana, ale to si uz muzete baliky kompilovat rovnou sami -- a jsme u Gentoo (myslenkou vychazi z FreeBSD), kde se kompilace a instalace provadi primo na stroji s aktualnimi verzemi knihoven (a v pripade nutnosti se updatuji i ty) a baliky (kompilacni skripty) s novymi verzemi se objevuji kazdou chvili :-). (Konec reklamy)

kompilace src baliku neni zadny problem ani v debianu (pripada me to porovnatelne s porty) ... takze v tom bych nehledal az tak vyhodu oproti debianu. Problem je v tom, ze balicky jsou stare. Ja si myslim, ze rozdeleni debinu na core a zbytek by pomohlo zrychlit vyvoj.

no a prave aby se to snadno zkompilovalo, pripadne dotahalo co je treba, pripadne pak odmazlo, na to je strom portu to prave. Kdyz kompilovat, tak
s komfortem a ne rucni drezinou :))

http://packages.debian.org/unstable/admin/apt-src
http://packages.debian.org/unstable/devel/apt-build

Vyborne. Tyhle utilitky mi v te dobe chybely. Jen mi tak napada, jestli je nekdo, kdo se stara o nejnovejsi baliky a dela pro ne potrebnou podporu. Utilitka je pekna vec, ale pokud do ni nejsou baliky (nemyslim binarky, ale potrebne dsc, tar.gz a diff), tak se da pouzit jen pro optimalizovane instalovani jiz existujicich baliku, takze zadna zmena -- nove verze zase rucne, nebo brat baliky z unstable, jestli jsou hotove (ale tam jsem mel stejne problemy jako predtim, totiz ze vyzadovaly nektere zavislosti, ktere ani nebyly nutne).

Ty potrebne "dsc etc." jsou samozrejme k dispozici stale aktualni, jak asi probiha automaticka kompilace balicku na vsech platformach? :-) A cela idea kompilaci na lokalnich strojich je zcestnym mrhanim vypocetniho casu.

Me by zajimal principialni rozdil mezi Gentoo a Debian. Pokud Gentoo pouziva same nove veci, tak asi nebude moc vychytane, ne? Doma mam na desktopu Woodyho a nemam problemy. Prelozit si mplayer neni problem a nainstalovat Firefox taky ne. Naopak v praci jsem mel problemy s testing verzi a Evolution 1.4, musel jsem si tam pridat Evolution 2 z unstable. Osobne by mi stacil upgrade na novou verzi systemu jednou za dva nebo tri roky.

Co myslíte pod pojmem "vychytané"? Funguje. Jediné problémy, které jsem zatím měl, jsem si způsobil sám tím, že jsem si některé věci - konkrétně třeba gcc 3.4 nebo javu - přehodil z unstable do stable (tohle rozdělení totiž má Gentoo také, ovšem zároveň není problém obě verze mixovat pomocí nastavení v package.keywords. Čili můžu mít ve stabilním systému třeba sunovské JDK 1.5, které jako stabilní zatím označeno není, a aktualizace se mi pro něj budou tahat také). Pokud člověk používá pouze ebuildy, které jsou označeny jako stabilní, obvykle nenarazí. A když už, tak v případě problémů většinou pomůže http://forums.gentoo.org/

Par detailu. Mixovat muzete i v Debianu. A i Debian mel par mesicni odstupy mezi novymi stable vetvemi. Trvalo par let, nez se ty cykly prodlouzily. Dnes uz na problematickou miru. A proto se hleda rozumny kompromis. Az tu bude Gentoo tak dlouho, jako Debian, bude zajimave sledovat, jak na tom bude. Navic, stale tu mluvite o "hrani si". Ale o tom diskutovana oblast neni. Take na svem soukromem notebooku pestuji testing. Ale zakaznikovi ho cpat neminim.

O "hraní si" jsem nemluvil. Třeba to JDK 1.5 mám na ostrém serveru. Na každý pád jsem pouze odpovídal na dotaz položený výše.
Gentoo nikomu necpu, ať si používá kdo chce co chce. ;-)

Mimochodem, když už jste to nakousl: je sice možné, že Gentoo časem po stránce rychlosti vydávání stabilních verzí také "zdebianovatí", ale osobně bych to neviděl jako příliš pravděpodobné. Důvod spatřuji v tom, v čem se obě distribuce liší: zatímco Debian používá verze celé distribuce, Gentoo nic takového nemá. U Debianu se (opravte mě, jestli se mýlím) může stát, že balíky, které by mohly být z fleku uznány za stabilní, musí čekat až bude za stabilní uznána celá distribuce. Gentoo tohle neřeší, prostě pokud je jeden konkrétní ebuild uznán za stabilní, pustí se do světa a na nic dalšího nečeká. Verze celé distribuce neexistují, strom Portage se neustále mění. Z toho důvodu si nemyslím, že by Gentoo bylo náchylné k protahování vývojového cyklu.

A raději znovu upozorňuji - neobracím nikoho na "gentooismus", jenom píšu to, co mě napadlo při čtení vašeho příspěvku. Gentoo má také své mouchy a nikdy bych si netroufl ho někomu doporučovat, i když mně na to, na co ho používám, velmi vyhovuje. Jiným vyhovovat nemusí, ale není důvod se kvůli tomu hádat.

Ano, popsal jste hlavni vyhodu a zaroven nevyhodu Portage. Neni to celek, ale hromada ruznych casti. Proto prave muze mit Gentoo ohromne problemy, kdyz se zmeni klicova komponenta. Problemy s prechodem na ni. Neco, co dosud Gentoo nezazilo, je na tohle stale v plenkach. Co se tyce Debianu, v tomhle smeru existuje vize Debian "rozbit" na vice nezavislych casti a ty vydavat v ruznych cyklech. Problem je, ze Debian je v dnesni dobe natolik komplexni, ze oddelit ty casti od sebe proste jednodusse nejde, balicky jsou mezi sebou silne provazany.

Vim o tom, ze to neni zas takovy problem. Nekolikrat jsem si rucne backportoval baliky jen tim, ze jsem si stahnul dsc, tar.gz a diff primo ze seznamu baliku a pak si to zkompiloval rucne (udelal deb balik a ten pak instaloval).

Casto vsak v tomhle formatu nebyly nejnovejsi verze -- pro novou verzi to chtelo rucni upravy, coz neni prilis user-friendly -- nehlede na to, ze toto neni uplne standardni reseni. Mluvim o tom, ze v Gentoo je tohle bezne a snadno proveditelne (jeden prikaz stahne zdrojaky, pripadne opatchuje, pak zkompiluje a nainstaluje).

Myslim, ze podobny pristup by urychlil vyvoj i v Debianu, proste mit moznost automatizovaneho kompilovani. V Gentoo je ted opacny pristup -- pro nektere vetsi baliky se delaji binarky (tzv. grp soubory), ktere jsou uz zkompilovane s nejakymi parametry (optimalizace pro i586, i686...) -- staci nainstalovat, zadna kompilace navic. Debianu by prospelo zmodernizovat pristup k problemu a inspirovat se napr. u Gentoo/FreeBSD (jestli to uz nekdo nahodou neudelal)

Hmmm, trosku nechapu, o jakych novejsich verzich mluvite? Balicky, ktere jsou nahravany do unstable/experimental v mainu jdou zaroven se zdrojovymi balicky. Ano, nekterym komplexnim vecem trva dele, nez se dostanou do techto oficialnich vetvi, ale to je treba tim, ze Debian zajistuje jejich portaci na mnoho platforem. Nebo je treba zajistit jejich plne funkcni kooperaci s ostatnimi balicky. Tedy to, na co upstream treba kasle. Prikladem byvalo treba xfree86. V Gentoo take potrebujete, aby dana verze byla do stromu zarazena, aby Vam emerge zafungovalo bezvadne.

O tom to je. Pro novou verzi neni problem upravit ebuild (skriptik pro kompilaci, otazka chvilky), zjistit, jestli se to zkompiluje a jestli bezi OK, a pak uvolnit do testovani (jednotlive architektury maji sve testovaci/stabilni verze oznacene zvlast v tom samem ebuildu). Rychlejsi, nez uvolnovat binarky (pro jednu konkretni verzi -- Woody/Sarge). Komunita pak zjistuje, jestli to jede v poradku na vsech konfiguracich, nebo ne. I ebuild muze mit chyby, ty se ladi v teto fazi, nebo se prijde na nejakou zavaznou chybu programu a nasledne se ebuild "zamaskuje" (jakoby unstable), nebo se prida patch. Kdyz je nejakou dobu program bez chyb (hehe), zrusi se testovaci oznaceni a je vedeny jako stable.

Vyhodne je, ze pokud uzivatel chce, neni mu kladen odpor. To je hlavni rozdil oproti Debianu. Muzete si klidne nainstalovat cely system "testing", ale na vlastni riziko. V teto fazi vydatne pomuze forum.gentoo.org a bugs.gentoo.org. Vyhodou je, ze muzete z "testing" brat treba jen konkretni baliky (a na ty se nasledne vztahuji veskere updaty ebuildu, vcetne novejsich testovacich verzi), nebo jen konkretni verze baliku.

Hmmm, zjevne jste nikdy do Debianu poradne nekouknul. Date na par mytu a fam. Vytvoreni skriptu tvorbu pro normalni aplikace, pokud to chcete jen naprasit, je otazka par okamziku. A pokud takove balicky cpete rovnou do produkcniho prostredi, tak to neni zrovna nejlepsi. Stale jsem nevstrebal, co mi Gentoo skutecne prinese lepsiho oproti Debianu. A fakt se snazim. I jeden phanatic do me dost dlouho o nem presvedcoval. Ale zadny skutecny argument nemel. Ve vysledku jen negativa. Tak, jak funguje Gentoo doposavad, jen si koleduje o problemy s kompatibilitou mezi ruznymi aplikacemi ci pri rozsahle zmene API/ABI nejake kriticke komponenty (napriklad libc).

Kdybych nemel s Debianem konkretni zkusenosti, tak se nepoustim do diskuze.

A co ma Gentoo lepsi, nez Debian? Muzete si zvolit, jestli chcete nejnovejsi, mix, nebo pouze stabilni aplikace.

Se zmenami kritickych komponent bych to nevidel tak cerne. Predne se kriticke veci nejdrive testuji (daji se do "masked" -- jako unstable -- i do "testing"), ne jak jsem naznacil. A stale je tu ta moznost, ze si muzete zneprijemnovat zivot i "masked" vecmi -- svobodaaaaaa, freeedom :-) A potom, stejne si muzete danou komponentu sami zamaskovat a vykaslat se na jeji updaty (zamaskovat konkretni verze vyssi nez je nejaka urcita). Zadny problem.

Jinak v soucasne dobe nevidim rozdil mezi Debianem a Gentoo na serverech. V obou pripadech lze vyuzivat pouze security-updatu a na vyssi super extra enhanced verze se vykaslat.

1) Mix muzete mit take (apt to samozrejme podporuje). Argument vyhody rekompilace je stejne u rozsahlych zmen mimo misu (stabilitu). Typicky libc, libstdc atd. Tohle Gentoo dosud nezazilo, je prilis mlade.

2) Zablokovat aktualizace konkretni veci samozrejme Debian umoznuje take

Safra, zase zadny argument ;-) Vidite, zase zadny prinos Gentoo :-)

> 1) Mix muzete mit take (apt to samozrejme podporuje).

hm, tak to jsem nějak nestihnul pochytit jak ... když mám debian stable a stáhnu si balík z testing nebo unstable, jak ho donutím, aby nevyžadoval milión nových knihoven, a pokud to násilím nainstaluju, tak aby to taky fungovalo?

p.s. Oldium bych opravdu nepodezříval, že nemá s debilanem zkušenosti ;-)

Chcete-li napriklad balicek z unstable v testingu (nejobvyklejsi to nasazeni) a mate spravne nakonfigurovane apt, stahne Vam navic vsechny potrebne soucasti, ktere v testingu nejsou, nebo jsou ve starsi verzi. A pamatuje si, ze ty jsou z unstable a tak se k nim pri pristich updatech chova. Samozrejme, ze v dnesni dobe davat veci z testingu do stable casto nejde, protoze zavisi na novem libc (zmeny API), maji jine ABI (C++ programy) atd. Ale treba nemalo cistych php balicku takhle uzivat lze (myslim tim skripty, ne moduly). Pokud chcete, aby nevyzadoval takovy balicek milion novych knihoven, udelate to same, co v Gentoo, prekompilujete ho, v pripade nutnosti backportujete. Rozdil je v tom, ze takovy backport diky starsim knihovnam nemusi proste byt trivialni. Ale to, co vadi treba Vam, nevadi mnoha spravcum serveru.

P.S.: Nektere Oldiovy reakce ukazuji, ze proste o Debianu zatratil mnoho informaci...

nějak se mi z toho ovšem vytratila ta jednoduchost ... co se týče konkrétního postupu, musel bych si to vyzkoušet, ale Váš příspěvek mě optimismem nenaplňuje ("v případě nutnosti backportujete" - "backport nemusí být triviální" - a jaké to jsou případy?)

tak ten ja vidim. mel jsem ho na dvou, ne z me vule a stejne tam pak musel po pul roce provozu jit debian. protoze gentoo je na server nevhodne. pokud to neni "sever" ale server

Chtěl jsem původně hájit své oblíbené G.. Tato věta pak pokračovala na půl stránky, nakonec jsem ale všechno smazal - jediné, k čemu jsem došel je: Ať si každý používá, co mu vyhovuje :-)

Rok stara? Hmmm. Woody byl ve stavu frozen pul roku. Sarge zastaralosti moc neoplyva a v dobe vydani ani moc oplyvat asi nebude. A argumentace MPlayerem je zcestna (je udrzovan z licencnich duvodu mimo oficialni strom). A uz zase ujizdime na desktop koncoveho uzivatele. Ale o tom clanky nebyly. Koncovy uzivatel at si uziva testing, je-li znaly (a zakaze vsechny porty z venku napriklad). Nebo, lepe, at uziva Ubuntu, ktere je presne pro nej. Ale server a kancelarsky pocitac menit co pul roku je nesmysl.

Nevim, jaky je aktualni stav s MPlayerem, jen vim, ze s nim jsem mival problemy. Klidne na nej zapomente a berte priklad KDE.

Mate ale pravdu, protoze tohle je otazka spis pro Desktop, nez pro Server. Na serveru bych ale chtel videt silence, co se pusti do nejakeho vetsiho updatu, napr. PHP/Postgres (myslim hlavni verzi X.m.n na X+1), pokud nema hodne kafe a volny tyden na upravu softwaru :-)

Server se vetsinou zakonzervuje a vetsinou se provadi jen nutne security updaty (a tohle Gentoo umi take, stejne jako Debian).

Na desktopu pouzivam unstable uz dlouho a bez vetsich problemu. Obcas se neco malo resit musi, jinak by se to nejmenovalo unstable :-) ale vyjimecne. Kdyz chci nove Gnome, za tu chvilku pripadneho rozcilovani mi to rozhodne stoji :-)

Dobry den,
jenom se chci zeptat, jake problemy mel autor s testing verzi (resp. jeji casti). Beham vsude testing, na zadne velke problemy jsem nenarazil, rad bych vedel, s cim muzu pocitat.
Diky, zdravim
PD

Typickym problemem testingu je, ze obcas z nej musi byt nasilne odstraneny nektere komplexni balicky, ktere v nem v prubehu vyvoje natvrdo zatuhnou. V ramci testovani se klade duraz na moznost automatickeho upgrade ze stable na budouci stable a ne tolik na propadavani balicku z unstable do testing. A pak samozrejme hlavnim je to, ze nekdy balickum z unstable do testingu to dlouho trva (obcas i rok). Takze tam muzou zustavat velmi neprijemne problemy.

Zajimalo by me jestli ma nekdo zkusenosti s Ubuntu linuxem (http://www.ubuntulinux.org/) a jake? Jde o distribuci zalozenou na Debianu a rekl bych velmi vhodnou minimalne pro desktop. Ma vychazet jednou za pul roku stabilizaci podmnoziny unstablu. Podpora pro kazou verzi minimalne rok a pul. Verze pro x86, AMD64 a powerPC.

Mne zatial funguje slusne. Ale zase ja som taka polovicna lama :-) Kazdopadne z tych viac user-friendly distier, co som skusal (Mandrake, Fedora) mi zatial pripada najlepsia.

Ruzne. Kolega HW admin si Ubuntu pochvaloval. Nainstalil jsem si ho. Instalace prijemna. HW veskery nalezen, co se nenakonfigurilo samo, bylo jednoduche nakonfigurit. GNOME (vlajkove GUI Ubuntu) se mi na prvni pohled moc libil. Na druhy pohled pri pouzivani byl schopny vytvaret sileny zmatek(prirazovani specialnich eventu klavesam primo v keymap takovym zpusobem, ze nebyl schopen premapovat zpatky jinak nez rucne, napr.). V balikach na distserveru chybelo mc. Pripadne mi, ze ma jeste dost co dohanet - nabizi malo veci v GUI a tam kde GUI nestaci, tam neposkytuje konzolove zprijemnovaci programy. Chybi dobra burnici aplikace (gtoaster pro GNOME nebo k3b). Vratil jsem se zpatky na fluxboxe a debiana. S debianem mam moznost lip si vybrat a nejsem tak omezeny. Zkusil jsem dat Ubuntu/GNOME i newbiekovi (slecne) a ta po mesici presla na fluxboxe taky - lip a rychleji se ji pracovalo a ucilo :)

No ja som tiez presiel, ale na XFCE4 a rozmyslam nad
Fluxboxom... ale to nic nehovori o Ubuntu ako celku, skor o GNOME, ktore sa da trivialne zmenit za nieco ine.

ale vypovídá ... jestliže si někdo vybere Gnome za "vlajkovou loď" ...

"Správa serveru není odpočinková záležitost (i když, jak se to vezme), je třeba se jí pravidelně věnovat, protože skutečně bezchybných aplikací je poskrovnu (ani DJB není neomylný)."

---

Ano, plne chapu, ze to neni odpocinkova zalezitost, zvlast kdyz si clovek programove komplikuje zivot pouzivanim nevhodne distribuce. Nevim jak ostatnim, ale me tohle sachovani s backporty proste prijde naprosto zcestne.

Tvrzeni, ze nove verze prinaseji nove chyby, neni zadnym argumentem, protoze pri backportovani oprav se tam ty chyby mohou zanest take, o znasilnovani novejsich verzi tak, aby fungovaly v beznadejne zastaralem systemu, uz radeji ani nemluve. Autor si vazne mysli, ze pri tomto procesu nove chyby nevznikaji? Opravdu ten "skvely pocit" nechapu - me to skutecne prijde jako poskakovani kolem posvatneho totemu (viz jiny prispevek o neco vyse), rozhodne ne jako rozumna sprava serveru.

Jednu vec Vam uprit nemuzu. Vase prispevky me vzdy rozesmeji :-) Nevim, jak rozsahle jsou vase znalosti spravy kritickych systemu. A znovu. Backporty tam ty chyby muzou zanest take, ano. Ale neboli me, nez nove libc ma security chybu. Nebo nove 2.4 jadra, kdyz se zrovna nektere security chyby objevily az v kodu, ktery prisel po 2.4.18 (Debian woody jadro). Nebo perl. Stale nechapete, ze cilem je minimalizovat moznosti vzniku chyb. Take je zajimave, ze pod mou spravu prichazeji stale nove a nove stroje, ale zadne neodchazeji. A zakaznici jsou spokojeni. Ne pocity, ale realny svet ukaze, co je lepsi.

jo Jakub Moc .. skoro lepsi nez Werich :)

Eh, jiste - zakaznici jsou spokojeni, protoze oni se v tom nemuseji vrtat. Ja se ale nevyjadruju z pohledu zakaznika, ja se tady snazim sdelit, ze mi ta distribuce nevyhovuje, protoze jaksi neodpovida mym potrebam.

Ja napr. na serveru potrebuju funkcni, aktualni antivirus a antispam. To mi jaksi ta v clanku opevovana stable verze Debianu nenabidne. Na desktopu pro zmenu potrebuju funkcni webovy prohlizec, nikoliv dva roky starou Mozillu 1.0.1 se spoustou der. Nemyslim, ze mam az tak vyjimecne pozadavky. A "resenim" jsou podle vas nejake third-party backporty? Nechapu...

Ty takzvane "third-party" backporty napriklad v podobe bpo predstavuji casto backporty provadene primo maintainery, nebo jsou jimi podporovane. Jedine, co dosud neexistuje, je zahrnuti nekterych vhodnych forem backportu mexi oficialni Debiani projekty. O moznych resenich z hlediska projektu Debian je neco v clanku take napsano.

K tematu desktop se vyjadrovat v teto diskuzi nebudu (clanek o nem neni).

A ano, resenim je mit stabilni zaklad a do nej backportovat pouze nutne aktualni veci. Takhle to uz chodi desitky let nejen v Linuxu. Vsechny snahy to delat jinak se v dlouhodobejsim meritku ukazuji jako extremne destabilizacni a totalne vycerpavajici silu tvurcu.

Jinak, ja mam samozrejme vsude, kde je treba, "funkcni, aktualni antivirus a antispam".

P.S.: Ja Vam netlacim Debian, fakt si uzivejte, co chcete. Ja tu prezentuji a oargumentovavam, proc je uziti testingu (a nedej boze unstable) na produkcnim SERVERu nezodpovedne. Vy snad ve sve distribuci take nasazujete jeji alpha nebo beta verzi?

P.P.S: Fascinuje me, jak si vsichni oponenti predstavuji, ze se cele dny venuji ohybani backportu. To bych pak asi treba nemohl tolik sledovat tuhle diskuzi a prubezne reagovat na prispevky. To, ze jsem napsal, ze sprava serveru neni odpocinkovou zalezitosti, nebylo mysleno tak, ze je treba tomu venovat stovky hodin mesicne, ale tak, ze je treba pri sprave se trosku obcas zamyslet.

Pri backportovani oprav se samozrejme backportuje _pouze_ oprava, takze chyby v novejsich verzich software se do stable nedostanou. Samozrejme muze vzniknout chyba zpusobena spatnym backportovanim opravy. To je ale take duvod, proc clenem debian security teamu nemuze byt kdokoli...
Jak casto upgradujete OS na serveru vy? Serverovy OS stary nekolik let mi prijde uplne bezny. Vase argumenty o backportovani novych verzi softwaru na stary OS take moc nechapu. Vzdyt je to v praxi uplne bezne. V debianu mate tu vyhodu, ze relativne dobre otestovany oficialni balicek pochazejici primo z debianu (vetsinou testing) vam nekdo prekompiluje pro stable, otestuje, vyresi pripadne nove zavislosti atd. Kdyz se vam to nelibi, muzete si balicky pro stable "backportovat" sam. Vetsinou to obnasi pouze prekompilovani nekolika zdrojovych balicku (odkazy na apt-src a apt-build jsou uvedeny na jinem mite tehle diskuze). Jak myslite ze stejny problem resi napriklad uzivatele pouzivajici na svych produkcnich serverech (pro vas) prehistoricke verze FreeBSD? Proste si sami zkompiluji novejsi verzi pozadovaneho software z ports. Tady vam nevadi "...znasilnovani novejsich verzi tak, aby fungovaly v beznadejne zastaralem systemu..." ?

Jak casto upgraduju server? Nikdy. Diky Gentoo to neni treba. ;-)

Opet prijemne rozesmani :-) Jasne, vy tomu rikate prubezny update. Jenze to, co vy provadite nekolikrat za mesic, ostatni provadi jednou za dva roky. Potrebnym schopnostem to neuskodi (ta delsi perioda) a ztrati se tim radove mene casu. Zkuste se priste zamyslet nad tim, co tu zase placnete.

Debian je na mé nároky a vkus příliš nepružná distribuce a v některých směrech značně těžkopádná. Ještě že ho nemusím používat :o)

Stara, lety proverena skola. Zajimave, ze k ni casem vzdy zamiri vsichni, ktere zajima profi ci enterprise nasazeni. Byt cerstvy kazdy den je krasna idea, ale v praxi brutalne problematicka v dlouhodobem horizontu. Ale na kazdy pad, Debianu konkurence prospiva. Je skvele, ze existuje a mnoho lidi ji uziva. Trosku nechapu, proc tu prudi lide, ktere Debian nezajima. Maji tolik volneho casu? :-)

Nejspíše mají opravdu hodně volného času, protože jim rozumná (tj. neovlivněná náboženstvím) volba distribuce šetří čas. Když máte požadavky, musíte si je včas rozebrat a zvážit a ne pak mrhat svojí prací a nervama na látání nadrobených problemů.

Brrrm, brrrrrrrrrrrrrrrrrrrrrm, brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrm.

Nemam k tomu co rici? Ale mam. Chci k tomu neco rici? Nechci. Nema to cenu. Ti, co ctou linux.cz, mozna si vzpomenou na lity flameware mezi mnou a panem Kerslagerem ne tak moc davno probehly. Je zajimave, ze pan Kerslager se ucastni vsech podobnych flameware, stale s tim samym "nabozenstvim". Ne, nema cenu reagovat na prispevek, ktery neprinesel zadny argument, neosvetlil v nicem situaci a jen opet dokazuje, jak vysoce schopny clovek dokaze byt tak strasne zahleden do sebe a svych vizi sveta, ze ho ostatni radeji ignoruji. A timto prispevkem jen chci dat na vedomi, ze nemam uz zajem o zadne monology s panem Kerslagerem.

> Chci k tomu neco rici? Nechci.

tak mlčte a nezostouzejte dvakrát tak dlouhým příspěvkem

možná považujete svoje flamewars na jiných serverech za důležité, nicméně pro mě (a myslí, že i pro ostatní čtenáře?) je důležité, že p. Keršláger má pravdu - to, že jeho "náboženstvím" byl (je?) RedHat je věc zcela jiná ...

Ale ja k nekterym trapnym prispevkum mlcim. Ale k vrcholne trapnemu jsem proste musel neco rici. Jste naivni, kdyz si myslite, ze vetsinu meho dne zabira opecovavani "mych" krabicek. To by napriklad muj skolitel nemusel uz davno byt mym skolitelem. Take bych si nemohl dovolit na mnoho mesicu opustit republiku. Takze, muj nazor je, ze pan Kerslager nema pravdu, neni schopen predlozit zadny argument (mnohokrate dokazano v poslednich mesicich), ma klapky na ocich atd.

> Jste naivni, kdyz si myslite, ze vetsinu meho
> dne zabira opecovavani "mych" krabicek.

ale já si nic takového nemyslím :-)

můj názor se shoduje s tím, co mi vyplynulo z onoho příspěvku, tedy že volba distribuce by měla být určena právě těmi požadavky a nikoliv "náboženstvím"

věřím, že své debianí servery znáte do posledního bajtíku a spravujete je efektivně - což ovšem neznamená, že Debian, nebo dokonce konkrétně tento stable-only přístup k němu, musí vyhovovat každému, i když má požadavky jiné ...

diskutovaný příspěvek je hodně obecný a imho jej není třeba zde odargumentovávat - že každý potřebuje něco jiného ukazuje na mnoha místech tato diskuse sama o sobě ... spojovat to s nějakými "klapkami na očích" z jiných diskusí mi přijde unfair vůči předloženému stanovisku, i když by si to třeba jeho autor zasloužil jako Bush souzení v Haagu

Ja jsem nekolik let - cely svuj admin. zivot :)) - pouzival stary dobry RH. Potom ovsem skoncil a Fedora me moc neoslovila. Chvilku jsem zkousel MDK, ale :((, nyni pouzivam SuSE (celkem spokojenost) na desktopu a na serverech Debiana a musim rici, ze jsem s nim zatim velmi spokojen a planuji na neho prejit kompletne i na desktopu. Ale jinak je dobre, ze existuje mnoho jinych distribuci. Neni treba se hadat o to kdo je lepsi, kdyz pouziva tu a tu distribuci - kazdemu vyhovuje neco jineho. A hlavne - sila je ruznorodosti a ne v monokulture :))

Ma zkusenost je stejna. Dokud se starate o 2 servery, dejte si tam RH. Pribude 3, to uz mate novou minor verzi RH, na ctvrtem novou major verzi a u pateho serveru koncite. To s Debianem neznate. Spravuji (jsme na to dva) okolo 30-40 serveru (nepamatuji si, ze by se kdy ktery preinstalovaval), jsou mezi nimi i kriticke servery a jde to. A pujde to i se 100 servery. Protoze casem se clovek se zavislostmi balicku nejak dokaze poprat, kriticke/nestadardni veci dela na testovacim stroji a prestoze mi vadi, ze ze stav stable neni idealni, jsem si vedom toho, ze proste ani byt nemuze, je totiz kompromisem mezi bezpecnosti a modernosti. A kdyz uz jinak nejde, stale je tu testing, stale je tu chroot a jine ficury linuxu). Backporty prilis za reseni nepovazuji, ale prosti gustu zadny disputat.

Mam pres 20 serveru, puvodne s RH, ted se SuSE. To neni o dostribuci ale o stylu prace.

Ja jsem opustil RedHat nekdy okolo 5.1, tehdy provest upgrade na stroji na 5.2 bylo spachat harakiri v primem prenosu. Nicmene verim, ze SuSE i RH dnes jsou v tomto opatrnejsi, ale jedna se pp o EP verze, Debian si na nic nehraje a lze se na nej spolehnout leta letouci. Tudiz o distribuci to je, ne ze ne. Vy jste RH taky zrejme neopustil bezduvodne. A taky pripustte, ze z Debianu si vzali vsichni priklad. EP verze je takovy stable v malem, a jejich package managementy resi konecne zavislosti.

Zlata slova upgrade z RH7.x na RH8.x me definitivne znechutil. Nikdy se mi to nepovedlo.Zkousel jsem ledacos a skoncil u Debiana a u nej i zustanu.Je to pro me jistota :-)

RH jsem opustil, protoze jsem se nedockal po verzi 7.2 nejake dalsi, kterou bych si dovolil nazvat stabilni (to byly jen 5.2, 6.2 a 7.2).

Osobne jsem v EP nasel vice chyb nez obycejnych verzich, ale holt certifikat je certifikat, takze jich 5 mam :(

Nevim, jestli si vsichni brali priklad z debianu, to nedokazu posoudit, ale v dobe, kdy jsem ho zkousel a rozhodoval se, kterym smerem se vybrat mi chybela obdoba zdrojovych baliku z RPM distribuci, kde by byl popsany cely proces vytvareni baliku.

Prijde mi, ze komercni distribuce jsou vice vhodne pro nasazeni v prostredi, kde si server casto spravci predavaji a kde jsou placeni od ukonu. Jsou vice "odosobnene". Systemy typu *BSD, debian, gentoo kladou vetsi naroky na udrzovani dokumentace k serveru. Taky to tak vidite nebo se pletu?

Prebiral jsem posledni roky nekolik RH serveru po ruznych spravcich (coz ale nedokazuje, ze to nelze delat jinak) a ve vsech tech pripadech na tech strojich byl nehorazny chlivek.

Nevim, co myslite tim "mi chybela obdoba zdrojovych baliku z RPM distribuci, kde by byl popsany cely proces vytvareni baliku.", kompletni buildovaci proces je soucasti kazdeho balicku. U komplexnich veci, jako jsou Xka, jsou zvlast jednotlive aplikovane patche (podobne jako je to u src.rpm).

Veskera "dokumentace" pro slusne spravovany Debian je v /etc, pripadne nektere debconf veci ve /var (tak jako u vsech ostatnich, takze je lepsi ji vest nekde jinde v aspon castecne kecaci podobe), vcetne toho, odkud se berou balicky (/etc/apt/sources.list). To, v jakem stavu je dany Debiani server zjistite behem chvilky. Ale to plati o naproste vetsine "balickovych" distribuci. Tohle je opravdu spise o stylu prace nez vlastni distribuci.

A jeste jedna vec, Debian neucil enterprise verze, ty tu jsou se svymi dlouhymi cykly dlouho, navic ani ony s nimi neprisly samy, ale ucily se je ze sveta komercniho SW. Protoze neco, co se vam denodenne meni pod rukama, nemuzete realne produkcne supportovat.

S tim enterprise nasazenim je problem. Dneska nikdo
nezacne pracovat na projektu, kterej by bylo mozny
provozovat na Woodym. Vsechny databaze, prog. jazyky
jsou uz dneska dal a tezko dneska nekoho presvedcite,
ze ma neco vyvijet pro tri roky starou verzi postgresu. Kdyz by mu nova verze usetrila spoustu prace a vysledny produkt by se jeste zjednodusil.

Taky je problem v tom, co oznacime za "stable" a kdo to udela. Ma to byt tym programatoru, ktery dany produkt vyviji nebo spravce baliku? Debian na serverech pouzivam uz hodne dlouho a cim dal tim verim vice autorum sw. nez spravcum baliku.

Uz se mi nekolikrat stalo, ze neco nefungovalo
(treba ltrace na aplikace v c++) a zjistil jsem ze v jinych distribucich je to uz davno opraveny, ale spravce baliku tvrdosijne odmita opravu aplikovat.
Spravci baliku maji nekdy az moc velkou moc a neni sila, ktera by dokazala s nima pohnout(viz treba knihovna QT). To se mi libi na vyvojovym cyklu u FreeBSD, ze se tam hlasuje a rozhoduje vetsina.
U Debianu se spravce baliku rozhodne, ze ho zkompiluje s nejakejma silenejma optionama a nikdo s tim nic neudela.

Vyvoj je na neprodukcnim serveru, nebo snad ne? Nez dokoncite vyvoj, je stav uplne jiny. A zase, snaha minimalizovat naroky prinasi sve ovoce, casto vycistuje vysledny kod.

Stable balicek je takovy, ktery nema hlasenu kritickou chybu.

Autori SW casto vidi jen to sve "detatko" a obcas je jim uplne putna, co je okolo. Spravci balicku musi zajistit, ze ten SW se bude chovat slusne k ostatnim. To neni trivialni zalezitost mnohdy.

Kdyz se spravce balicku zaspuntuje, muzete to zkusit diskutovat verejne, treba v debian-devel, vetsinou vysledna diskuze prekvapi.

A kdyz selze tato moznost, nic Vam nebrani spravovat separatni verzi.

Jiste, ve FBSD je princip debat siroce podporovan. Pravda zase je, ze spravce balicku je ten, kdo za dany balicek zodpovida. Proc mu berete pravo o svem dile rozhodovat? Proste, diskutujte (vim, QT je zrovna docela komplikovana vec) a nebo vytvorte alternativni, userove rozhodnou, kdo je pro ne zajimavejsi.

Muze byt system ktery se kazdou chvili meni stable? Asi tezko. Stabilni je prave tim, ze se nemeni a diky tomu se na nich da neco vybudovat. Tak jako jsou stabilni Windows, ktere vychazeji asi tak kazde 3roky a diky tomu na nich mohou dalsi firmy stavet software. Woody r4 je jako ctvrty service pack do Wxp. Security.debian.org je jako Windowsupdate. Pravda vsak, ze service packy od MS zavadeji i nove veci, ale take si kazdy vzpomene na problemy, ktere to prinasi.

doufejme že nový Debian dorazí dřív než Longhorn

:-) Doufejme. On je Sarge skoro ready (proto ho take mnoho uzivatelu uziva). Resi se vlastne pouze jedna, bohuzel podstatna, vec. Novy system buildovani bezpecnostnich updatu. Predpokladam, ze tak daleko v MS jeste nejsou :-)

Neni. Zbyva pres 200 kritickych chyb a nakonec se tam bude prece jenom davat KDE 3.3. O co ze i v cervnu uslysime ze Sarge je "skoro" hotova.

Kdo rika, ze tam budou vsechny balicky? Asi neznate release politiku Debianu pro Sarge. Ve chvili, kdy se rekne "jde se na vec", bude mit vetsina spravcu cca mesic, jinak vypadnou pryc ze Sarge.

Co se tyce migrace KDE 3.3, stejne tak se tvrdilo, ze Gnome 2.8 bude zdrzovat. Nestalo se tak. Tyhle velke baliky musi nyni vzdy predstavit kvalitni plan migrace a byt kvalitne overene pred uploadem. KDE 3.3 tam pravdepodobne opet namigruje behem cca 3 tydnu. Ono se totiz balickuje pro Debian uz docela dlouho.

Nebyt toho, ze Sarge ma byt zlomovou verzi (novy instalator a novy security build), byl by tu mezi nami uz delsi cas.

O ten cas se s vami nevsadim, protoze to nemohu realne ovlivnit. Asi uz jste slysel, ze Sarge bude, az bude pripraven. Vsechny datumy, ktere kdekdo predstavil, se ukazaly nesmyslnymi. Ale Longhorn letos neocekavam. V Sarge doufam :-)

Zdravim vsechny a omlouvam se za OT: nechce se mi stravit cely den surfovanim po netu, abych si vybral distibuci linuxu, ktera by vyhovovala mym pozadavkum:

Nasazuji to na routery, takze: platforma i386, pokud mozno vsechno ve zdroj. podobe, aby se to dalo v klidu zkompilovat, bezproblemova sprava balicku (i src, nejlepe vanilla jadro, nejlepe stabilni 2.4.2xx) neco jako urpmi, instalace celeho systemu i baliku ze site, idealne tak do 300MB velikost na disku a aby se to dalo nainstalovat i na pentium 200 s 16MB RAM ;-), ale vse samozrejme udrzovane a "moderni".

Proste quick & dirty linux na hrani s minimem demonu (sshd, cron), spise na ladeni ruznych driveru, QoS atd. Zadne X ani podobne zbytecnosti ;-), proste masina, co vydrzi 2roky bez udrzby prehazovat pakety.

Zkousel jsem postupne behem par let redhat, suse a ted jsem na madrake, ktery se mi zda zatim nejlepsi, ale i to ma spoustu chyb (napriklad bin. jadro distibuce neni totez co jadro, ktere si prelozite ze "src rpm" :-\ )

Takze poradte, nejlip e-mailem, co je lepsiho pro moje potreby nez ten mandrake.

Diky.

Presne na tohle ja pouzivam debian stable. Pokud ho pouzivas na WWW server a nekdo porad drzkuje ze tam neni posledni PHP nebo ze proste nove funkce se ti hodi, tak to chapu. Ale pokud vylozene hazis pakety ze sitovky do sitovky tak nepotrebujes na nic vlastni verzi a bohate si vystacis se starymi verzemi. Pokud vim tak routovat umi vsechno. Jedine co potrebujes je pripadne jine jadro a iproute atd kvuli shapovani nebo novejsi iptables. Ale fakt nevim proc to chces delat ze zdrojaku. Ja mam router na P100/32 RAM s par sluzbami jako ftp, thttp, sshd apod, vetsina co sla v inet demonu. Fakt by me zajimalo proc si to chces na tohle kompilovat sam, kdyz tam skoro zadne funkce nepotrebujes.

300MB disk, 200MHz procesor ... to mi nepripada jako konfigurace pouzitelna na preklad ze zdrojaku ...

Jak to takhle čtu, došel jsem k závěru, ZLATÝ WINDOWSy. Stahovat desítky vopravnejch balíčků tejdně, denně updatovat, HNUS. To bych jako spravce sítě nedělal nic jinýho než se hrabal v Linuxáckým serveru. WINDOWS nebo NOVEL jsou systemy na servery, jede to a máte klid.
A ted se z toho poserte LINUXACI.

pochop ze windows v sebe obsahuje kernel a len par aplikacii, linux distribucia obsahuje kernel+tisice aplikacii

Smichy?

Tak to je slovo do pranice ;) Kdyz ma nekdo ve winech nastaveny automaticky update a ani netusi co se mu kazdy tyden stahne a nainstaluje, zije spokojene a ma i dost casu na to mlatit zenu a svych 5 deti ;)

a případně i TEBE ;-)

Ve winNT automatickej update neni a presto to na solidnim HW jede naprosto spolehlive i bez denniho stahovani balicku a vrtani se v tom. cim vic se do severu stoura tim je v tom vetsi bordel. a navic nezbejva cas na ostatni praci, spravce site neni jen ten hrbac s popelnikama na vocich co hypnotizuje monitor serveru.
ZKRATKA SEM SI MYSLEL, ZE LINUX JE VYMAKANEJSI. ZE SE NAISTALUJE A JEDE. Spravnej server ma zaprasenej monitor i klavesnici.

Ano, server by mel mit zaprasenej monitor a klavesnici... v pripade, ze jsou na nem widle a tudiz lezi ladem a zaprasi se ;) U linuxovyho serveru se to nestane - narozdil od win serveru zadnej monitor ani klavesnici nepotrebuje :) A co se tyce toho, ze se neco "samo" nainstaluje, tak to je podle me dost kontroverzni: je lepsi, aby si to udelalo samo podle sebe, aniz by spravce vlastne vedel, co to obsahuje (windows), nebo je lepsi si dat nejakou tu praci s instalaci a konfiguraci a vedet naprosto presne, co tam je a jak to bude fungovat?

Moj drahy synu,
pisem Ti pomaly, lebo viem, ze nevies rychlo citat. Uz nebyvame tam kde sme
byvali. Tvoj otec niekde cital, ze najviac dopravnych nehod sa stava v
20-kilometrovom okruhu od bydliska, preto sme sa ihned prestahovali. Neviem
ti napisat nove cislo domu, lebo predosli obyvatelia ho odmontovali a
zobrali so sebou, aby si nemuseli menit adresu.
V novom dome je vsetko velmi pekne. Aj pracku mame, i ked nejako nefunguje.
Vlozila som do nej bielizen, potiahla retiazku a odvtedy som ju nevidela.
Ale nie je to az take zle. Minuly tyzden prsalo iba dvakrat. Raz tri dni a
raz styri dni.
Poslala som Ti kabat, ktory si chcel, ale podla Tvojho otca by bol balik
kvoli gombikom prilis tazky, tak som ich odrezala. Najdes ich v lavom
vrecku.
Tvoja sestra dnes rano porodila, ale este nevieme co to je. Takze Ti zatial
neviem povedat, ci si stryko, alebo teta.
Tvoj brat si niektory den pribuchol kluce do auta, dost sme sa obavali, lebo
trvalo to vyse dvoch hodin, kym ma s otcom vyslobodili z auta.
Nas novy sused minuly tyzden padol do suda s domacou hruskovicou. Skusali ho
vytiahnut, ale hrdinsky ich premohol a utopil sa. Potom tri dni horel v
krematoriu.
Ale inac sa nic zvlastne nedeje, vsetko je v starych kolajach.

Tvoja milujuca matka.

PS: Chcela som ti vlozit do obalky nejake peniaze, ale bola uz zalepena.

Nevim, jak autor, ale na desktopu mam uz hodne dlouho Woodyho a po kazdem updatu z backports.org musim resit nesplnene zavislosti, nefunkcni (rozumnej nespustitelne) aplikace a pod. - na server s backports.org tedy ani nahodou. Sarge mi slape na serverech pekne a veci, ktere pozaduji uzivatele (rozumnej chlebodarci) tam narozdil od Woodyho jsou a jsou funkcni.