Ahoj jsem tu zase, protoze mi preletel pres nos Red Hat a jejich desktop system. Slysim o tom poprve - az do ted jsme mel za to ze Fedoru pouzivaji jako desktop system. Mam to chapat tak ze Fedora je testovaci -> co se osvedci a je stabilni a tudiz prodejne se dava do serveru a vyse zmineneho desktopu? A jeste jedna vec na strankach Red Hatu se musim regnout… a pak si to stahnu. Je to taky zadarmo nebo jsou tam license jako u MS? Ja se prave moc v techto vecech neorientuju. Na netu casto vidam ze i linux stoji penize. Vim ze co je vydano pod GNU se nesmi prodavat - takze to mi moc nesedi. Jeden spoluzak mi rikal, ze i jejich servery jsou zadara a ze prodavaji jen podporu. Je to pravda? Mne se to nejak nezda ze by zili jen z toho.
Spousta otazek s komplikovanymi odpovedmi. RHED vznika z Fedory - je to skoro tak,jak pises. Red Hat moralne i financne podporuje vyvoj Fedory, resp. novych projektu. Enterprise Desktop a Enterprise Linux ale neni jen odladena Fedora. Red Hat do ni pridava nektere svoje nastroje a predevsim k nim dava podporu, garanci vyvoje, aktualizaci na delsi dobu a certifikace pro beh dalsich komernich aplikaci (velkych databazi, CAD nastroju, simulacnich prostredi atd.).
Ted ke GNU GPL software. GNU GPL software muzes prodavat, OVSEM vzdy k nemu musis zdarma poskytnout zdrojove kody. To je presne to, co dela Red Hat - stahnout si binarni zkompilovany RHEL nejde. Ten si muzes pouze koupit - cena se sklada ale predevsim z toho, ze si kupujes sluzbu podpory (helplinku) a aktualizace/opravy systemu - aktualizace RHEL nejsou zdarma jako u Fedory. Je to skutecne tak. Z tohoto duvodu se Red Hat a dalsi firmy produkujici komercni Linux zameruji predevsim na segment firemnich zakazniku. Skutecne nechteji poskytovat podporu Frantovi Omackovy z Horni Dolni za 1000,- rocne, protoze takova prace by se jim asi moc nevyplatila.
Vzhledem k tomu, ze ovsem zdrojove kody RHEL jsou k dispozici zdarma, muzes si cely RHEL sam zkompilovat. A to je presne to co dela projekt CentOS. Ten ovsem nenabizi placenou podporu ani placene verze.
V podstate je to jak pises. Red Hat se podili na vyvoji Fedory a vyuziva zkusenosti s ni. Red Hat Enterprise Desktop ale obsahuje programy starsich, tedy odladenejsich verzi a ma podstatne mensi pocet baliku v distribuci. Zadarmo si to asi nestahnes. Red Hat ovsem poskytuje podle licence zdrojaky. Na jejich zaklade pak vznikaji distribuce, ktere zadarmo jsou - treba CentOS, ktery bude asi rozsirenejsi nez original Red Hat. Skutecne ziji z prodeje podpory. OS bez podpory je k nicemu - rozumne firmy do rizika nemuzou jit.
Pak jsme zil asi rok (pred rokem jsme si naistaloval Fedoru) v omylu jaky mam stabilni desktop. To je to co jsme od linuxu cekal - to ze to ma x novinek ale je to neodladene/nestabilni je mi k nicemu. Tzn. CentOS=RHEL. Rozdil je v tom ze je zadara a asi i v te kompilaci. Dedukuju to z toho ze RH dela pri kompilaci neco o cem nechce aby ostatni vedeli(know how). CentOSse to zrejme snazi co nejvice napodobit takze uplne stejny neni. Vite v cem se tedy tyto kompilace muzou lisit? Co se tam dela jinak? Podle meho i ten CentOS neni tak stabilni jako RHEL protoze postup jeho vytvareni neni identicky s RHEL.
Pokud ti Fedora prisla po dobu jednoho roku stabilni - pak je stabilni 
RHEL neznamena, ze je to uplne bez chyb. RH podle me nic tajemneho pri kompilaci nedela, naopak je velmi otevreny. Ale z podstaty veci nejsou Centos a RH 100% identicke - vice se dozvis na strankach Centosu.
polo napsal(a):
Dedukuju to z toho ze RH dela pri kompilaci neco o cem nechce aby ostatni vedeli(know how
Ne, nedělá nic tajemného, vše je otevřené - zkrátka opensource 
CentOS musí ze zdrojáků vyházet pouze loga a nějaké další “nepodstatné” věci. Není to tak žeby CentOS na RedHatu nějak parazitoval. Je to oboustraně výhodná symbióza. RedHat myslím má někde na svých stránkách návod jak ta loga a copyrightované materiály ze zdrojáků odstranit.
Centos o sobě tvrdí, že je 100% binárně kompatibilní. Co tedy funguje na RHEL musí fungovat i na CentOSu. Může být snad problém v tom, že si nějaká instalačka kontroluje, že v /etc/redhat-release je napsáno RHEL, ale to se dá snadno oeditovat
To Kalidah: Fedoru jsem mel a mam pouze na nauceni se s linuxem. Kvuli firme kde pracuju nemuzu pouzivat linux jako primarni system. Slovo linux se tu pred sefem nesmi vyslovit - i ted pisu potajnu z prace a doufam, ze me neuvidi:)
Jeste jedna vec co me zajima ohledne Fedory a i jinych distro. Kdyz stahuju napr. pidgina 2.0.0 pres yumex tak se stahne pro F7(protoze tu pouzivam). Ti co maji F8 uz stahuji “jineho” pidgina 2.0.0? Na netu jsou casto programy pro tu ci onu verzi distra. Tzn. v kazde verzi distra se delaji tak razantni zmeny ze neni v nekterych pripadech kompatibilni s predchozim? Pokud to tak je musi to byt tezke pro programatora. Vyjde F8->napise pidgin pro F8. Sotva ho ale dopise uz je tu F9 a on jede jako znova(editace zdrojaku)? Napr. prave ve windows se knihovny systemu ktere jsou programatory vyuzivany nemeni-nemeni se jim to po rukama. Jasne kdyz vyjde dalsi windows tak jo(ale ty vychazi po x letech a maji jaks taks dobrou zpetnou kompatibilitu). Jina kapitola by byla asi JAVA a .NET. Nejsem programator, ale myslim, ze kdyby napr. app pro linux byly v jave(vim nektere jsou) tak pri zmene distra by jela i stara app protoze by jela v JVM a uzivala by stejnych knihoven(framework). U toho CentOSu tedy verze vychazi v delsich intervalech a celkove to neni tak “divoke”? Pak bych daval prednost asi tomuto OS.
F7 a F8 maji jiny binarni balik pidgina, ale zdrojaky jsou ± stejne. Vyvoj pidgina (i jineho sw) probiha nezavisle. Neprovadeji se zmeny pro ruzne verze ruznych distribuci. Proste existuji nejake pozadavky na verze ruznych knihoven a tim to konci. Fedora 8 je proste distribuce zkompilovana v urcitem case a s urcitymi verzemi knihoven atd. Casto i baliky ruznych verzi funguji - pokud jsou splneny zavislosti. Ja napriklad pouzivam updaty kernelu z Centosu 5 pro update Fedory 5 a funguje to. Razantni zmeny knihoven, kdy veci prestavaji fungovat nejsou zas tak caste. Vyhodou Centosu je prave to, ze to neni tak divoke.
Fedora je skutecne svym zpusobem divoka. Je to ale proste kompilat (v naproste vetsine pripadu stabilnich) verzi aplikaci, ktere vydaveji ruzne projekty. Faktem je, ze kdyz se to vsechno sestavi poprve, casto se prijde na to, ze nekde neco s necim neni kompatibilni. Od toho jsou vyvojove verze Fedory, aby se to odladilo. Problem CentOS a RHEL je casto napr. to, ze neobsahuji novejsi kernel, ve kterem jsou ovsem pridany . nove ovladace TV a wifi karet atd.,tusim jeste dnesk v RHEL neni ani 3D akcelerovany desktop (to si ale nejsem jist).
Co se tyce F7 tak za mesic skonci jeji zivotnost - Fedora projekt prestane vydavat aktualizace, tedy predkompilovane baliky. Fakticky ti sice nic nebrani kompilovat si nove verze aplikaci, otazkou je, zda na to mas cas a prostredky. Pro F8 se vydanim F9 mnozstvi aktualizaci omezi v podstate predevsi na opravy zavaznych chyb, pro F9 budou kompilovany i nove verze aplikaci.
Nektere jine distribuce (napr. Ubuntu) ke vsem svym vydanim poskytuji pouze bezpecnostni aktualizace a nove verze aplikaci jsou dostupne pouze v nasledujici verzi.
Jeste s tim ze CentOS neobsahuje novy kernel s novymi ovladaci. Ovladace ruznych zarizeni jsou v kernelu? Tzn. na svete je x milionu zarizeni, ale ja pouzivam jen nekolik z nich. Je zbytecne mit v kernelu vsechny, chci mit jen ty co potrebuju. Jednou jste mi vysvetloval ze zavislosti se tahaji k instalovanemu programu dodatecne a nejsou uz primo v nem proto, ze kdyby to tak udelal kazdy programator byl by system za chvili bez pameti na disku. Proc se to tak nedela i s ovladaci? Mohlo by se jet v nejakem provizornim modu a pak se doinstalit ne? Jinak 3D nepotrebuju a nejnovejsi TV karty ozelim:)
Predkompilovane baliky = instalacky(rpm) aplikaci?
Ovladace nejruznejsich zarizeni jsou soucasti zdrojovych kodu kernelu, ale kompiluji ze zvlast jako tzv. moduly - najdes je v /lib/modules/. Jsou soucasti baliku kernel*.rpm, do pameti se nahravaji jen ty co jsou potreba. Ktere to jsou zjistis prikazem lsmod. Moduly=ovladace lze za behu kernelu pridavat a odstranovam prikazem modprobe.
Ovladace pro kernel lze dohravat i z repozitaru tretich stran jako samostatne baliky - to presne dela livna, musi byt ovsem zkompilovany pro stejnou verzi kernelu.
Predkompilovane baliky = rpm. Ale pozor jsou i src.rpm a jsou prave zdrojove kody urcene k rychlemu sestaveni binarniho rpm. Balik src.rpm obsahuje krom zdrojoveho kodu programu jeste popis jak balik .rpm vytvorit tzv. spec soubor a napr. patche, ktere se na zdrojovy kod musi aplikovat, aby fungoval v dane distribuci, nebo proste jen kuli oprave nejake chyby.
Jen aby ti v CentOSu nechybely treba mp3 kodeky :).
Jeste jedna nesrovnalost… “PREDKOMPILOVANE” = RPM = To co ve windows soubor.exe. Tzn spustim a on se “rozhaze”(zapise si co kde potrebuje) po systemu. Pak bych to ale spis nazval zkompilovane. Mam zdrojak->zkompiluju->soubor.exe a ten spustim. V pripade slozitejsich programu se instaluje(zapis do registru atd.).
V linuxu nejsou registry ale textove soubory… ZDROJAK->KOMPILACE->RPM. Ten spustim a probehne instalace (zapis do ruznych casti systemu atd - vlastne ani nevim co se pri instalaci deje… v tomto je pro mne system nepruhledny). Pokud presto trvate na slove predkompilovane - co pak znamena podle Vas zkompilovane.
Jedine snad:
zkompilovane - na mem systemu
predkompilovane - zkompilovane na jinem systemu(ale instaluje se na mem)
pokud je to spravne tak pak ve win je to stejne akorat ten dany soft kompiluje vzdy(temer) tvurce (tzn. vetsinou na jinem systemu) a ja stahuju z netu uz jen *.exe.
Pokud to tak je pak uz chapu proc je problem se zavislostmi - je to ruznorodosti linuxu. Ja neco zkompiluju (napr. na Ubuntu) poslu rmp Vam (na Fedoru) a ono to nejede, protoze tam mam nalinkovane knihovny, ktere vy nemate. Jedine reseni snad pridat k tomuto jak vy rikate predkompilovanemu rpm jeste nejaky info soubor o tom co vsechno potrebuje z “vnejsku”(proste co je prilinkovano). A vy byste si to musel dostahovat. Pro bezneho uzivatele takovy postup peklo:)
A jeste jeden dotaz s tim spojeny - kdyz to tak stahuju pres yumex tak on vi jake zavislosti ma dotahnout pak to musi znamenat ze bud primo s tim stazenym programem tam nejake info je a nebo v tech repozitarich musi byt zaznam typu “pokud stahuje rpm xyz stahni a instaluj jeste x dalsich rpm”. Mozna jsem uz toho napsal az moc:)
Zkompilovanwe nebo predkompilovane - to je jedno. RPM neni to co soubor.exe, to je prilis zjednodusujici a pak to vede k nepochopeni, jak predvadite. Pkod RPM trochu nastudujete, zjistite, ze je to mnohem pruhlednejsi (100%) a jednodussi nez ve Windows. Problemy se zavislostmi nejsou kvuli ruznorodosti, ale spise kvuli nezkusenosti uzivatele a nedokonalosti tvurcu sw - proste lidsky faktor. Ja treba podobne problemy nemam, asi nejsem bezny uzivatel :).
RPM ma v sobe i ty zavislosti (jak pisete info) a mnohem vic (dalsi info je v repository), proto je yum schopen je vyresit za vas.
Ja myslim, ze polo si to prebral celkem spravne. Az na to prirovnani exe=rpm. Ono, dnes je problem v tom, ze instalacky windowsich programu uz casto taky nejsou .exe ale .msi. Driv byl exe taky jen instalator, uprimne znacne zmateny a kazdy vyrobce software ho pouzival trochu jinak, ktery skutecne rozhazel soubory po disku a provedl zapisy do registru. Tento instalacni exe tak nainstaloval jen dalsi exe samotne aplikace. Puvodni vyznam .exe je totiz executable - tedy spustitelny kod. K tomu jsou ruzne .dll - dynamic linked library a datove soubory nejruznejsich pripon, ktere si kdo vymysli.
V linuxu se soubory nerozlisuji podle pripony jako ve windows, ale podle obsahu (hlavicky, viz man file) a prav, executable = spustitelny je ten soubor, ktery ma nastaven tento priznak (viz man chmod). RPM je pak vic neco jako prave .msi, nebo .zip - je to archiv/balik obsahujici zkompilovane binarky, datove soubory, konfiguraci a informace o zavislostech, o tom co se ma udela pri a po instalaci atd. Kdyz si pustis “mc” a stisknes na souboru .rpm enter uvidis celou jeho vnitrni sktrukturu - a uvidis i to, ze kazdy .rpm soubor si s sebou nese prave informace o zavislostech - jake dalsi baliky ke sve funkcni potrebuje. Vyhoda ja takova, ze v Linuxu je teoreticky kazda knihovna jen jednou a kazdy program, ktery ji potrebuje si o ni pozada. Ve windows, aby autor mel jistotu, ze potrebne knihovny jsou v systemu, musi je kazda aplikace dodavat znovu. Samozrejme existuji sytemove knihovny windows, ty potom aplikace nemusi obsahovat, ale proto jsou pak Windows tak velike. V Linuxu lze aplikace zkompilovat i tak, ze obsahuji vsechny potrebne knihovny - rika se tomu staticke slinkovani (spojeni). Takto se dodava napr. balik skype (tedy aspon do nedavna jeste dodaval… ted nevim). Takova aplikace je pak zbytecne velika a zabyra hodne mista v pameti.
Problem se zavislostmi jak si ho popsal je taky vicemene spravne, az na to, ze do toho vstupuje este jedna komplikace - existuji ruzne systemy vytvareni balicku, takze Fedora pouziva rpm, Ubuntu pouziva deb. Jsou to jen ruzne struktury archivu rikajici vicemene to same, bohuzel ale nejsou prenositelne. A aby v tom byl jeste vetsi zmatek, tak .rpm vytvorene na Suse nebo Mandrive, nejde pouzit ve Fedore, prave proto, ze kazda distribuce ma jinak rozdelene knihovny a aplikace - to je to co dela distribuci distribuci.
Co se yumexu tyce, je to jen graficka nadstavba yumu. Samotny yumex je jen klikatko a praci za nej dela yum, ktery komunikuje s repozitarem, kde jsou tzv. metadata - informace o obsahu repozitare. Na zaklade techto dat pak yum resi zavislosti - kdyz nejaky balik potrebuje jiny balik, podiva se do metadat a najde dany balik a prida ho do instalaciho procesu. Tento proces je o rad narocnejsi na udrzbu distribuce nez to co pouzivaji windows, podle me je ale take mnohem vyspelejsi. MS k tomu jistym zpusobem speje prave s .msi soubory. Driv kazdy program pro windows, ktery jsi stahl si s sebou nesl i vlastni instalator programu. V linuxu existuje definovana struktura .rpm souboru a tento soubor je zpracovan spravcem balicku (rpm a podle nej spravce rozhaze soubory po disku. Tedy je jeden univerzalni instalator, kteremu se jen dodaji informace co ma udelat.
Diky za naprosto vycerpavajici informace. Nejradsi bych na zaklade toho napsal knizku:) Nemyslim takovou kde jsou prikazy linuxu a nebo ty kde popisuji “klikatka” ale proste uplne obycejnou ve ktere bude popisovano co se vlastne deje uvnitr systemu:) I kdyz ted me napada ze tato vysada by patrila Vam. Myslim, ze by ste mel uspech. Neco takoveho podle me na trhu neni.
Nekde tu bylo cele vlakno o knizkach. Divil bych se kdyby to napr. v Mistrovstvi v Red Hat Linuxu nebylo… ale necetl jsem tak nevim. Krom toho vydat knihu neni vubec legrace.
covex napsal(a):
Divil bych
se kdyby to napr. v Mistrovstvi v Red Hat Linuxu
nebylo… ale necetl jsem tak nevim.
knihu mam … neviem ci je tam presne to o com sa tu pise,
mozno niekde na zaciatku, tie casti som len preletel …
chcel som len k tej knihe, ze som bol viac menej z nej sklamany:
- vela stran venovanych bash
- vela veci popisovanych cez klikacie system-config-nieco
a teda malo veci popisovanych ak mam serve bez graf. nadstavby
nejak tam redhat tlaci tie ich system-config-cosi
co by mi nevadilo keby to bolo aj pre text mode, co nie je.
teda od knihy s takym nazvom som cakal ze sa budu rozoberat hlavne text mode = textove konfiguraky a nie kliknite sam napiste a potom kliknite tam …
Zvlastni… ja teda knihu nemam, ale nekdo ji tady myslim celkem chvalil. Doufal jsem, ze to je prave kniha popisujisi spis obecne postupy, nez konkretni klikaci nastroje, ktere se navic verzi od verze celkem lisi, nektere zanikaji, jine vznikaji… skoda.
Asi jsem se spatne vyjadril. Ta kniha je best of the best! Tyka se obecnych postupu a prace v prikaz radce. Je opravdu velmi povedena. Ale napr. tak podrobne jak jste tady vysvetlil RPM a jine systemove veci na ktere se ptam tam nejsou(tak podrobne). Neni to chyba knihy - autor musel udelat kompromis mezi tim aby tam dal vse a tim aby kniha nemela 1000 stran(ma asi 250). Kdyz si vezmete to na co se tu ptam tak se da rict ze to jsou zbytecnosti co nikoho nezajimaji…jen me:)
Aha prehlidnul jsem se. Mel jsme na mysli Linux: Prirucka ceskeho uzivatele od Vilema Vychodila.