Vlákno názorů k článku Je libo Debian GNU/kFreeBSD? od hx - "Leckdo tvrdí, že jádro FreeBSD je v mnoha...
-
hx (neregistrovaný)"Leckdo tvrdí, že jádro FreeBSD je v mnoha ohledech lepší než jádro Linux."
A na tuhle blbost autor prisel jak? Prijde mi, ze kdysi v dobach linuxoveho kernelu 2.2 a mozna i 2.4 nekdo udelal benchmark, vypichl si co se mu hodilo do kramu a 5let to porad papouskuje dokola ...
Netvrdim, ze Linux je lepsi ve vsem - to neni proste pravda, ale oblbovat neznalé masy neustálými tvrzeními o tom, ze FreeBSD je MNOHEM lepsi je davno prekonany FUD. -
ava (neregistrovaný)Promin, ale to ze "LECKDO tvrdi, ze jadro FreeBSD je v mnoha ohledech lepsi nez jadro Linux" blbost rozhodne neni, sam znam prinejmensim jednoho takoveho cloveka a verim tomu ze jich jsou spousty. Nekterym z techto lidi se muze Debian GNU/kFreeBSD libit. Nevim nad cim si tu vylevas zluc.
-
Ledaskdo to tvrdí, ale málokdo dokáže říci nějaké konkrétní výhody. Sám jádro FreeBSD moc neznám, z vlastních uživatelských zkušeností si pamatuji, že FreeBSD mělo svého času výrazně lepší virtual memory management (nicméně současný Linuxový oproti tehdejšímu Linuxovému je jako nebe a dudy).
Nevíte někdo o nějakém trochu aktuálnějším srovnání?
Nechci zapalovat ohníčky, zajímají mne fakta. -
neologism (neregistrovaný)freebsd jadro ma navic oproti linuxu, aspon teda co vim (mozna z toho neco ma linux taky, neznam moc linux):
1) moznost nastavovat ruznou velikost memory stranek (nezavisle na hw)
2) m:n threading
3) direct dispatching a fast forwarding packetu
4) fs snapshots a softupdates
5) geom a zajimave geom tridy
6) polling na sitovkach (a koluji velmi nezrale patche na obecny polling)
7) jaily (tusim to nejak linux ma, ale minimalne jsem to nevidel v praxi)
8) memguard a ddb (mozna koluji nejake externi patche pro linux ale pokud je nikdo z vyvojaru nepouziva tak je to napicu)
9) accept filtry
10) compat layer s linuxem/nbsd/svr4 a buhvicim jeste
to mne jen tak napadlo z hlavy, netvrdim ze je to seznam nejdulezitejsich rozdilu nebo tak, linux ma taky plno veci navic (hnusny kod, milion zbytecnych ovladacu na kokotiny, stovky zbytecnych fs ktere nikdo nepouziva atak.). -
neologism (neregistrovaný)fakt nepotrebuju ovladace na dalkove ovladani televizni karty atd. je pravda ze linux podporuje kazdy nesmysl a na podporu hw se dava hrozne moc vyvojoveho potencialu ktery pak chybi jinde. a co se tyce fs... k cemu je dobre mit 5 (pouzitelnych) fs ktere umi to same? tento trend se ted zacina objevovat i ve FreeBSD a vubec se mi to nelibi. mne osobne staci na 1 ucel 1 fs. tj. klidne budu mit fs na disky, fs na pamet, fs na sit ale proc mit ke kazdemu 150 ruznych?
a k cemu kompatibilita? mozna by neskodilo se vzbudit a podivat se okolo, ze ne cely svet je linux. to je vubec velka nemoc oss, vsichni predpokladaji ze vsude je linux. ;( -
Kompatibilita je pěkná věc, ale obvykle stačí, aby fungovala na úrovni zdrojáků. Umět spouštět cizí binárky je možná pěkná featurka, ale pro většinu uživatelů dosti zbytečná a asi nestojí za práci s jejím udržováním spojenou.
Přikladem budiž spouštění SVR4 binárek pod Linuxem -- kdysi fungovalo, dnes je to projekt, který živoří, protože už o něj prakticky nikdo nemá zájem. -
Většina ovladačů kupodivu vývojový potenciál jádra nezabírá -- mnohé z nich píší lidé, kteří by na jádro nesáhli, kdyby se jim zrovna neobjevil doma nějaký zatím nepodporovaný kus hw :)
Napsat filesystem, který by byl ve všech parametrech lepší než ostatní, se zatím nikomu nepovedlo, takže alespoň do té doby je určitě šikovné mít na výběr. -
Díky za postřehy, i když u některých si nejsem úplně jistý, jestli to doopravdy jsou výhody -- například m:n threading se pod Linuxem přestal používat, když se zjistilo, že dobře udělaný kernelový threading je minimálně stejně rychlý, ale daleko jednodušší na implementaci.
Copak je "geom" a co jsou to accept-filtry?
Co se ovladačů týče: Ono je něčemu na škodu, že má Linux spoustu ovladačů a filesystémů? Tedy mimo toho, že se zdrojáky déle downloadují a zabírají o něco více? :-)
Hnusnost kódu se těžko soudí -- v každém dost velkém projektu pravděpodobně nějaké kusy hnusného kódu budou (zatím jsem je vždycky našel :) ). Máte nějaký konkrétní příklad? Pokud ano (a není to nějaký příliš obskurní driver na něco, co jsem nikdy neviděl), rád ho přepíšu. -
anonymníM:N threading ma sve kouzlo... dost problem je, ze vetsina aplikaci predpoklada ze funguje na linuxu (ktery ma prakticky jen 1:1 threading, rychle context switche, rychle/nepresne hodiny atd.) a je na nej optimalizovana. to se tyka i toho M:N threadingu. faktem zustava ze minimalne teoreticky je to proste lepsi architektura nez 1:1/1:N
geom je IO framework, ktery umoznuje napsat "tridu" ktera "neco" (raid, vzdalene disky atd.) dela a pak to pouzivat podobne jako tridy v oop. tj. je ruzne propojovat, stackovat atd.
accept filtry jsou filtry ktere zajisti aby zpracovani nejakeho protokolu bylo optimalni. tj. aby se napr. nestalo, ze kdyz prijde http pozadavek na port 80 aby se nezpracoval takhle:
prijme se GE
context switch do apache
prijme se T....
context switch do apache
ale
prijme se GET....
context switch do apache
a nerekl jsem ze je skoda ze ma linux ovladace a fs... pouze mi to prijed zbytecne a taky bych rekl ze se muze stat ze se nevyvyne treba vfs protoze se nikomu nechce prepisovat vsecky fs aby to pouzivaly atd.
ad hnusnost kodu - zkousel jsem opsat neco z alsy a koukal jsem na driver ide. oboje je dost silene zmatene dle meho nazoru. ve freebsd mam api z driveru ven realizovano pomoci open/close/ioctl/read/write a z driveru na hw pomoci busdma. v linuxu jsem nasel asi tak tisic neokomentovanych funkci ktere "neco" delaly a delaly to bud podobne nebo stejne a nikde nebylo jasne co se kdy vola. aspon mne teda ne. to, ze je ten kod zamoreny #ifdef linus_in_a_bad_mood a zakomentovanym kodem a ruznymy wrappery typu foo(..) {foo1(..);} foo1(..) {foo2(..)} o tom ani nemluve. mimochodem, freebsd ma popsany styl psani kodu, ma linux neco takoveho? (tim nemyslim indentaci a kde jsou zavorky)
dale mi prijde divne ze syscally jsou per-arch. a tusim taky VM je dost MD. urcite je plno veci pouze mym zvykem na bsd styl psani ale faktem zustava ze kdykoliv jsem neco potreboval najit v bsd (libovolnem) tak se mi to hledalo DALEKO lepe nez v linuxu (pamatuju si na syscall read, ktery je v adresari filesystems/ nebo tak...) -
M:N threading je opravdu teoreticky lepší, ale v praxi ho nikdo nedokázal implementovat tak, aby nebyl výrazně složitější než 1:1 threading. Na systémech, jako je třeba starý Solaris, které mají kernelové context-switche ukrutně pomalé, samozřejmě M:N threading pomůže; pokud jsou ale kernelové switche rychlé, nemá jak pomoci, pouze může uškodit.
Ad accept filtry: hezký trik, ale pomůže doopravdy? Například u HTTP GETu je pravděpodobnost toho, že přijde "GE" jedním packetem a "T" až dalším, efektivně nulová. Navíc pokud je server pod zátěží, většinou má context-switch na proces, který se stará právě o toto spojení, trochu opozdí a mezitím request stihne dorazit celý.
Souhlasím, že linuxový IDE driver je složitý a nepřehledný a místy ošklivý, jenže alespoň polovina té ošklivosti tkví v hardwaru, se kterým se musí bavit. Tolikeré obcházení hw bugů se hned tak někde nevidí. Navíc IDE driver není jeden driver, ale spousta driverů na různé IDE controllery. Když se podíváte na driver jednoduchého zařízení, opravdu bude jednoduchý a pěkný. Popisujete-li ošklivé wrappery a spol., věřím vám, že někde se asi skrývat budou, ale přesto prosím o konkrétní příklad.
Formální definice stylu psaní kódu asi neexistuje, vzhledem k rozlehlosti jádra je asi i rozumné, když jsou některé zvyklosti lokální pro subsystém.
Syscally jsou per-arch úmyslně (respektive tabulky syscallů jsou per-arch a občas v nich je nějaký syscall specifický pro danou architekturu), umožňuje to například nezatěžovat se na nových architekturách syscally, které existují pouze z důvodů zpětně kompatibility, nebo optimalizovat číslování syscallů, aby se tabulka lépe cacheovala (opravdu to dává měřitelné zrychlení). VM je skoro celý generický.
(Když už jsme u toho readu, on je opravdu v adresáři fs a má tam být, protože je součástí obecného filesystemového interfacu, jehož místem tento adresář je; jednotlivé filesystémy jsou až v podadresářích)
-
neologism (neregistrovaný)M:N threading ma taky vyhodu v tom ze se usetri prostredky kernelu, pac se pro kazdy thread nemusi obetovat cela struktura thread/proc ale jen pro mnozinu M threadu. coz asi nema moc smysl pri 5ti threadech v pustenem firefoxu ale pri desitkach tisic threadu zde rozdil asi bude.
no.. ten GET nevypada jen tak ze by to byly 3 bajtiky :) proste se pocka az se to prijme cele, navic nejsou accept filtry jen na http, to byl priklad. a nevidel jsem benchmark ale verim ze to neskodi
co se tyce ide - mrkni na fbsd na sys/dev/ata... podporuje to +/- ten samy hardware ale je to neporovnatelne hezci
cachovani tabulky syscallu? tyve.. tak to sem fakt nezral :) tady je asi videt rozdil mezi vyvojem bsd a linuxu. neverim ze by nekoho z vyvojaru jakehokoliv bsd napadlo resit cachovani tabulky syscallu. je to proste prilis velka... nevim jak to nazvat :) linuxaci tohle resi. naopak neresi zase jine veci.
ad read: copak se read da volat jen na soubory na fs? co treba sockety atd. ? to umisteni tam mi prijde nelogicke -
neologism (neregistrovaný)ide v 4.x mi prislo pomerne dost stejne jako dal.. (a to se povazuju za docela "odbornika" na ata kod v fbsd). sos je konzervativni clovek a nenecha si do toho kodu srat...
dalsi vec kterou na fbsd miluju je to ze clovek sedne k irc a zacne resit veci s vyvojari problem a za chvili je to hotove. v linuxu jsem se snazil protlacit jeden patch a neuspel jsem...
p.s. ale tohle pisu dost ozralej takze... :) -
Pokud má program spousty threadů, budou stejně spotřebě paměti vévodit jejich zásobníky, nějaká kernelová struktura navíc nebo namíň se nepozná. (Mimo to, program používající 10000 threadů bude stejně ukrutně neefektivní, takže je to v zásadě jedno.)
Ad IDE: mrknu se. Ale když jsem se před pár lety mrkal naposledy, vypadalo to, že právě těch podivnějších (ale bohuže občas se vyskytujících) řadičů, které potřebují hromadu mírně řečeno nestandardního zacházení, uměl Linux daleko víc.
(Jinak souhlasím s tím, že by si Linuxové IDE drivery zasloužily přepsat -- po letech inkrementálního vývoje do takového stadia dojde každý program --, ale to už se konec konců děje.)
Ad read: inu, ony i ty sockety žijí v nějakém (virtuálním) filesystému. Opravdu to je logické, byť možná jiným způsobem, než byste napoprvé čekal.
Stejně je dobře, že se Linux i FreeBSD stále vyvíjejí paralelně a občas se snaží předhánět se :) Vždy si přitom vzpomenu na jeden den před asi tak šesti lety, kdy do mailing-listu linux-net přišel mail od tehdy ještě téměř neznámého Alexeje Kuzněcova s textem (velmi volně): "Hrál jsem si s FreeBSD a všiml jsem si, že na mém stroji routuje 3x rychleji. Tak jsem Linuxový routing trochu předělal a 10x ho zrychlil." :) -
neologism (neregistrovaný)nemyslim si ze program ktery pouyziva 10000 threadu musi byt ukrutne neefektivni rekl bych ze je to o paradigma - proc nemit "skoro kazdou funkci v threadu" ? tj. blbustku ktera mi toci kurzorem atd. tj. trivialni funkce a tam bych rekl ze ty kernelove struktury budou znat. rozhodne bych ale urcite nevykrikoval neco o tom ze "150 threadu bude stacit navzdy" :))
ad ide - jasne, linux podporuje vic hnusneho hw, ale ten kod je dost sileny. fakt se na ten fbsd kod mrkni, je to radost pohledet :) nevim, porad se nemuzu zbavit toho ze mi bsd kod prijde psany daleko hezceji. hezci nazvy typu, hezci struktura kodu atd. atd. atd.
ad read: mne to logicke neprijde a dost pochybuju ze nekomu pri prvnim setkani ano. freebsd ma syscall read v sys/kern/sys_generic.c, ale uznavam ze je to o zvyku/nomenklature.
a neni pochyb o tom ze je fajn ze existuje vic OS a navzajem se popohaneji. o tom snad netreba ani debatovat. osobne planuju z linux prepsat nekolik veci na fbsd (jen co bude cas ;) ) a linux by se taky mohl dost od fbsd naucit. faktem rozhodne ale zustava ze na bsd leti holky daleko vic nez na linux a proto u nej zustavam :) -
hx (neregistrovaný)http://bulk.fefe.de/scalability/
http://geri.cc.fer.hr/~ivoras/web2/papers/osbench.html
http://www.opensolaris.org/os/article/2005-10-14_a_comparison_of_solaris__linux__and_freebsd_kernels/
http://software.newsforge.com/software/04/12/27/1243207.shtml
http://os.t1.cz/
Pokud by nekdo vedel jeste o dalsich benchmarcich, zejmena mezi FeeBSD 6.0 a kernelem 2.6, byl bych mu vdecny. -
Pavel Píša (neregistrovaný)Dobrý den, kategorické prohlášení autora mi připadá neseriózní
a poněkud poškozuje jinak celkem zajímavý článek.
Je pravda, že s FreeBSD praktické zkušenosti nemám, ale četl
jsem si více dokumentace, zdrojáků a srovnání řešení různých mechanizmů
na úrovni jádra (Linux, NT, BSD, L4, HURD) a obecně FreeBSD řešení jsou
většinou velmi konzervativní. To je sice dobře co se týče stability. Linux dělá
i pro FreeBSD určitou práci průkopníka a používá někde odvážnější
řešení. Je nutné si ale uvědomit, že některá tato řešení posouvají
i kvalitu systému obrovsky dopředu. Nedíval jsem se na poslední
snapshoty FreeBSD. Ale jsem přesvědčen, že i tato verze má k úrovni
následujících řešení Linuxu velmi daleko: FUTEX (mutex s nulovým
kernel overheadem pro případ, že není kolize mezi thready při přístupu
k mutexu), princip RCU updatu struktur v jádře (umožňuje téměř lineární
růst výkonu pro systému s velkým množstvím CPU), připravovaný fully-preemptive
kernel, který Linuxu umožní konečně zasáhnout i do oblasti hard real-lime
systémů (RT nadstavby zde nepočítám a HRT myslím garantované odezvy
pod 1 ms), atd. U SGI a IBM asi nejsou diletanti, když pro systémy s 1024
CPU raději používají Linux než BSD. Přitom BSD licence by jim umožnila
lépe své nápady skrývat a prodávat je jako binary only řešení. A oni
raději ztrácejí hromadu času na to, aby podporu svých platforem a svá
vylepšení směli dát/byla akceptována do mainline Linuxového jádra.
Linux má trochu potíž vtom, že překotný pokrok v mechanizmech jádra
vede k překrývání starších a novějších zvyklostí a někdy to způsobuje
vznik nekvalitního kódu a zmatků. Ale celek jde nezadržitelně dopředu.
Takže původní prohlášení jako bezděčný výkřik FreeBSD nadšence
je omluvitelný, stejně jako podobný výkřik Linuxového nadšence,
ale jiné názory nepřipouštějící obhajoba výroku je hloupá a nekompetentní. -
hx (neregistrovaný)Vyrok jako takovy je pravdivy, ale ukazuje na to, ze spousta lidi jen prejima nazory, aniz by si udelalala vlastni. A on to je problem. Benchmarku zas tak tolik neni. A ani z benchmarku se nedaji odvodit ostatni dulezite vlastnosti, jako stabilita, apod. Takze to nejjednosussi je sirir polopravdy.
Kategoricky vyrok, ze je MNOHEM lepsi neni (asi i z principu) pravdivy. Lze se donekonecna hadat nad nekterymi vyhodami toho ci onoho.
At si kazdy pouziva co chce, ale prosim nedelejte falesnou reklamu FreeBSD (i kdyz takto neprimo).
P.S.: Asi by me to melo byt jedno, ale neznam clanek o FreeBSD, kde by si jeho autor/uzivatel nezahojil svoje ego na Linuxu a nejhorsi je to, ze to po nem papouskujou masy neznalych ctenaru. Kdyz se jich pak clovek zepta v cem je BSD lepsi, tak vlastne nevedi, ale pravda to musi byt, protoze to je obecne znamy fakt mezi "odborniky". -
ToM (neregistrovaný)U SGI a IBM mozna diletanti nejsou (mozna jsou), ale tezko lze predpokladat, ze rozhodnuti nasadit Linux a nikoli BSD udelali jejich vyvojari. To muzu take argumentovat tim, ze komercne neuspesnejsi unixovy desktop OS je postaveny na FreeBSD.
Co se tyce toho prukopnictvi, tak ta sluzba je, rekl bych, oboustranna. A mozna vic nez z Linuxu se inspiruje FreeBSD spis z ostatnich *BSD.
Ty nove vlastnosti v Linux vypadaji sice zajimave, ale prave ta nekolikaleta zkusenost mi dava vetsi duveru v nove vlastnosti FreeBSD nez v nove vlastnosti Linuxu, co se stability tyka. Bohuzel je to tak, protoze Linux jsem nucen pouzivat (stejne jako Windows jsem nucen pouzivat). Pak je jeste otazka kdy tyto vlastnosti prijdou do SLES a RHEL. Protoze do te doby je mlaskani nad temito vlastnostmi pouze divanim se do zrcadla a pochvalovanim sama sebe jak jsem hezkej. -
Ondřej Tůma (neregistrovaný)Rozdil mezi FreeBSD a Linuxem jako jadrem je jedna vec, ta uz byla rozebirana davno - z veci ktere se me osobne libi, je propracovanejsi chroot, i kdyz selinux patch by to mel resit taky a k bsd obdobe by mel linucha hoooodne priblizit - nemohu ani potvrdit ani vyvratit jeste sem nezkousel.
Co se kompilace jadra tyce, pravda je ze sem se v linuxconfigu krapet ztratil, tech voleb tam na me bylo moc, ale to uz je taky historie;)
Vydesila me ale distribuce jako takova !?!?
1) FreeBSD ma glibc port taky, akorat se vse snazi portovat a kompilovat bez jeho podpory (zcela logicky, bo by to melo byt rychlejsi a asi i je ;)
2) FreeBSD stejne ma absolutne uuuuzasnej init system, zadne slozite scripty co volaji scripty - proste jeden kofigurak a tri sripty ktere se nemeni ;)
3) FreeBSD maji uzasne porty, ktere prevzali z NetBSD. Tento balickovaci system je neprekonatelny, vcetne upgradovaciho scriptu. Ostatni balickovaci system si brali priklad prave z techto portu. A nektere implementace me prijdou nedodelane. Proto vzit uzasnou BSD distribuci a nacpat na ni nechutnosti ktere sebou nesou nektere distribuce linuxu, me pride jako przneni dobreho systemu jako celku. -
hx (neregistrovaný)Pokud odhlednu od kvalit jader, apod. a zamerim se jen na spravu (balickovaci system, init scripty, ...), tak je pro me jasny vitez Debian. Pomerem jsem chtel naznacit miru slozitosti spravy; konkretne bych to ohodnotil 100:10 ve prospech Debianu.
Duvody:
- pro spravu jsou binarni balicky lepsi
- bugy jsou resene backporty ne novou verzi
- bezpecnost neni ponechana na autorovi, ale na bezpecnostnim tymu distribuce
- intitscripty na Debianu jsou lepsi protoze:
- jsou prehlednejsi (to mozna uz neplati, mam nejasny dojem ze to u FreeBSD od verze 5.x zmenily)
- teoreticky odolnejsi proti chybe
- lepe prizpusobeny pro praci se scripty (balickovacim systemem)
- pomalejsi boot (coz by mohla byt nevyhoda) nevadi -
ToM (neregistrovaný)Pro nas dva to sice nema vyznam, ale pro ty ostatni, kteri treba nevedi, budu reagovat:
> - pro spravu jsou binarni balicky lepsi
Souhlasim. Doplnim jen "vetsinou lepsi". Na FreeBSD pouzivam take binarni balicky, pokud to jde. Nekdy ale vyzaduju urcite vlastnosti, ktere dostanu pouze custom. kompilaci daneho SW.
> - bugy jsou resene backporty ne novou verzi
Takhle to na FreeBSD fungovalo jeste pred tim, nez mel Debian apt.
> - bezpecnost neni ponechana na autorovi, ale na bezpecnostnim tymu distribuce
Stejne jako ve FreeBSD. A opet to bylo driv na FreeBSD.
> - intitscripty na Debianu jsou lepsi protoze:
> - jsou prehlednejsi (to mozna uz neplati, mam nejasny dojem ze to u FreeBSD od verze 5.x zmenily)
Tohle povazuji opravdu za subjektivni parametr. Vzdy se mi libil startovaci proces BSD vic nez SVR4, i kdyz jsem to uplne jednoznacne nevidel. FBSD5 prislo s necim "mezi".
> - teoreticky odolnejsi proti chybe
Ve srovnani s FreeBSD ani nahodou odolnejsi! Naopak.
> - lepe prizpusobeny pro praci se scripty (balickovacim systemem)
Nesouhlasim. V tomto jsou oba systemy rovnocenne. -
anonymníBinarni balicky:
Pokud nemusim modifikovat, tak to je jasna deviza binarnich balicku. Problem je, ze src balicky sice modifikuju, ale tim rozbiju dependence. Ale ano, vpodstate jste to vystihl.
Bezpecnost, bugy:
Hmm, tuto informaci jsem mel od treti osoby ... takze muzete mit pravdu.
Initscripty:
Robustnosti jsem myslel to, ze v pripade BSD initu se musi modifikovat script pro startovani runlevelu, coz dle meho nazoru zvysuje pravdepodobnost zaneseni chyby, takze dany runlevel nenusi ani nejet (hlavne, kdyz to delam rucne).
Ohledene prizpusobeni - mel jsem namysli jen to, ze je pro script jednodussi vytvorit symlink nez modifikovat script.
Zpusob, jakym se to resi FBSD >= v5.x se me libi mnohem vice nez predtim. Naprosto nechutne je pripad, ktery jsem videl kdysi na Slackwaru, kde nastaveni networkingu, startovani sluzeb, apod. se bastlilo (nebo jeste bastli) primo do daneho init scriptu.
ČLÁNKY DO MAILU