musim prispet take svou troskou, prominte.
odjakziva jsem pouzival slack a myslim, ze to je linuxove distro, kde ma vse sve misto a smysl o p r o t i jinym distribucim. v minulosti se nikdy nikam nehnala a to co vyslo v nove verzi, i kdyz bylo castokrat kritizovano, bylo "vzdy" stabilni (prechod libc5 -> glibc, .. spousta dalsich veci). i kdyz pro nekoho spatecnicky postup, pro klidnejsi spanek administratoru serveru vec k nezaplaceni. to co si clovek na danem stroji zkompiloval tam i bezelo - jediny problem, na ktery jsem obcas narazel, byl ponekud prekotny vyvoj jadra linuxu, ktery nekorespondoval s myslenkou slacku - vypoustet az to co je o p r a v d u vyzkousene (no more comments).
jednoho krasneho dne, jsem byl (tehdy) nucen prejit na freebsd. zpocatku drsny prechod z do hlavy lety vtloukanych postupu, na trosku jinou unixlike vetev, byl pro me tvrdym pristanim. opravdu to je cele tak, jak je popisovano v handbooku k tomuto os. vse jako v linuxu jen trosku jinak. neni idealni v mnoha ohledech, naslo by se zde jeste mnoho veci k dodelani, nicmene musim konstatovat, ze to cim se pro me stal kdysi slack svou myslenkou, jednoduchosti, stabilitou - tim je pro me dneska bsdecko. uroven vnitrni usporadanosti tohoto systemu a prehlednost musi byt zjevna kazdemu, kdo mel uz nekdy nejakou jinou zkusenost s jinym *nixem a nyni zkusil freebsd. ma casto kladena otazka v linuxu - proc je tohle zrovna na tomhle miste v adresarove hierarchii? - dostala prave az zde svou odpoved. mezi mozna nevyhody bych uvedl, abych jen stale nevyzdvihoval, dvousecnou zbran svych linuxovych kolegu - podpora hardware. je opravdu slabsi nez u linuxu - priznavam. druha vec je takova, ze uz mnohokrat v minulosti se ukazalo, ze precizni proracovani spolu s konfrontaci dokumentace vydanou vyrobcem daneho hardware je tou pravou cestou. osobne musim priznat, ze tuto zkusenost s linuxovymi drivery v mnoha pripadech nemam.
omlovam se za mozna trosku o f f t o p i c prispevek, ale proste napsat jsem to musel. bye.
- implementace bsdeckoveho tcp stacku microsoftem (pokud se nemylim) je podle me ostuda obou stran. jednak to, ze se "nikdo" z vyvojaru freebsd nebranil a podruhe to, ze si microsoft neco takoveho vubec dovolil.
- token ring - http://www.jurai.net/~winter/tr/tr.html
- nebo (4.4-RELEASE) -
~~ snip ~~
pecko.nekde:~$ grep -i token /usr/src/sys/i386/conf/LINT
# configured or token-ring is enabled.
pseudo-device token #Generic TokenRing
# oltr: Olicom ISA token-ring adapters OC-3115, OC-3117, OC-3118 and OC-3133
# The oltr driver supports the following Olicom PCI token-ring adapters
pecko.nekde:~$
~~ snip ~~
1) Token Ring tam sice je, ale bohuzial su podporovane len Olicomacke karty, ktore som este nevidel. Myslim, ze v tomto su Linux alebo NetBSD na tom lepsie.
2) Co sa tyka BSD kodu vo Win, tak pokial viem, ten kod pochadza z povodneho BSD (4.2?) a nie FreeBSD... len pre poriadok. A ze si ho Microsoft privlastnil? Co je na tom "ostudne"? Hanba by bola, keby porusili licenciu. :-)) Je skoda, ze "komunite" za odmenu nicim neprispeju, ale nemozno ich nutit. Mimochodom, sietovy kod v *BSD sa stale vyvija a tak je v sucasnosti (podla mojho nazoru) o dost vykonnejsi ako ten vo Windows, cize to, ze maju staru verziu BSD sietoveho kodu, im ziadnu vyhodu nedava.
Ad token ring> nevedel som, ze FreeBSD podporuje TR, takze diky za linky. Ked som predtym hladal pri informaciach o novej release, tak tam boli tieto karty medzi ethernet interfaces, takze som to nenesiel, kazdopadne aj tak mam kartu od IBM, takze z BSD rodiny mozem pouzit akurat NetBSD (ale este som ho neskusal)
Vývojáři FreeBSD ani Micro$oftu branit nemohli, protože toto je v BSD licenci povoleno. Narozdíl od GPL, BSD licence nenutí uživatele kódu, aby se také vzdal práva na finanční odměnu za svou práci (tzv. viral aspect of GPL)->BSD licence je daleko altruističtější než GPL.
Tento přístup je poměrně výhodný, protože:
1)firmám se jednodušeji vydělává
2)zveřejnění kódu daleko snadněji vytváří standardy->i firmy občas přispějí svobodnému softwaru.
Kéž by si Micro$oft vypůjčil více kódu z BSD (a Linuxu pokud by to licence umožňovala). Windoze by byly lepší a dělaly by méně problémů s kompatibilitou. Nejlepší by bylo, kdyby si příští M$Office "vypůjčila" formát dokumentů z KOffice nebo StarOffice.
>Kéž by si Micro$oft vypůjčil více kódu z BSD
To by ich kod bol stabilnejsi a lepsie by sa im presadzovalo na trhu. Na nas by cakali este propietarnejsie >>standardy<< a este tvrdsie podpasofky.
>Nejlepší by bylo, kdyby si příští M$Office
>"vypůjčila" formát dokumentů z KOffice nebo >
>StarOffice.
to sa ale nikdy nestane. m$ nepuziva svoje zvrhle formaty preto, ze je nesikovny ale preto, aby nutil ostatnych prejst na ich platformu. preto m$ najviac vyhovuju take formaty, ktore su utajene a zaroven previazane s ich platformou (napriklad format obsahuje odkazy priamo na funkcie API atd.).
Pokud bych ja srovnaval FreeBSD s Linuxem (debian distribuce)
FreeBSD + : snadna instalace
lepsi sprava a management bezicich procesu
(linearni seznam pro velky pocet procesu proste zere prilis mnoho systemovych zdroju)
snadna konfigurace (na jednom miste)
rozumnejsi cislovani eth interfacu (v linuxu jeden vytahnete, a precisluji se vsechny)
FreeBSD - : sprava "balicku"
konfigurace sluzeb
slabsi podpora hw
dementni pojmenovavani zarizeni v dev podle
vyrobce, misto podle typu
co je spatneho na sprave balicku u freebsd ?
je tam nadherne izi pkg_add, pkg_delete, pkg_info(to umi listovat i jiz nainstalovane balicky)
asi vam chybi adresar rd.d/init.d ze ? me teda ne ...
ano, podporu hw ma bohuzel slabsi, ja mam grafiku od nvidie a jako workstation zatim fbsd pouzivat nemuzu, protoze mi nestiha prehravani filmu
pojmenovanani zarizeni v /dev je zvyk, ono je to skoro na kazdem *nixu uplne jine :))