Vlákno názorů k článku
Jaká je základní směrnice Fedory?
od Milan Keršláger - Fedora je samostatná a Petr by neměl tupě...
-
Fedora je samostatná a Petr by neměl tupě přepisovat zprávy z http://OsNews.com. Nebo by si alespoň mohl pamatovat, co se psalo před 14 dny: http://osnews.com/story.php?news_id=15242
RHEL je forkem Fedory. Na tom není nic špatného. Nebo by měl být podle vás RHEL forkem třeba Debianu? Red Hat platí hlavní vývojáře Fedory, takže je pochopitelné, že se budou soustředit na takové věci, které mají rozumnou perspektivu. Kdo to ještě nechápe: Jsou to 2 samostatné projekty, každý ma JINÉ cíle, jiný styl vývoje, jinou dobu podpory, jiné QA atd. -
Milan Keršláger (neregistrovaný)Zrovna to bych moc nevyzdvihoval, při přechodu na GCC 3.x byli prakticky všichni kromě RH proti a kdyby RH intenzivně nezatlačil, neměli bychom GCC 3.0 ještě dnes. Všichni šli až do GCC 3.2, což je fajn. GCC 3.1 měla být ta "pravá non-RH" verze, ale nakonec ji nepoužil v distribuci nikdo.
-
To těžko. Podívejte se, jak lidé kolem Debianu nadávají na Ubuntu (hlavně ti, kteří nejsou u Ubuntu zaměstnáni). A to přesto, že by Debian dnes již bez vývojářů Ubuntu jen těžce přežíval. Pomalý vývoj by byl ještě pomalejší (některé části vyvíjí jen Ubuntu - např. IIRC GNOME) a tak dopředu by byl ještě slabší.
-
martink (neregistrovaný)Nechápu. Debian má víc vývojářů než kdy dřív a jejich počet neustále roste, ale najednou by se neobešel bez vývojářů Ubuntu... IMHO trochu nelogické.
A na ten pomalý vývoj jste přišel jak? Protože stable vychází jen jednou za pár let? A vývoj u RH se vám v tom případě zdá také pomalý? -
Milan Keršláger (neregistrovaný)Ale pánové... Debian má v implicitní stable instalaci jádro 2.4 a další obsatarožní nástroje. Debian má prostě na všechno dost času. A to není zrovna přístup, který je výhodný pro uživatele. Tedy kromě těch, kteří se jednou něco naučí a pak si myslí, že mají do důchodu vystaráno.
Ubuntu je na rozdíl od Debianu aktuální. Lepší, rychlejší aktualizace (viz nedávná zprávička), grantuje dlouhodobou podporu. A tím je prostě lepší. I přes docela nevybíravé políčky od "komunity" (viz opět nedávné zprávičky, LWN.net, OSNews.com atd.). Některé části Ubuntu vyvíjí pro Debian, jiné opačně. Nechápu, proč by měl za Debian dělat všechno nebo držet binární kompatibilitu kvůli prehistorickému GCC a podobně (alespoň se toho zde dožadují jak diskutující, tak někteří oficiální Debianí předáci).
Nechápu averzi vůči GNOME. Jednoduché, GPL a jediný skutečný konkurent KDE, který zajišťuje zdravé soupeření. -
Petr Baláš (neregistrovaný)Debian má jako implicitní jádro 2.4 protože na některých z 10 podporovaných architektur prostě jádro 2.6 nefunguje bez problémů. Zvolit při instalaci jádro 2.6 je triviální a zvládne to cvičená opice.
Debian prostě nepustí do stabilní distribuce balíček, který nefunguje na všech podporovaných platformách. V praxi jsem ale na serveru na problém že by mi vadil starý balíček a neřešil to archiv volatile (např. pro antivir) nenarazil. Popř. existují backports.
Ubuntu víceméně není nic jiného, než velice malý subset Debianu unstable který byl zmražen a vychytány bugy. U subsetu a na omezeném množství architektur to logicky jde rychleji než u Debianu.
Požadavku na udržení binární kompatibility jsem si nevšiml (ale asi bude pocházet od někoho, kdo chce používat balíčky z Debianu v Ubuntu), prehistorické gcc se dlouho drželo prostě proto, že na některých architekturách podporovaných Debianem prostě nové gcc nefungovalo korektně. Vztahy mezi Debianem a Ubuntu jsou mnohdy napjaté - někteří lidé v Debianu si myslí, že jim Ubuntu ukradlo jejich show, někdy se správce téhož balíčku v Debianu a Ubuntu neshodnou, někdy je správce balíčku tentýž človék a pracuje pro Ubuntu a na Debianí balíček kašle, ...
Dlouhodobá podpora je prima věc (kterou je mnohem lépe schopna garantovat firma než komunita) ale nechápu jak se toto týká rychlosti vývoje.
BTW asi největší přínos Debianu pro komunitu vidím v otestování programů na mnoha exotických platformách.
BTW2 co se týká rychlosti vývoje tak doporučuji sledovat unstable. Např. nové KDE se jako balíčky objevuje velice rychle (Gnome nenmohu posoudit, to nesleduji). -
David Hrbáč (neregistrovaný)Já bych ještě přidal to, že oba projekty mají své místo. Navzájem se doplňují. Fedoru v produkčním prostředí bych si netroufnul nasadit, primárně z důvodu doby podpory. Na druhou stranu, vývojáři Fedory udělali za poslední dobu takový kus práce a posunuli RH Linux velice daleko. Mám na mysli především to, jakým způsobem se pustili do QA a celého managementu balíčků, výsledky jsou vynikající. V tomto RH prakticky zaspalo a uslo na vavřínech, mnoho balíčků je nekompletních, mají nemsylslné závislosti, a pod. Jakmile to bude dotaženo u Fedory, je předpoklad, že se to promítne u RHEL. To potom bude paráda, až bude možné rebuildovat balíčky v Mocku http://fedoraproject.org/wiki/Projects/Mock Doufejme, že to nezůstane jen pro Extras.
-
Izak (neregistrovaný)No ja sice nasazuji CentOS4.3, ale dokud nebyl, naszoval jsem nejdirev RH 9 a kdyz uz byl opravdu off-topic tak jsem i ne velmi dulezite servery nasazoval FC3 a bez problemu.
Na Oracle samozrejme placene RHEL, a to ne kvuli kavlite, ale nemoznosti niceho jineho a zaroven mizerneho a predrazeneho supportu Oracle -
David Hrbáč (neregistrovaný)Ale jistě, takovýto vývoj mělo mnoho uživatelů RH. RHEL4 není nic jiného než FC3 s různými malými/velkými změnami. Oracle na Fedoře běží výborně, o to však nejde. Jde o updaty a tam se doba u RHEL/klonů počítá na roky, u Fedory na měsíce a přechod z jedné verze na druhou není bezbolestný. Jo, to až jednou přes yum (podotýkám jednoduše, ne změnou konfiguráků) půjde transparentě provést updgrade distribuce, jako je tomu u apt, to bude jiné kafe. Proto jsem napsal, že Fedora nepatří do produkčních systémů (přesto i já jich pár mám :o)).
-
David Hrbáč (neregistrovaný)Nutná bych řekl, že je špatné slovo. Mock je skvělý, alespoň tak co cítím já, v případě jeho plného nasazení, či jiného podobného systému. Binární RMPka se elegantně vytvoří ze zdrojových. Interně to používá YUM, takže se natáhnou balíčky dle závislostí. T.z. konečně to přivede autory balíčků k jednoznačnému způsobu popisu, specifikace apod. Odpadne většina hacků při kompilaci některých balíčků, jako je tomu dnes. Co se týče SPEC souboru, tak to prakticky postrádá smysl, protože je to opravdu primárně určeno pro automatizovaný build SRMPek. Viz Plaque projekt. Na čem pracuje SuSE to nevím, ale RH také něco tvoří. Zda to bude používat Mock/Plaque, zatím nevím. Spustili k tomu i web, ale nemůžu si vzpomenout na adresu :o).
