Názory k článku Porovnání systémů Linux a FreeBSD (2)
-
Mikulas Patocka (neregistrovaný)
FreeBSD 5 ma stale cely filesystem, virtualni pamet a sit pod big kernel lockem (jako Linux 2.2). Bez locku tam bezi ovladace. Asi se neda predpokladat, ze to ted zacnou prepisovat, bugu tam maji dost a nechteji nove udelat, spise by radi existujici bugy odstranili a vydali stabilnejsi 5.2.
-
jamalajka (neregistrovaný)
qnx je neco uplne jineho, protoze je to mikrokernel.
v podstate se jedna o to, ze kernel tama dela jen predavani zprav mezi procesy a zpravu pameti, jinak veskere ostatni veci bezi bud v userspacu, nebo v "privilegovanem user spacu" (povoleny nektere instrukce procaku, napr. ovladace a pod, ktere potrebuji primo lizt k HW atd.); vyhoda je, ze pokud si clovek napise nejake watchdogy, mohou tyto bez problemu restartovad ovladac, ktery se dostal do "nestabilniho stavu", nebo ktere crashly.
jelikoz samotny kernel obstarava jen tak malo, neni prakticka potreba ho nejak extra zamykat a jelikoz vsechny ostatni veci jako napr. sitovy subsystem, fs atd. bezi jako oddelene procesy (klidne i threadovane), neni tam se smp zadny takovyhle problem. da se tam zapnout jak roun-robin, tak i realtimove (tj jakmile je proces vyssi urovne mozne naschedulovat, nizsi procesy nemaji sanci, tu dostanou, az kdyz procesy s vyssi urovni dobehnou, nebo cekaji) casovani (prepinani procesu). tot hlavni rozdily, daleko vic toho najdete na QNX.COM a dokonce si muzete sosnout i testovaci verzi ... -
Ladislav Michl (neregistrovaný)
Díky za článek, já si snad stáhnu cvs FreeBSD :-)
Jen pár detailů - třeba se budou někomu hodit:
"Když je jádro zkompilováno pro jednoprocesorový systém, spinlocky jsou prázdné struktury..."
by mělo být (níže v článku je to ostatně dovysvětleno)
'Když je jádro zkompilováno pro jednoprocesorový systém bez preemptivního přepínání procesů, spinlocky...'
"Zakázání přerušení pomocí cli a sti se v Linuxu už téměř nepoužívá." - možná by stálo za zmínku, že se vývojáři snaží všechna použití odstranit, viz. Documentation/cli-sti-removal.txt -
Pavel Tisnovsky (neregistrovaný)
A ta instrukce lock zakáže přístup na sběrnici i ostatním procesorům? No, je pravda, že na něco podobného se používala v dobách 386+387 na jejich spolupráci, ale není to zbytečně pomalé, zejména u většího množství procesorů?
No, já vím, že první blbost bylo dávat ty procesory na jednu sběrnici, pro masivně paralelní počítače se opravdu Intel/AMD/... s jejich "mikroprocesorovocentrickou" architekturou nehodí. -
Mikuláš Patočka (neregistrovaný)
Pokud tam ten lock nedáte, tak nastane problém popisovaný v článku --- intrukce decb se ve skutečnosti uvnitř procesoru rozloží na tři samostatně vykonávané operace --- přečtení čísla, odečtení 1 a zapsání čísla. Pokud dva procesory současně provedou přečtení, zmenšení i zapsání, tak se výsledek zmenší o 1, i když by se měl zmenšit o 2.
Prefix lock (od Pentia Pro) nutně neznamená, že procesor zamyká sběrnici --- pokud je obsah paměti v cachové řádce ve stavu "Exclusive" nebo "Modified", tak se operace provede pouze v cachi a prefix způsobí, že po dobu vykonávání intrukce procesor nepustí svoji cachovou řádku.
Tento prefix lock má jiný problém --- procesor při něm vyprázdní celou instrukční pipelinu --- proto instrukce s ním trvají dlouho --- 20 tiků na Pentiu 2/3, 112 tiků na Pentiu 4. -
Pavel Tišnovský (neregistrovaný)
No právě, z důvodu přístupu více procesorů se dá použít například mnou zmiňovaná instrukce cmpxchg (porovnání a prohození obsahu registru a paměti). Ono je v případě této instrukce jedno, jak se v procesoru rozloží, důležité jsou přece přístupy k paměti. Musíte buď nějak synchronizovat přístupy R-R (ten vlastně ne, že), R-W, W-R a W-W, nebo použít atomické instrukce.
-
Jan (neregistrovaný)
Ale ne. Obe instrukce potrebuji lock a obe se daji pouzit uplne stejne. Vyhoda cmpxchg spociva v tom, ze umoznuje atomickou instrukci spinlock ovlivnit i precist. V pripade instrukce decb se pouze nastavi hodnoty FLAGS, takze se da jedine poznat kdy hodnota v spinlocku klesla na nulu. Coz v tomto pripade staci, takze nema smysl spinit kernel instrukci, ktera je k dispozici az od i486.
Viz problemy s InterlockedIncrement() na WinNT 3.51. -
lnx_bfu (neregistrovaný)
v nekterych vecech se s vami shoduji, ale v nekterych zase ne.
u tech vyvojaru je to pravda a vseobecne. neplati to jenom u vyvojaru, ale taky treba u sitariny, atd atd. proto nemam rad manazery a proto ani nevim, na jakou VS mam jit. vsude je to manazersky zamereny a to neci.
s tema vyrobkama ... mno, nevim. napr. jsem si vybral bundu za 4k protoze je z kvalitniho materialu a protoze doufam, ze nejaky ten patek vydrzi. rozhodne to nebylo proto, ze ji udelala tahle a tahle firma, nebo ze jsem ji tamhle videl venku. mate asi pravdu v tom, ze mnozi lide tak jednaji(hlavne ti mladsi, kde je to asi 1)kamos 2)cena a uz nevim co bylo dal). ted se mi nejako prerusil tok myslenek, tak zas budu zticha.
jeste jsem nekde zahledl, ze nejake firmy ve strojirenstvi potrebuji programy pro vyrobu rychle. na to maji odborniky; SW se da updatovat; s tou rychlosti bych neprehanel, protoze je tu take nastrojarna, kde se nejdrive museji vyrobit nastroje :)
tot uz radsi vse, kdyby v tom byly chybky, tak se omlouvam :(
btw: sef projektu je skoro magager, takze bych moc nespolehal na to, ze vyvojare podrzi. navic jak bylo jiz zmineno. pokud udelate kvalitni vyrobek(at uz nerozbitnou sklenicku, nebo dokonaly SW bez chyb), tak jiz neni neni potreba ve vyrobe pokracovat. -
Psonek (neregistrovaný)
Kdyz jsem si cetl tenhle clanek, tak jsem nabyl dojmu, ze o programovani a Linuxu toho fakt moc nevim. Zajimalo by me ale, jestli clovek, ktery ma takove znalosti jako autor clanku, ma v praxi dobre uplatneni nebo uz firmy maji zajem jenom o lidi na programovani "klikacich" aplikaci.
-
Johanka (neregistrovaný)
Mam pocit, ze kdyby clovek jako Mikulas prisel nekam do firmy ci nedejboze do personalni agentury, tak se vsichni vydesi jeho zanedbaneho zjevu typickeho kerneloveho vyvojare a na znalosti ani nedojde :)
Ale vazne :) Pokud vim, sam Mikulas dela jen postgradual a nic trvalejsiho na kseft, ale osud lidi tohohle typu je bud takovy, ze je plati treba SUSE/RedHat (supporteny treba zase vyrobcema procesoru apod.) za to, ze hackujou kernel a pisou drivery, nebo stridave pisou kernelovy/Open Source veci pro dobry jmeno a pak nejaky proprietarni libovolneho zamereni na kseft :), nicmene o uplatneni asi nemaji nouzi. -
Clock (neregistrovaný)
Nevim jestli moje uvaha bude platit i na Mikulase, ktery je v teoretickych otazkach operacnich systemu radove schopnejsi nez ja.
Ale ja mam dojem, ze clovek, kteremu jde o to, aby veci fungovaly, a prachy nejsou u nej "az na prvnim miste", tak ma celkem problem. Firmy chteji akorat vydelat prachy a ten zbytek je balast. Proto vznika kolize mezi dynamickym manazerem v bilem/modrem limecku a vyvojarem. Dynamicky manazer rekne ze se to musi udelat tak protoze je to z marketingoveho hlediska optimalni a vyvojar rekne ze to tak neudela protoze je to blbe. Nacez vyvojar leti, protoze vyvojar, ktery dela veci dobre, neni pro firmu perspektivni.
Vydelavat se da totiz pouze na vecech, ktere funguji mizerne. Kdyz neco chodi dobre, uzivatele nemaji duvod si koupit dalsi verzi v naivni iluzi, ze ta na rozdil od tech predchozi bude fungovat. A tak firma prijde o kseft.
Rozhlednete se kolem sebe. Podivejte se, jak funkcni jsou vyrobky bezne spotrebni elektroniky, jak funkcni jsou komercni operacni systemy, jak funkcni jsou softwarove aplikace, mikroprocesory, motherboardy, graficke karty, pameti. Me prijde ze odpoved na tyhle otazky je jednoznacne "spatne". A technologicke moznosti na to dle meho nazoru jsou - stacilo by vzdycky, aby se to dotahlo az uplne dokonce a nenechavaly se tam chyby.
Pokud vyvojar nechce byt v takovemto koliznim pripade vyhozen, musi se podrobit, a pak se uz z nej stane spatny vyvojar. Vyvojar, ktery vedome dela veci, o kterych vi, ze nebudou fungovat, je dle meho nazoru spatny vyvojar.
Preju Mikulasovi, aby se do takovehle kolizni situace nedostal, a kdyz uz se do ni dostane, aby si nevybral tu posledne zminenou moznost. -
Mikuláš Patočka (neregistrovaný)
Třeba vývojáři Unixu řekli, že se jim systém vyvíjel velmi dobře proto, že nemuseli nikdy splňovat ničí požadavky.
Manažera nezajímá, co se systémem bude za 15 let, manažera zajímá, co se systémem bude za 2 roky, proto je přístup managementu jiný.
Když do systému dáme nějakou "cool feature", tak ho sice z dlouhodobého hlediska zprzníme (ta featura stejně nebude potřeba a bude ji třeba podporovat v každé nové verzi, čímž se údržba stane složitější), ale krátkodobě to přinese zisk. -
Michal Kara (neregistrovaný)
No, priznejme si, ona ta nekvalita je hlavne v tom, ze uzivatele _chteji_ nekvalitni vyrobky (mluvim obecne, ne jenom o SW). Kdyz se uzivatel rozhoduje co koupit, rozhoduje se podle dvou kriterii: 1) Kvalita, 2) Cena (3) Ma to kamos). Problem je v tom, ze bezny clovek (neodbornik v danem oboru) neni schopen poradne poznat/porovnat kvalitu vyrobku a je v tomto ohledu vice ci mene ovlivnen marketingem. Zato cenu dokaze porovnat kazdy, kdo ma alespon par trid zakladni skoly :-)
Proto se lide/uzivatele rozhoduji pro levne a tudiz nekvalitni vyrobky. Protoze vidi nizkou cenu a jelikoz tomu nerozumi, nechaji se o kvalite presvedcit. Proto je take potreba, aby vyrobky (i SW) mely hlavne ty veci, ktere se daji i laikovi jednoduse prezentovat jako kvalita/vyhoda (bez ohledu na jejich skutecnou kvalitu).
Ne ze bych z toho byl nejak nadseny, ale je to podle mne popis toho, jakt o funguje :-) -
Mikuláš Patočka (neregistrovaný)
Ani bych neřek, že se uživatelé rozhodují podle ceny. Naopak mnohdy lidi schválně kupují drahé výrobky a myslí si, že budou kvalitnější (třeba značkové oblečení).
Lidé používají výrobky podle toho, jaký dojem to na ně udělá. I když Linux dokáže vykonávat kancelářské potřeby stejně jako Winwows, většina lidí či firem si radši zaplatí za Windows, protože prostě Linux nemá ten správný image, který by je lákal. Ti, co používají Linux ho prostě používají proto, že chtějí být "cool-anti-microsoft" a nezvažují jiné variany (BSD), protože se o nich tolik nemluví. Zase existují fanatici, kteří vyznávají BSD prostě proto, že je to "pravý Unix" --- a tak. -
Michal Kara (neregistrovaný)
> Ani bych neřek, že se uživatelé rozhodují podle
> ceny. Naopak mnohdy lidi schválně kupují drahé
> výrobky a myslí si, že budou kvalitnější (třeba
> značkové oblečení).
Ale to je presne ono! Taky se rozhoduji podle ceny, sam jsi to rekl :-)) Jen chteji kvalitu, kterou neumi posoudit, takze se rozhoduji stylem "kdyz je to drahe, musi to byt kvalitni".
Pak samozrejme existuji skupiny "fanatiku" - (Windowsari, Linuxari, Skodovaci, Anti-skodovaci, ...). Ale tam je to o necem trochu jinem, Ti se o danou problematiku alespon zajimaji a obcas o ni treba i neco vedi :-) -
JoHnY (neregistrovaný)
a pak je este mala skupina pragmatiku (nikdo neni pragmatik ve vsem) a tem sice trva mesic nez se rozhodnou co koupit, ale kdyz to kupujou vedej co.
Ja jsem treba typickej pragmatik pres HW a nekdy i SW. Proste radci prectu 30 recenzi MB na 50serverech nez abych si koupil kram.
PS:vite proc pouzivam Widle? jsou pro me pohodlnejsi - a vite proc pouzivam i linux? widle jsou pohodlny, ale jen kdyz maj dobrou naladu, to linux je furt stejne skoropohodlnej ;-)))) -
Ladislav Michl (neregistrovaný)
asi je třeba si uvědomit, že OS především hostí aplikace, které zpracovávají informace (teď nechám stranou řízení CNC strojů nebo železniční dopravy) a protože informaci ještě nikdo neposnídal ani jej v zimě nezahřála, je třeba brát toto odvětví (IT) jako podružné/pomocné. ke "zbytku" je asi v podobném vztahu, jako kdysi prazáklad strojírenství k zemědělství - alias dej mi pluh a já ti dám část obilí (no dobře, dej mi meč a přinesu ti zisk nepřítele ;-)). čili šlo by to i bez IT, ale cesta zpět není. můžeme se samozřejmě přít o to, jaká by byla efektivnost výroby bez použití výpočetní techniky, ale to není tak důležité. pro firmy jako takové, je třeba, aby funkce, které od programu očekávají, byly k dispozici hned nebo aspoň brzy - vždyť je to jen pomůcka a její nákup snižuje zisk. a uživatele taky vůbec nezajímá, jak kód vypadá uvnitř a jak se bude dále udržovat. vítejte v instatním světě :-)
tak, teď očekávám spousty (proti)názorů neboť v takto obecné rovině se dokáže projevit každý, kdo nemá co říct "k věci" ;-)
omlouvám se za OT. myslím si, že by nám neškodilo více smyslu pro svět vně spinlocků, VM a scheduleru. podívejte se, jak je venku krásně a nemyslete na to! vždyť je to jen pár řádek kódu o který třeba za pár let nebude nikdo stát. -
hyperion (neregistrovaný)
No, myslim ze bych to takto neprehanel..vyvojar se zpravidla s managorem nemusi vubec bavit a nebyva ani jeho primym podrizenym. Sef oddeleni/vedouci projektu pak spise byva osoba, ktera to musi hrat na dve strany. Jednak dobre vyjit s managorem (splnit termin) a s vyvojarem (neudelat ze sebe hajzla). Hlavnim ukolem IT je primarne pro nekoho udelat sluzbu za uplatu, rici ze je chyba na jedne nebo druhe strane je dost odvazne. Spise bych se ale priklanel k vam, situace kdy nekolik hracu drzi trumfy a ostatni nepusti k banku neni nikdy moc dobra. Zahrat si ale muzete vzdycky..Tak to v IT chodi, vitez bere vse..a "spatny" vyvojar?:) mno. treba ma doma dve maly deti, manzelku na matersky a hrdina je pro ne. moc si to CVUTaci malujete. Budte vy ti, kdo to dotahne do konce..a delejte "dobre" vyvojare. Budete mit cistou karmu a ja vam budu fandit.
-
peto (neregistrovaný)
Neviem, preco ale musim to posielat druhy raz, lebo to akosi nepreslo.
Neviem ci tu niekto robi s RT Linux-om - je aj v GNU-GPL tzv. Open verzii od Finite State Machine Labs
http://www.fsmlabs.com/products/openrtlinux/
tam sa patchne kernel tak aby mohol bezat ako idle proces RT executive a teda musi byt- odozva RT - nebeziacich pod Linux kernel-om -taskov do 10 nm - a je aj vo verzii pre BSD. RT programy bezia z pohladu Linux-u ako kernel module. Odtail sa da poucit a hlavne z toho patch-u Linux ci BSD kernel-u. funguje to dobre len dost casto treba robit sync, lebo moduly su moduly a aj tak sa obcas pocas vyvoja nevyhneme HW reste-u a fsck pri boot-e. No ak aplikacie nemachyby tak to ide. Dalsia podarene diplomovka (Linux je diplomovka Linus-a Torvalds-a) tentora je autorom Michail Barbanov -
Johanka (neregistrovaný)
Ahoj, ne vazne jsem to cetla, dokonce dvakrat, nejdriv jako diplomku.
A cachí mi prijde daleko lepsi nez keší, u toho padam ze zidle zase ja (a pokud se to nesklonuje a vsude se pise cache, tak se to zas blbe cte, protoze si clovek tu neexistujici morfologii musi domyslet z kontextu). A inoda je skoro tak puvabna jako CVSka ;)
Kazdy mame jiny vkus na veci, pro ktere zatim neni zadna kodifikace. -
Clock (neregistrovaný)
"Chyby v SMP zamykani vpodstate vubec debuggovat nejdou a nezbyva nez si cely kod precist a ujistovat se, ze je zamykani spravne."
Tento priklad demonstruje, ze v dnesni dobe bezne pouzivany vyvojovy cyklus "napis program - zkus jestli funguje - oprav nalezene chyby - zkus ho znovu - uvolni ho" je fundamentalne spatne. Zde se konecne ukazuje, ze psani BugFree(TM) kodu, neboli ze si po sobe kod peclive precteme a popremyslime, jestli je spravne (pripadne to nahradime nejaky strojovym popremyslenim), je jediny univerzalni nastroj, jak dosahnout semanticke spravnosti programu. -
Zdenek (neregistrovaný)
Jenom par poznamek:
- kdyz uz Mikulas pise, ze makra expanduji na "nejake jednoduche atomicke instrukce", je dobre je uvest, ne kazdy si to umi nebo chce dohledat v kernel headerech.
- Problem s debugovanim SMP kodu mi neprijde SMP-specificky, vzdyt u MT aplikaci v userspacu je to stejne, a i "klasicke" unixove procesy kdyz zhusta pouzivaji standardni IPC primitiva jsou obtizne debugovatelne.
- Kdyz kod zacne vypadat tak, ze se velmi casto na relativne mnoho instrukci zakazuje preempce, a obcas na chvilku povoluje, je dobre system zamykani "otocit", jak to delaji nektere riscovske procaky. Tim ze misto dvou istrukci "zakaz/povol" bude jen jedna instrukce "ted muzes", usetrime pri srovnatelnych latencich polovinu synchronizacniho kodu.. To je taky duvod proc se mi pristup s low latency patchema libi vic nez preemptivni jadro. -
hkmaly (neregistrovaný)
- Ono to je na kazdem procesoru jine. A tim myslim ze je to jine napr. na 386 a na 486 ...
- Tenhle problem se objevi kdykoliv mas preemptivne nebo vice paralelni procesy.
- Neni mi jasne jak jsi to myslel s tim otocenim, ale take preferuju low-latency pred preemtivnim jadrem. -
david (neregistrovaný)
Nejen teoreticky. Před mnoha lety (cca 1992) jsem takový systém viděl. Výkonné CPU pro programy, Rychlý I/O procesor k diskům, Pomalý I/O procesor pro obsluhu terminálu.
Myslím, že IBM má v mainfraimech také něco podobného, kdo z Vás si vzpomene na desku do AS/400 s i386 procesorem a Novel Netware. -
Jozef Vondrák (neregistrovaný)
Ahoj, tak jsem se chtěl zeptat, jak je na tom rozhraní pro binární kompatibilitu jader. Mám na mysli, že modul zkompilovaný pro jádro ve verzi třeba X.Y.Z bude funkční a nepadavý také pod verzí X.Y.(Z+n). Pokud si dobře pamatuju, tak Linusovi se to nelíbilo, že to bude omezovat rozvoj nových funkcí jádra, ale nakonec nebyl proti. Dost se o tom mluvilo tak dva roky dozadu a od té doby jsem o tom neslyšel.
-
Jozef Vondrák (neregistrovaný)
Ahoj, tak jsem se chtěl zeptat, jak je na tom rozhraní pro binární kompatibilitu jader. Mám na mysli, že modul zkompilovaný pro jádro ve verzi třeba X.Y.Z bude funkční a nepadavý také pod verzí X.Y.(Z+n). Pokud si dobře pamatuju, tak Linusovi se to nelíbilo, že to bude omezovat rozvoj nových funkcí jádra, ale nakonec nebyl proti. Dost se o tom mluvilo tak dva roky dozadu a od té doby jsem o tom neslyšel. PePa
-
Pavel Pisa (neregistrovaný)
Existuje iniciativa vytvořit univerzální model driverů (UDI) pro Unixové systémy, bohužel je v tom zainteresováno SCO, takže nevím, jestli již není tento projekt mrtvý
http://www.projectudi.org/
FSF a GNU komunita obecně nad UDI ovšem nejásá
http://www.gnu.org/philosophy/udi.html -
neologism (neregistrovaný)
SMP kod v FreeBSD 5.x je docela fajn... ted je uz skoro i networking Giant free...
nedavno byl commitnut novy ATA kod (Giant free) a spousta veci se predelava...
vyhodu v SMP na FreeBSD 5.x bych videl ale spis v KSE (M:N threading) - vim, ze linuxaci tomu neveri ale ono to JE lepsi nez 1:1 (odkazy na Solaris neberu, paac solaris bezi na sparcu, ktery ma o dost levnejsi kontext switche)
fajn clanek -
Mikuláš Patočka (neregistrovaný)
Síťování na FreeBSD 5 běží pod Giantem --- všechny interrupty (softwarové i hardwarové), které nemají nastaven příznak INTR_MPSAFE, Giant berou --- viz funkce ithread_loop a v ní místo, kde se volá ih_handler. Síťový softirq příznak INTR_MPSAFE nenastaví (je vytvořen ve funkci start_netisr), takže obslužná rutina pod Giantem poběží. Giant se bere i ve funkcích pro čtení a zápis na socketu --- soo_read a soo_write.
KSE popíšu v některém z dalších článků. -
hkmaly (neregistrovaný)
Pro normalni uzivatele (kteri nepotrebuji uptime pres rok) je nejlepsi mit nainstalovano vic OS a stridat je podle toho co ti vic vyhovuje. Osobne bych cekal ze skoncis u linuxu, protoze pod BSD nenajdes nejake aplikace, ale nepovazuju za ferove ti ho doporucit rovnou kdyz to nevim jiste.<BR>Slackware sam pouzivam, ale dneska bych zkusil SourceMage nebo Gentoo - pokud na to mas HW. Taky je dulezite jestli budes instalovat z CD nebo mas pripojeni na internet.
-
Jerry III (neregistrovaný)
Tak sem po dlouhy dobe zase zacal cist roota a neverim vlastnim ocim. Mel sem pocit ze kdyz vsichni vychvalujou jak je Linux dobrej na servery tak bude mit naprosto vymakanou podporu SMP, ale ten clanek vyzniva jako ze Linux na ostry systemu pouzivat pouze a jen se single CPU. Neumim cist anebo to je pravda? Ja v praci honim Win2k servery na minimalne 4 procesorovych masinach a firma se nas snazi natlacit na Linux, ale kdyz ma takhle mizernou a bugovou implementaci SMP tak to proste vubec nebude pripadat v uvahu...
-
Mikuláš Patočka (neregistrovaný)
Windows na tom asi nebudou o moc lépe --- třeba jsem slyšel, že ve Win2k se našlo několik míst, kde proces sebere spinlock a pak sahá na swapovatelnou paměť (to taky může vést k vytuhnutí s velmi malou pravděpodobností --- sahání na swapovatelnou paměť může způsobit zablokování a proces držící spinlock se zablokovat nesmí). Mám takový pocit, že na SMP žádný systém není dokonale funkční.
-
Jerry III (neregistrovaný)
Tak sem trochu hledal a podle Andrew Mortona 2.4 kernel zacina ztracet uz na 4 cpu :( Preci jen na nasazeni na poradny servery jeste neni zralej (2.6 by mel byt, tak pred dvema lety nebo kdy to mel puvodne vyjit), ale jak tak vidim tak BSD je na tom jeste hur... On se na rootu obcas clovek docte uzitecny informace :)
ČLÁNKY DO MAILU