Názory k článku
Linus srovnával Linux a BSD

Pro mě je zatím nejlepší Linux, protože ho kompiluju ze zdrojových textů (http://www.linuxfromscratch.org), jiné distribuce si instaluju jen pro inspiraci. Nevíte někdo o něčem podobném pro *BSD?

Pokud vim tak cele FreeBSD (a asi i ostatni *BSD, ale tam nevim) si muzes v pohode zkompilovat ze zdrojaku, ma preci jeho vehlasny system portu (kterym se inspirovala treba portage v Gentoo).

Nicmene sam mam take mnohem radsi Linux nez *BSD - kvuli hw podpore a dalsim vecem (proste mi linux pro desktop prijde mnohem lepsi a zralejsi... na serveru uz je to ale z meho pohledu vyrovnane). Take mi mnohem vic z filosofickeho hlediska vyhovuje GNU licence nez BSD licence (jsem priznivcem Free softwaru ;-))

No já jsem spíš myslel něco méně automatického... Nějaké make world je jistě pohodlné a užitečné, ale moc mi to nedá...

Sebrat kod, ponechat zminku o autorovi a za prodavat ho (ten kod, ne autora) za penize muze kdokoli i s GPL. S GPL licenci ale musi stale dodavat kod. (Verim, ze rozdil znas, ale aby to nematlo jine.)

A kód programů, který používaji GPL knihovnu, musí být také pod GPL. Někdy si řikam, jestli to neni v rozporu se svobodným software... :-(

Musim rict, ze me takovy dotaz az prekvapil...
FreeBSD ma system distribuce zdrojovych kodu pres cvsup. Kompilace systemu na miru je ve FreeBSD spise beznou zalezitosti narozdil od vetsiny linuxovych distribuci (myslim ted spis RH/FC, MDK). Nevim, co si predstavujete jako "lepsi" nebo mene automatizovane nez "make world" (ktere BTW. v dnesnim FreeBSD ani nefunguje, a vypise hlasku, ze tohle muzete pouzit pouze pokud OPRAVDU vite co delate).
FreeBSD ma pro kompilaci vlastniho jadra/systemu jednoduche ale pritom ne prehnane automatizovane nastroje. Na vsechno se pouziva make, jadro ma jednoduchy okomentovany konfiguracni soubor, ve kterem si zvolite drivery, ktere chcete zakompilovat primo do jadra (ostatni muzete nahravat jako moduly), zvolite typ procesoru, pro ktery se maji optimalizovat instrukce, identifikaci, debugovani kernelu a podobne volby. Jak moc chcete proces automatizovat zalezi na vas. Dnesni automatictejsi prikazy (napr. make kernel) stejne pouzivaji starsi zdlouhave procedury s prikazy config, make depend, make, make install atd. (uz si je ani vsechny nepamatuju), takze pokud narazite na starsi manualy, nebo proste budete chtit toto pouzit, tak muzete.
FreeBSD take umoznuje zajimave veci pro ovlivneni i prekladu uzivatelskych aplikaci. Slouzi k tomu soubor /etc/make.conf, kde muzete nastavit defaultni volby pro prekladac (ekvivalent architektury v konfiguraku kernelu), a muzete i zvolit jiny systemovy prekladac (napr. pokud mate procesor od Intelu, zkuste icc, ktere by melo zvednout vykon udajne az o 20%)

Zaverem... u FreeBSD je kompilace ze zdrojovych kodu nejprirozenejsi cestou pri sprave systemu i uzivatelskych aplikaci, a cely system je tomu tedy nalezite uzpusoben.
Priznavam, ze zadnou Linuxovou distribuci from scratch jsem nezkousel, takze neporovnavam, jen uvadim jak je to v BSDcku.

Díky, to zní zajímavě. Já jsem zatím zkoušel ze zdrojáků zkoušel kompilovat jen LFS a chtěl bych analogicky zkompilovat i BSD. Třeba ono FreeBSD, protože to jsem si jednou nainstaloval z CD a celkem se mi líbilo. Ale když jsem měl vedle toho LFS s čerstvějšími verzemi skoro všeho (glibc, gcc, x, kde), neměl jsem motivaci se v tom moc vrtat. Pokud jde o to, co si myslím, že je lepší než make world, tak pro mě to je ./configure && make && make install a (skoro vždycky, mimo holého systému LFS a pak ještě XFCE) rád si tuhle trojkombinaci naťukám bez účasti dalších nástrojů.

V tehle trojkombinaci vam samozrejme nikdo nebrani. System portu ma ale oproti tomu pomerne vyrazne vyhody. V podstate v nem mate ekvivalenty (wrapery):
make configure
make
make install
Jde ale o to, ze software instalovany pres tyto wrappery (ktere vam nijak neubiraji napr. na moznostech konfigurace, naopak ji leckdy zprijemnuji GUI nastroji, za kterymi neni nic jineho nez generovani parametru pro configure) ma pak v systemu zaregistrovane informace o zavislostech/nainstalovanych souborech apod. To vam umoznuje spoustu veci, krome "ciste" deinstalace jsou to rekurzivni upgrady a nejruznejsi testy (napr. ktery soubor patri do ktereho balicku, nebo primo adresar portu, ze ktereho bybl nainstalovan, testy, jestli je port aktualni atd.).
Moje zkusenosti jsou takove, ze pokud se muzu vyhnout klasicke trojkombinaci primo ze zdroje, tak to udelam, protoze je pro me velmi obtizne pozdeji zjistovat: co jsem vubec nainstaloval, jake konkretni soubory a kam jsem je nainstaloval, a pripadne problemy s deinstalaci (napr. make uninstall u alsa driveru mi pod linuxem vymazal cely adresar s drivery pro zvukovku vcetne nejakeho sound.ko ci co, ktery ale sam nenainstaloval a byla to soucast distribuce, takze jsem uz zadny zvuk nerozchodil, dokud jsem na tohle neprisel).

Neviem ako vy, ja som skusal Linux (Debian) ale po vyskusani FreeBSD (OpenBSD) som zostal pri nich. Vsetko si kompilujem sam zo zdrojakov, bez najmansich problemov. Nehovorim ktory je lepsi, zalezi komu co sadne. Ja som si vybral FreeBSD. Na notebooku pouzivam FreeBSD 6.0 Current a na desktope FreeBSD 5.4, som s nimi spokojny...:) Ps. system portov ...hmm good !!! :)

