Redistribuce vypálených ISO souborů byla zakázána jen komerčním subjektům (které neuzavřely s RH smlouvu). Školy, neziskové organizace, lidé mezi sebou a dokonce i firmy pro své zaměstnance mohli RHL šířit neomezeně včetně ochranných známek (dokonce kvůli zachování jména neměla být distribuce modifikována). Redistribuce nebyla možná už před vznikem RHN. RHL byl vždy základem pro RHEL (např. verze 2.1 vychází z RH 7.2). Zapomněl jste na subprojekt Fedora Legacy, který má dobu garantované podpory 6-9 měsíců prodlužovat. Vsadil bych se, že grafická instalace s pomocí NFS je stále k dispozici, protože GUI bylo pro FTP a HTTP přidáno. GUI nástroj pro správu balíčků závislosti v rámci výběru řeší (a yum i up2date například bez problému také). Grafický start sice přináší zpomalení na začátku (startuje X server), ale v závěru nemusíte čekat na start GDM (GUI přihlašování). Nepoužívate-li Xy, pak samozřejmě GUI start nemá smysl (a ani se nenainstaluje). Místo zápisu do /proc/sys bych raději doporučil editaci /etc/sysctl.conf. Fedora je nadále (stejně jako mnoho verzí zpět) překládána pro instrukční sadu i386 s optimalizací na i686. O i586 se Vám asi muselo něco zdát (nebo si to pletete s Mandrake). Vytuhnutí RPM při instalaci není způsobeno použitím non-Fedora balíčku, ale futexy (používané pro spouštění instalačních scriptů). Nicméně já jsem si toho ještě nevšiml a nesetkal jsem se s tím (v RPM ve verzi post-RH9, kterou si můžete pro starší verze RH Linuxu stáhnout z ftp://ftp.rpm.org). Interoperabilitu můžete elegantně řešit pomocí programů luit(1) i xterm(1) nebo (dočasným) nastavením UTF locale na vzdáleném systému. Midnight Commander už od verze z RH 8 (resp. 9) s UTF problémy IMHO nemá. Z konzole nelze vkládat jen některé (multibajtové) znaky (v podstatě velká háčkovaná písmena a ta malá, která nemají přímo klávesu na české klávesnici). Nechápu, co je za problém při přepnutí na ISO locale (asi myslíte LANG=cs), protože Glibc i s locale je stejná jako v jiných distribucích, které UTF implicitně nenastavují (pouhou změnou proměnné LANG). Také nechápu, proč by RH měl čekat, až tento krok provedou ostatní (to bychom se nedočkali funkčního UTF nikdy). Podpora MP3 ani DVD skutečně není možná kvůli licencím (za MP3 je třeba platit a dekodér DVD pro Linux oficiálně neexituje a tím pádem byste v USA i jinde porušoval distribucí zákon, což nelze). Osobně si myslím, že FTP edice SUSE bude také bez podpory MP3 (nebo by SUSE musela platit nebo by musela mít nějakou extra licenci). Ostatní distribuce jinak porušují (netýká se koupě krabice, kde to máte v ceně) zákony, což jistě dobré není...
No, celkově je to dost tristní recenze.... Některé věci vysvětluji podrobněji v dnešním článku na http://linuxzone.cz.
Je jiste pravda, ze RH se snazi dodrzovat americke zakony a proto vyradil podporu mp3 apod. ze svych novejsich distribuci. Pro me to byl ale jeden z duvodu, proc jsem presel z RH na MDK. Americke zakony me nezajimaji a doufam, ze ty evropske takove pitomosti jeste dlouho obsahovat nebudou.
Jinak k clanku - pokud se nemylim, RH neobsahoval podporu mp3 uz minimalne ve verzi 7.3, ne-li drive.
Problemy s RPM opravdu existuji od verze RH8.0 kdy proste RPM zatuhne pri instalaci noveho balicku. Chyba bude nekde v DB4 nebo v nespravne komunikaci mezi RPM a DB4. Staci dat kill -9 na rpm. smazat pomocne soubory v /var/lib/rpm ( jsou 3 "__neco.00[1-3] ) a rpm zase funguje dale. Je to neprijemna a asi i zakerna chyba. Minimalne na RH8.0 jsem vypozoroval, pokud se hned po instalaci snazi clovek odinstalovat mozillu ( vsechny 4 balicky naraz ) doje k 100% zatuhnuti RPM, chtelo by to overit popripade na zaklade teto teze chybu najit a opravit. Jinak RH o tomto problemu vi, nekolik zaznamu v buglistu ale mlzi protoze jej nedokaze opravit. Dokonce je tam popsan vyse uvedeny postup s vetou "situace neni kriticka, nijak to neafektuje funkcnost systemu". V RH9.0 je situace o to horsi ze nefunguje --rebuilddb ktery na RH8.0 fungoval.
Nicmene rpm jako takovy nadale funguje.
root@cookie root]# rpm --rebuilddb
error: db4 error(16) from dbenv->remove: Zařízení nebo zdroj jsou používány
Chyba je skutečně ve futexech. Dojde k nekonečnému čekání na uvolnění zámku. RPM z ftp://ftp.rpm.org to skutečně řeší, jak jsem již napsal. --rebuilddb není a nebyl po smazání zámků vůbec potřeba.
MP3 není americký problém, ale náš. Fraunhoferuv institut je z Německa. Kromě toho dodržování zákonů (i když třeba v našem právu není ošetřeno) je projevem civilizovanosti.
Patenty na MP3 jsou IMHO nesmysl. V norme je jasne receno, jak ma vypadat decoder, takze tam nemuze byt o patentech vubec rec a co se tyka koderu, tak ten musi splnovat to, ze vystupni data museji jit dekodovat dekoderem. To je taky v normou jasne dano - jedine, co si na tom muze kdo dat patentovat, je konkretni implementace koderu, protoze to je jedine, co tam lze prinest noveho.
Aby nedoslo k mylce, co je teple slovo editora a co muj osobni nazor, toto je *muj osobni nazor* na prilozeny link: Clanek neni spatny (i kdyz te politiky skoro moc, na trojnasobne delce textu jsem se nedozvedela nic noveho), ale fakt jsem se po ranu zasmala nad spojenim vzneseneho pana Kerslagera a LinuxZony - svuj k svemu, uzijte si to chlapci :)
Podpora UTF-8 v konzoli: Existuje patch do jádra od Radovana Garabíka, který to opravuje. Bohužel mění ABI, a tak se do jádra nedostane.
SuSE a MP3: SuSE sice nemá podporu pro vytváření MP3, ale pro čtení ano. Ač by i za to mohl Frauhofer Institute vyžadovat poplatky, zdá se, že dodržuje jakýsi "gentleman's agreement" - jde-li o software zadarmo a MP3 podporuje pouze pro čtení, licenční poplatky (zatím) nevyžaduje. Pro hw dekodéry a jakékoliv kodéry ano. A dosti vysoké.
Jak je tomu u LAME? Tam se, pokud vím, také poplatky neplatí. Měl jsem za to, že nezpoplatňování free věcí se týká i encoderů, ne jen přehrávačů.
Nicméně faktem stále zůstává, že MP3 může být kdykoli zpoplatněno v plné míře; je to tuším něco přes rok, co se o tom dokonce vážně diskutovalo, byť to nakonec Thomsoni dementovali. Na druhou stranu taky nechápu, proč v RH podpora free koderů/přehrávačů není.
No je to trochu proti zdravemu rozumu, a aby toho nebylo malo tak se to nakonec zase zhodi a nastartuje znovu s GDM :) A cely je to navic udelany tak divne, ze pri 2 monitorech to nenabehne temer vubec, pouze tehdy, kdyz na vas ma vyskocit ta kouzelna hlaska ze mate stisknout do 5-ti sekund y pro fsck, to to nahodi X a zase shodi aby se vas to mohlo na neco zeptat, no neni to na prd?
Jen při bootu jádra. Pak lze sice framebuffer dále používat (např. SUSE), ale stejně nakonec kvůli grafickému přihlašování startuje X server. V RH se rozhodli rovnou spustit X server, což je prostě jinačí přístup (nicméně logický je). Během léta byly pokusy o paralelizaci startovacích skriptů, ale nepřinesly kýžený výsledek a do finální distribuce se proto nedostaly. Nicméně byly dále optimalizovány samotné původní startovací skripty.
Děkuji za uznání :-) Přejdeme k věcným tématům.
Ad redistribuce: V tom nejsme ve sporu. V článku jsem pod pojmem redistribuce uvažoval komerční redistribuci.
Ad Grafický start: Na mém počítači se nejprve nastartuje grafický boot, až se dokončí, tak se X server shodí a nastartuje se nový ve kterém se teprve nastartuje GDM. Nedochází tedy k recyklaci jednoho serveru, ale X server se startuje dvakrát. Čili se tím start prodlužuje.
Ad Správa balíčků: Věcné výtky GUI nástroje pro správu balíčků si můžete přečíst např. tady http://www.root.cz/clanek/1629
http://www.root.cz/clanek/1584
Ad NFS instalace: Máte pravdu. Před chvílí jsem ji zkoušel a funguje.
Ad 386/586: V release notes je doslovně uvedeno že minimální procesor na kterém Fedora běží je Pentium. Ostatně oproti dřívějšku není v distribuci není balíček s jádrem, které by běželo na 386/486. To že je optimalizována pro 686 je fakt.
Ad UTF8: Pokud nejdou na klávesnici vkládat velká písmena s diakritikou, považuji takovou konzoli za v našich podmínkách nepoužitelnou. Luit a xterm nelze použít vždy, stejně jako ne vždy je možné na vzdálené straně nastavit UTF-locales. Navíc v UTF-8 jsou i jména soborů, takže může dojít k problémům pokud na jednom disku máte více distribucí Linuxu.
Ad MP3: SuSE Linux 8.2 FTP i Mandrake GPL dekodéry MP3 obsahuje - ftp://ftp.suse.com/pub/suse/i386/8.2/suse/i586/mpg123-0.59s-301.i586.rpm
Nedíval jsem se podrobně, ale start 1 X serveru je záměr. Takže pokud to funguje jinak, tak buď máte špatný dojem nebo je někde chyba (a zaslouží reportovat). Výtky k RPM si můžete strčit za klobouk, protože (jak jsem vysvětlil nejméně 2x) existuje jednoduché řešení. O i586 se v REL.N. mluví jako o minimálních požadavcích na instalaci (succesfull install), takže to chce lépe číst. BOOT jádro je pro i386 a můžete ho použít (nebo si přeložit svoje). Ostatně instalovat na 386 je hloupost, protože by to dlouho trvalo a navíc jistě mělo málo paměti (instalátor není optimalizován na malou spotřebu paměti). Konzoli používat nemusíte, máte FB a Xy (ve kterých xterm a luit jde použít vždy a mám takový pocit, že konkrétně luit i v textové konzoli, protože to je obyčejný filtr). Jestli chcete konzoli s UTF češtinou, záplatujte jádro nebo použijte ISO kódování (to je to takový problém?). Soubory na disku by měly být vždy v UTF, jinak z problémů nevylezete. A jestli chcete používat zároveň i jiné distribuce (bez UTF), umažte 5 znaků z /etc/sysconfig/i18n a přestaňte zbytečně plakat na nesprávném hrobě. O tom, že Fraunhofer institut nevyžaduje (i když to deklaroval) poplatky od SUSE zde byla řeč. Problém RH je v tom, že na rozdíl od SUSE má RH 50% trhu a zisky, takže případná žaloba má smysl a RH by neměl na obranu nic. Stejně tak to je s NTFS podporou - Microsoft může zažalovat bez varování kohokoliv a jestli to udělají, bude to pro SUSE i Mandrake velmi nepříjemné (ne-li smrtící). Takže nedat podporu pro MP3 je naprosto legitimní a správné.
Prominte, ale michate dohromady fakta a smyslenky a navic na to jdete z pohledu obhajce pristupu RH, nikoliv z pohledu nezaujateho uzivatele. Toho skutecne nektere veci nezajimaji. Uz pouzivani framebufferu pri spusteni jadra je haluz (kolik uzivatelu uz se kvuli tomu dostalo do potizi), spusteni X je IMHO jen pokracovani v nespravne nastoupenem smeru. Nic by se nestalo, kdyby "vylestena" bootsplash byla v textovem rezimu.
rpm balicky pro multimedia (mp3 plugin do xmms, mplayer, totem, xine...) lze pohodlne dotahat pomoci yum (apt) z jinych rpm zdroju (napr. http://rpm.livna.org/). Na freshrpms.net jiz jsou balicky pro Fedoru take. Nevidim v absenci techto balicku zadny problem. Diky licencnim omezenim je to naopak v poradku.
Spousta veci jeste neni na Fedore zralych. Take se hodne projevilo nedostatecne testovani. Obsahuje spoustu chyb. Napr. jedna naprosto zbytecna:
nastroj redhat-config-packages obsahuje relativni cestu na instalacnim mediu. To je v poradku, az na to ze cesta je RedHat/RPMS ale na CD je zpravna cesta Fedora/RPMS. Takze se to musi ve dvou skryptech opravit (python + smazat .pyc soubory). Jinak neni mozne doinstalovat pres tento "skvely" nastroj zadny balicek pozdeji.
FC1 ma jeste jeden bug, ktery mi prijde neprijemny: na textove konzoli se neznamo proc ztraceji nektere barvy (bila je svetle seda, zluta hneda, atd. - nejspis se ztraci bit pro svetlost). Nevite nekdo, jak to vratit do funkcniho stavu?
PS: Mam to vracene do iso-8859-2. (ale s utf-8 to asi dela taky, nijak zvlast jsem to ale netestoval)
RH jsem používal od verze 6.2 ostaní distribuce mě příliš nezajímaly. Teď už vím že to byla chyba. Je to stená věc jako když někdo nechce nic než Windows protože je zná a i když není uplně spokojen, nemá chuť jít do něčeho nového. Po RH8 sem vyzkoušel mnoho různých distribucí až sem skončil u Gentoo. Mam pocit že je to obecný trend pro RH - odliv uživatelů, že už dávno není tím čím byl v době verze 6.2 vzhledem k ostatním distribucím.
Napodobne. Tiez som presiel od RH k Gentoo. Tusim 8.0 bol moj posledny Red Hat. Zacali vyhadzovat z distribucie baliky, ktore som pouzival (lilo, WindowMaker a tusim aj rxvt) a nemal som chut ich zhanat kade tade a mat s nimi problem pri kazdom update. Ale inak to bolo celkom dobre distro. ;-)
Dobrý den,
používal jsem Redhat zejména pro jeho stabilitu, zázemí silné firmy, dostupnost updatů. No což, co bylo, bylo. Co byste mi poradili, jako vhodnou náhradu? Nepotřebuji grafické prostředí, jde mi zejména o server www, mail, podporu wify, pokud možné přehledné rozdělení konfiguračních souborů, které by se co blížilo RH. Nechci tímto příspěvkem rozpoutat velkou debatu mezi příznivcemi jednotlivých distribucí, ale tohle dilema teď asi řeší více lidí.
Děkuji za rady
Naozaj si myslim, ze toto je dobra debata na flame. Ja som spokojny uz druhy rok zo slackwarom. Na zaciatku som skusal RH, SuSE, MDK, ale najviac ma asi oslovil "slejk". takisto ako ostatni si pochvalujem stabilitu na serverove zalezitosti.
BTW: Nechcem ale nijak hanit ostatne distribucie. Aj tato diskusia o Fedora Core 1 si myslim, ze je troska hlboko ponimana. Uvedomme si ale, ze FC je skoro /relativne/ nova distribucia a potrebuje cas na svoj vyvoj. Clanok hodnotim ako dobry na ukazanie vlastnosti, ktore si vsimal autor. Takisto aj clanok od konkurencie je dobry. Ja sam sa necitim byt az tak na urovni, aby som sa pustil do recenzovania systemu.
A co sa tyka mp3 a popri tom aj konca RHL ako takeho, nezabudajte, ze: there ain't no such thing as a free lunch.....
Je to sice hezke, ale pokud chci trochu stabilni server a nechci platit, tak musim prejit na neco jineho. Pouzivam Redhat 7.3 k plne spokojenosti, ale od noveho roku budu postupne preinstalovavat par serveru na debian. Mozna, ze nekdo z vlastni iniciativy bude delat dal security patche, ale je to trochu nejiste.
Fedora mi pripada trochu jako testovaci distribuce, kde Red Hat bude testovat programy, nez je vrazi do placeny distribuce a nevidim duvod, proc bych se do toho zapojoval.
Osobne jsem provadel upgrade z RH 7.1 a probehl k me spokojenosti. Takze z 7.3 asi pujde tez. Akorat je hloupy, ze upgrade (z jekekoliv verze) je vlastne pouze upgrade nainstalovanych baliku, bez pripadne dokonfigurace primo v instalatorovi a hlavne mi tam chybi moznost zmenit seznam instalovanych baliku, nektere pridat a pripadne vypustit.
No a jak je to GNU, prece pokud RH vyda verzi pro. MUSI JI DAT ZDARMA, bez podpory samozrejme.
Jinak ja si myslim ze krome Orace a IBM se na podporu RH vsichni vykaslou a nebo min. zacnmou podporovat vice distr.
Pro mne to napr. znamena jedno, pokud se Fedora nevydari, zacnu uvazovat o PDL, Aurox ... pokud ani tyhle distra mi nebudou vyhovovat jdu do Debianu nebo Slackware ... no spise do debianu. Uz tak debian umim dobre, slacka taky takze zadny problem.
No a pokud prejdu jinam tak se mnou logicky odmigruji i nasi zakaznici, nebot ti pouzivaji to co ja (bodejt kdyz jim na to delam i support)
Tak dobra, ale pokud je neco pod GNU, tak si koupim 1KUS, dam to na FTP a rozsirim to po cele fi.
NIKDO MI NEMUZE PRODAT LICENCI NA PC ... pouze podporu na 1.PC
Pokud by totiz byla fedora nekopatibilni s RH prof. tak by lide bud zacali zdilet na jinych FTP RH prof.nebo by hromadne presli na neco stabilniho a staleho ... coz je pro mne nejspise Debian.
I kdyz abych se priznal celkem Fedoru vitam, pokud to bude tak jako predtim, budou updaty, bude kompatibilni (budou tam fungovat komercni programy) a hlavne bude stabilni a spolehliva.
Zdrojáky musí podle GPL dostat ten, kdo dostane (koupí) binárky. RH by nemusel zdroje vystavovat na FTP, ale kvůli GPL by je kdokoliv z platících klientů vystavit kdekoliv mohl (včetně jejich modifikace). Proto je RH raději vystavuje sám (bez zdržování a s vědomím, že jsou to přesně ty, které vystavit chtěli).
Už chápete proč velká spousta lidí zůstává u win, kde má jisttotu, že MS má tolik miliard, že se mu nevyplatí nevrazit nějaké další do podpory? Samozřejmě že u Linuxu funguje mnohem lépe podpora komunity, to ovšem není vlastnost systému, jen psychologická záležitost. Domnívám se, že tento krok RH velice poškodil vztah lidí k Linuxu, neboť pro velkou část BFU byl linux=redhat.
BTW myslím, že by se mělo věnovat větší úsilí na konečné vyřešení základních problémů, jako je UNICODE. "Konkurence" už to má vyřešeno několik let a bez problémů.
Už chápete proč velká spousta lidí zůstává u win, kde má jisttotu, že MS má tolik miliard, že se mu nevyplatí nevrazit nějaké další do podpory?
Aha tak proto skončila podpora NT a 9x. Mě to bylo hned divné.
BTW myslím, že by se mělo věnovat větší úsilí na konečné vyřešení základních problémů, jako je UNICODE. "Konkurence" už to má vyřešeno několik let a bez problémů.
Aaha tak proto pořád naražím na jakési cosi co se tuším nazývá Win1250. Mě to bylo hned divné. Nač nějaké ISO, že :-)
Jdi plácat někam jinam.
:-) Taky dobré a nebo tahle:
Pošlu někomu s woknous mail s řádně vyplněným kódováním a textem v ISO-8859-2 a mu to přijde. Koukne na to a vidí to OK. Dá odpovědět a najednou je to zmršené, protože nějaká ta rozhledna, nebo co, neumí vytvářet text v ISO-8859-2 a překódovat ji to asi nenapadne. A perlička na závěr: Výsledný mail má nový text ve Win1250 a v hlaviče má napsaáno ISO-8859-2. Neměli by s tím konečně něco udělat?
Problém hledejte mezi klávesnicí a židlí, s ISO 8859-2 neměl problém tuším ani mailový klient z IE4 a to už je hezkých pár let. Outlook i Outlook Express v defaultním nastavení používá ISO znakovou sadu, v souladu se standardy. To, co popisujete, dělali někteří klienti třetích stran, ale to už není problém malého měkkého.
Co se týče kódování systému, problém je ve dvou řadách Windows: Win9x mají podporu Unicode omezenou, u Win32 API funkcí chybí většina unicode verzí; naopak řada postavená na NT jela vnitřně už minimálně ve verzi NT 3.51 (a možná dřív) v Unicode, byť s tím některé programy (i od MS) nepočítaly.
Podívejte, já nebudu všem zoufalcům co používají MS produkty vysvětlovat jak to mají udělat. Nepopiratelným faktem je, že když jim přijde mail v ISO-8859-2 tak to vidí dobře. Když dají reply, tak se ten text co přišel od nás domrví a v tom co příjde je zase napsáno ISO-8859-2 a přitom ten text v ISO-8859-2 rozhodně není. Jak a proč to ta rozhledna domrví já netuším a ani to nehodlám zkoumat. A nejedná se o ojedinělý případ jednoho člověka a jedné firmy, ale několik lidí z různých firem.
A když už to konečně vyřeší, tak by taky měli konečně něco udělat, aby všechny binární přílohy neměly mimetyp application/octet-stream. Kdo to má pořád čuchat, že tenhle application/octet-stream je zrovna application/msword nebo application/vnd.ms-excel. Už by s tím konečně měli něco udělat!
V tom pripade je to evidentni blbost adminu tech firem, kteri neco nastavi a nevi co to vlastne je (i co se tyce toho MIME, ted jsem si schvalne zkusil z OE poslat maila s wordovskou prilohou fse je jak ma byt). Cili nadavat by se v tomto pripade melo spis na to, ze admina u Windows dela kdejakej nymand, kterej o systemu vi prd. Nejsem si ted jist, jak se chova SMTP connector u Exchange, ale vzhledem k tomu, ze si bezne mailuju s lidmi, kteri pres Exchange server jedou, problem by nemel byt ani tady. Jedine, co vam muzu poradit, je prudit jejich postmastera, mne se to v takovych pripadech obvykle osvedcilo.
A co je to vlasně za licenci která se odklepává během instalace fedory? Mě to jako GPL nepřišlo...
Všechny trouble s grafickým startem vyřeší
rpm -e rhgb
nebo nastaveni runlevelu na 3
Proč už nejdou odebírat jednotlivé pakáže? (Resp. mi je tam instalátor bez ptaní znovu nacpe pokud je potřebuje k nějakým obskurním dependencím.) Jojo, zlatý flatview, párkrát tam a zpátky a bylo po potížích...
Konfigurace X během instalace je taky pryč...
... ale ich posledne kroky ma nutia prejst na ine distro. Co sa tyka fedory, nelubi sa mi uz samotny nazov ale to je o inom. Uz par tyzdnov sa venujem Debianu a moznosti hladkeho prechodu z RH na Debiho. Prve co som zistil je to ze ten prechos nebude v ziadnom pripade jednoduchy, ale na druhu stranu laka ma vysoka dostupnost takmer "vsetkych" binarnych/source balickov z oblasti opensource, a takisto urcita kultura systemu (filozofia) o ktorej sa mohlo RH len snivat, a ktoru postupne zacinam chapat ... Hold je to jedna z najstarsich distribuci a na tom neco musi byt :)
Suhlasim. Mimochodom vsetky distribucie, ktore sa snazia podobat windowsu ( ktovie preco, ked je to vlastne velky Linuxovy nepriatel ) postupom casu stracaju uzivatelov, pretoze stracaju vlastnosti UNIXU a jeden windows tu uz je ovela lepsi (v tomto zmysle). Vznikaju kadejake wizardy, ktore zmatu vsetko, co nakonfigurujem rucne v suboroch. Textova konzola zachvilu zacne byt zbytocnou a klikacie okna su stale }a aj budu) nedostatocne. Toto si UNIXovo zvyknuti uzivatelia uvedomuju a prechadzaju aj napr. k tomu "nenavidenemu" debianu.
Co na tohle rict. Me to proste prijde jako pekny kecy. Nevidim jediny problem v RedHatu popr. Fedore editovat konfiguraky rucne a kdyz je tam nejaky wizard, ktery funguje, tak proc he nekdo nemuze pouzit. Kdy kazdy pochopopi, ze na vyberu distra zas az tak moc nezalezi. Jak me Fedora brani(zabrani) v pouzivani textove konzole ?
Fedora je/bude urcite velmi zaujimave riesenie pre pracovne stanice. Neviem ale, ako to bude pre servre, dufam len, ze aj tam si najde miesto.
Mna uz ale nejaky ten cas zaujima OpenNA Linux:
http://www.openna.com/
Povodne vychadza z RedHat a zda sa byt velmi rychlou, stabilnou a bezpecnou distribuciou, zadarmo a s moznostou supportu od firmy OpenNA Inc.
http://www.openna.com/products/os/features.txt
Pre servre vysoko zaujimava distribucia, dokonca mam pocit, ze samotne OpenNA na svojom webe zdoraznuje vyuzitie OpenNA Linux hlavne na serverovske instalacie (ale s moznostou vyuzitia aj ako pracovnej stanice).
http://www.openna.com/products/os/whatis.php
Este pred vydanim verzie 1.0, ked bol este ako RC verzia, vychadzal z RedHat (naposledy 7.3), na ktoreho custom instalaciu aplikoval vlastne scripty a specialne vykompilovane RPM baliky s dorazom na bezpecnost.
Svojho casu som si tie scripty (vyhadzali vsetky nepotrebne baliky a subory z minimalistickej custom instalacie RH7.3) od nich pozical, upravil a pouzival na RedHat 7.3, a mal som tak zhruba 130 MB instalaciu RedHat 7.3 pre server (web, ftp, smtp), pripadne do 200-250 MB, ak som spustil dalsie scripty, ktore mi do takto orezanej instalacie 7.3 prihodili este baliky pre kompilaciu a buildovanie rpm balikov.
Od toho casu pozeram na OpenNA Linux ako na vysoko potencionalneho kandidata na moje servre namiesto RedHat (momentalne namiesto Fedory).
Pokial uz niekto z Vas OpenNA Linux vyskusal alebo pouziva, bol by som vdacny za Vase nazory. Ja som s nim doposial velmi spokojny.
Redhat za neco stal naposledy ve verzi 7.3. Potom rychle nasledujici 8 a 9 byly zabugovane a nestabilni. Fedora Core 1 je neco jako RH 10, ale stale nebyly odstraneny problemy s rpm (behem 3 hlavnich verzi jedna stejna chyba?) a unicode. Navic distribuce bude mit horsi podporu, coz je dalsi duvod proti.
Nevidim uz jediny duvod proc pouzivat tuto distribuci. Zkusim neco jineho. Redhatu i fedore n@sr@t.
- je takovy obrovsky problem si prislusny software zkompilovat ? Napr. chyba v sendmailu, stahnu zdrojaky ci patch ze sendmail.org, zkompiluji ... a nepotrebuji binarni baliky...
- Autor zapomel na existenci velice zajimaveho projektu FEDORA LEGACY: http://www.fedora.us/wiki/FedoraLegacy
Tento projekt ma za cil prave podporu Fedory po delsi cas a co vic (a to je velmi prijemne) - i podporu RH 7.3 . Vzhledem k tomu, ze RH 7.3 byla posledni pouzitelna distribuce od RH (a velice dobra) a asi jeste dlouho pobezi na rade serveru, je to vcelku dobra zprava. Doufejme, ze ten projekt uspesne pobezi - koneckoncu muzeme vsichni pomoci...
A co bych radil tem, kteri chteji premigrovat? Doporucuji SuSE Linux Pro. Krome toho, ze ma RPM je velice kvalitni a tech par korun za krabici cloveka nezabije. Osobne hodlam SuSE Linux Pro. nasadit na nekolik serveru, kde dosud bezi RH6.2 (updatuji kompilacemi)...
Zaujalo me tvrzeni autora o dobre funkci ACPI
viz "Kladně hodnotím, že fedoří jádro 2.4.22, je prvním distribučním jádrem, které dokázalo beze zbytku oživit powermanagement mého dva roky starého HP Omnibooku. "
Muzete mi nekdo poradit, jak rozjet poradny powermanagement na Omibooku 4500 kde uz je RH9.0 se vsemi updaty ? Stacilo by pouze vzit to jadro z FC, nebo je jedina moznost ji instalovat celou ?
Pokud by to jadro stacilo, jake jeste baliky pro ovladani ACPI musim z FC vzit aby to napr. suspendovalo do RAM popr na disk a hlidalo stav baterie ?
Diky
Mám desktop počítač s deskou Intel D845GBV. RH9 na tom neuměl udělat poweroff tak aby se úplně vypnul.
Při startu do logu napsal něco jako APM BIOS not found - bez záruky. Už to nepíše tak nemůžu opsat.
Stáhl jsem si ACPI patch a aplikoval jej na distribuční jádro. Byl tam myslím jeden problém, který jsem musel opravit. Ale bylo to něco jednoduchého, že jsem si to spravil i já, C jazykem nevládnoucí.
Teď už dokonce můžu dělat i korektní shutdown tlačítem power na kastli.