System portov je uz dost zastaraly. Nainstalovat konkretnu verziu z minulosti je obrovsky problem (bez rucnych hratok z cvsup ...).

Pripada mi, ze tady nikdo nezminuje problem s BSD, ktery mi pripada docela zakladni. Uz jste si nekdy zkouseli ladit hardware na systemu, ktery ani nema poradny /proc? Kdyz mam s Linuxem nejaky sys problem, zalezu do /procu a nekde vydoluji, co se deje. V BSD? Neexistuje...

Uzivatelska pritulnost sysctl a linux procu je IMHO nesrovnatelna... (samozrejme tim myslim, ze /proc je daleko pritulnejsi, pricemz predem rikam, ze nejsem takovy freak, abych vyznaval maximalne neuzivatelske veci jenom z principu)

No, IMHO tohle je prave ten rozdilny pristup mezi BSD a Linuxem (ci SYSV) - BSDcko ma jeden konfigurak, jeden sysctl. Linux ma strukturovany config a strukturovany proc. Ja preferuji to druhe (a myslim, ze nejsem sam). Mnohdy presne nevim, jak se jmenuje ten ktery priznak jadra, ale proste vlezu do /proc/sys/* a vzpomenu si. Take nevim, jestli je v sysctl eqivalent pouze informativnich veci - tzn. napr fajly jako /proc/bus/usb/devices, /proc/sys/dev/cdrom, atd. (a nerikejte, ze si to muzu najit v lozich - to samozrejme vim, ale proc bych mel neco grepovat, kdyz to mam na jednom fleku...?)

V *BSD je /proc taky, ale je tam to co tam patri, tj. informace o procesech. Informace o nalezenem hardwaru vypisuje prehledne (nesrovnatelne prehlednejinez v Linuxu) jadro pri startu. To mi zatim stacilo.

Skusal som raz FreeBSD (tusim 5.3), pretoze ma zaujimalo, v com je lepsie v bezpecnosti. Otazku nemyslim ohladom jadra, ale ohladom celej distribucie. Jedine, co som si vsimol, bolo, ze FreeBSD ma tusim po instalacii vsetky sluzby (ako napr. sshd) defaultne vypnute a firewall je nastaveny maximalne restriktivne. Co je ale myslim otazka skor instalacneho programu nez rozdielu Linux/BSD/iny OS.

Druha vec, vraj BSD kernel _vraj_ podlieha nejakej specialnej revizii kodu. Nejake blizsie info?

Ako je to napr. s bezpecnostou portov? Mam pocit, ze ked niekto portne nejaky soft, tak ho s najvacsou pravdepodobnostou portne aj so vsetkymi chybami. T.j. pochybujem, ze by precital zdrojove kody a hladal v nich chyby. Skor mozno co najde nahodne.

add bezpecnost portu

to je zajimava vec. Procedura komitovani portu probiha pomoci utility sendpr. Pokud nekdo naportuje libovolny program na FreeBSD (opatchuje, rozchodi zakladni funkce portu - make fetch/configure/install/package atd.) posle port pomoci sendpr k revizi. Samozrejme pochybuji, ze pri revizi dochazi k bezpecnostni analyze celeho produktu. Po revizi se program commitne do cvs a je pres porty pristupny k instalaci.
Dale alae existuji databaze bezpecnostnich chyb, ktere se napriklad kontroluji pri instalaci. Takze pokud se vyskytne bezpecnostni chyba v nejakem konkretnim baliku, a vy ho chcete nainstalovat, system vam to nepovoli, protoze jsou v teto verzi bezpecnostni rizika.
Samozrejme tuto kontrolu muzete vypnout, ale pak je to na vas.
Temito utilitami muzete testovat i nainstalovany software, jestli se u neceho neobjevila chyba.
Samozrejme podobne databaze exploitu existuji pro software nezavisle na platforme, ale tady je jejich kontrola integrovana do spravy systemu (o cemz jsem u jinych systemu neslysel)

Napr. gentoo ma tieto informacie o bezpecnostnych chybach priamo v portage tree. Pri instalacii to tusim este nekontroluje automaticky (pretoze glsa-check je zatial v beta fazi), ale da sa to skontrolovat rucne. Zatial to mam spravene tak, ze kazdy den sa mi pusti emerge sync && glsa-check -t all (update portage tree a check na chyby).

Aha, to je dobre. Gentoo jsem zatim nezkousel, ale spousta lidi si ho chvali prave pro jeho portage system.
Jinak info v portage tree (nebo v ports tree) ale postrada smysl prave proto, ze ta informace je aktualni az v momente, kdy je aktualni port. Ve FreeBSD jde prave o to, ze kdyz se pokusite nainstalovat stary port (protoze mate neauktualni ports tree, nebo potrebujete specifickou starsi verzi), tak se podiva do aktualni databaze exploitu! Pokud updatnete port, tak uz se tam treba ty rizika nevyskytuji a nainstalovat to muzete.
Primo v ports tree jsou flagy BROKEN/IGNORE, ktere take zpusobi to, ze se port nenainstaluje. Obvykle se pouzivaji pro pripady, kdy jsou problemy s kompilaci na nekterych verzich systemu, nebo maji spatne info pro package apod.

Takze ak to chapem spravne, tak FreeBSD pri instalacii portu pozrie do online databaze bezpecnostnych chyb? V Gentoo treba vediet, ze portage tree musi byt aktualny, napr. synchronizovat pravidelne cez cron.

Ako je vo FreeBSD vyrieseny check uz nainstalovanych portov na chyby?

Inak zrejme Gentoo sa inspirovalo tym FreeBSD systemom, namiesto broken/ignore su flagy masked/hard-masked. Prvym sa typicky oznacuju baliky, ktore este bud nie su dostatocne otestovane pre danu platformu (maskovat sa da per-platform) alebo maju este nejake bugy. Hard-masked su tie baliky, ktore su jasne nestabilne, casto sa v nich nachadzaju rozne buffer overflowy sposbujuce segfaulty a ine neprijemne chyby.