NetBSD 5.0

Nie jest wyczerpująca, tak samo jak pytanie. A gdybym napisał, to zaraz posypałoby się 'a wcale, że nie, bo'. Poszukaj, poczytaj, zainstaluj. Wyrobisz sobie własną opinię

Używanie systemu wcale nie rozjaśni takich kwestii jak bezpieczeństwo, ilość zapytań SQL na sekundę itp. Takie rzeczy wymagają portfolio bezpieczeństwa i specjalizowanych benchmarków .. które z pewnością ktoś na sieci już dokonywał.

a już nie działa?

@marcinsud: Jakos tak wyszlo, ze na codzien uzywam OSX-a.

A nie wiesz czasem jak jest ze sterownikami do interfejsów audio?

Co ciekawe projekt poszedł w stronę zasugerowaną w słynnym tekście Charlesa Hannuma "NetBSD jest martwe". W przeciwieństwie do wersji 4.0, edycja 5.0 wnosi sporo wartościowych zmian.

Projekty NetBSD w GSoC 2009 wyglądają bardzo ciekawie, oby tak dalej.

@LV: Musialbys sie dowiedziec, jaki to byl port (lista jest tutaj: http://netbsd.org/ports/#in-tree-ports) i zerknac do listy obslugiwanego sprzetu (na przyklad tu: ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.0/evbarm/INSTALL.html). Ogolnie – inaczej niz w przypadku Linuksa, w BSD jest dokumentacja – i warto jej uzywac, bo zwykle jest aktualna.

AFAIK to była specjalna wersja, specjalnie na ten jeden toster.

w tosterze była płytka z arm, więc równie dobrze można zainstalować Linuksa

czyli, że nowy NetBSD też da radę pewnie

http://www.embeddedarm.com/software/arm-netbsd-to…

Linuksa nie zainstalujesz, nie ma driverów

Trasz choć ma klapki na oczach i lubi siać zament dyletantem jednak nie jest.

Nie, facet który commituje do src FreeBSD nie jest kompletnie znawcą tematu ;> A ty jesteś znawcą czego? Pochwal się..

Czym się różni system na SPARC64 od systemu na UltraSPARC? Tak pytam, bo oba te procesory implementują ten sam zestaw instrukcji, SPARC V9

Też nie będę tego oceniać, ale podobno większość portów w przypadku Linuksa to gołe jajko. NetBSD to natomiast gotowy userland z toolchainem umożliwiającym "łatwą" cross kompilację (puryści językowi prawdopodobnie zjędzą mnie za te określenia).

NetBSD uchodzi za system z czystym HALem, co w przypadku wielu platform też ma swoje znaczenie.

> podobno większość portów w przypadku Linuksa to gołe jajko.

Nie wiem, co to "jajko", jeśli chodzi o Linuksa. Czy chodzi o jądro systemu?

> NetBSD to natomiast gotowy userland z toolchainem

Stary i wytarty do niemożliwości "argument" fanboyów BSD: że niby "Linux to tylko kernel". Owszem, formalnie rzecz biorąc – tak. Tylko co mnie interesuje ta czysto formalna różnica? Tak samo, jak BSD – tak i Linux (jako dystrybucja) zawsze zawiera jakiś userland. Że nie zawiera obligatoryjnie jakiegoś ustalonego zestawu narzędzi – to może być wręcz odczytane jako zaleta, bo daje większą swobodę twórcom dystrybucji (np. jeden wrzuci fdisk – a inny gparted-a).

Jeśli się mylę: wskaż mi dystrybucję Linuksa zawierającą sam kernel – i nic poza nim.

Poza tym: przecież prace rozwojowe xBSD też koncentrują się na rozwoju jądra systemu; jakoś nie za bardzo stwierdzam "rozwój userlandu". Chociaż – przyznaję – od pewnego czasu przestałem to śledzić. Po prostu: przekonawszy się, że xBSD – z czysto praktycznego punktu widzenia (podkreślam!) "to taki inny Linux", a poza tym oferuje głównie kłopoty w Linuksie dawno rozwiązane – już nie poświęcam temu tyle uwagi.

@ó: NetBSD jest przenosne. Linux zostal poprzenaszany. Roznica polega na przyklad w tym, ze w czasie, gdy wszystkie BSD od niepamietnych czasow mialy newbus i busdma – mechanizmy pozwalajace zapanowac nad mnogoscia roznych szyn, mechanzmow dostepu do pamieci i quirkow z tym zwiazanych, w kazdej architekturze innych, Linux nadal mial oddzielne API do kazdej z szyn i kupe ifdefow w celu obchodzenia szczegolow sprzetu w, rzekomo niezalezeznych od architektury, czesciach kodu. Inny przyklad to pmap – w Linuksie port na nowa architekture przez dluzszy czas – i kto wie, czy nadal tak nie jest – wymagal zrobienia kopiuj/wklej na wiekszej czesci kodu zarzadzajacego pamiecia, bo nikomu nie przyszlo do glowy, zeby to jakos sensownie uporzadkowac na czesc niezalezna od sprzetu i czesc od sprzetu zalezna.

Ale ogolnie – tak, masz racje, BSD to taki inny Linux. Z tym, ze w Linuksie nadal sa klopoty z rzeczami w innych systemach dawno rozwiazanymi, jak na przyklad z device'ami (udev? litosci.)

ó: Nie do końca o to chodzi. Linuksowi można zarzucić niespójność – każda dystrybucja ma swoje "rozwiązania", całe "ustrojstwo" od instalacji i uaktualniania oprogramowania, sposób konfiguracji systemu itp. itd. Ja jako użytkownik muszę sobie wybrać swoją ulubioną, do której się przyzwyczajam, zaczynam ją biegle obsługiwać od każdej strony, po czym zmienia się platforma sprzętowa i zaczynają się schody…

Popularne dystrybucje Linuksa budowane są głównie dla i386 i amd64, podczas, gdy NetBSD jest kompletnym systemem dla każdej wspieranej architektury. Jeśli w przypadku NetBSD zmieniasz platformę sprzętową, to po prostu instalujesz nowe NetBSD dla 'xxxx' i de facto cała Twoja wiedza i nawyki pozostają bez zmian. W przypadku Linuksa może (nie zawsze oczywiście musi) czekać Cię zmiana całej dystrybucji ze wszystkimi tego konsekwencjami. Weź też pod uwagę, że nie są to przypadki zmiany systemu na laptopie w domu, ale migracji np. serwera, na którym mogą być konta shellowe. Wtedy zmiana przyzwyczajeń dotyczy nie tylko Ciebie, ale też masy innych ludzi.

Tutaj widać główną różnicę między NetBSD a Linuksem w kwestii przenośności. Tu nie chodzi o "liczenie" – 10, 20, czy 50 platform w katalogu arch tylko o łatwość przeniesienia się z jednej na drugą platformę. To jest właśnie "skrajna przenośność" – nie dość, że system wspiera całą gamę urządzeń wchodzącej w skład danej architektury, ale oferuje też maksymalnie jednolite środowisko na wszystkich platformach.

> Linuksowi można zarzucić niespójność – każda dystrybucja ma

> swoje “rozwiązania”

To zamiast używać 10 dystrybucji naraz – wybierz sobie jedną.

> Popularne dystrybucje Linuksa budowane są głównie dla i386 i amd64

…to wybierz mniej popularną. Nikt przecież nie broni.

> NetBSD jest kompletnym systemem dla każdej wspieranej architektury

…a Linux to niby nie jest kompletny "dla każdej wspieranej architektury"? Podaj nazwę takiej "niekompletnej" dystrybucji – i wymień, czego jej tam brakuje.

> Jeśli w przypadku NetBSD zmieniasz platformę sprzętową, to po

> prostu instalujesz nowe NetBSD dla ‘xxxx’ i de facto cała Twoja

> wiedza i nawyki pozostają bez zmian

Nic podobnego. Tak samo, jak w przypadku Linuksa na różnych sprzętach – tak i w przypadku każdego z xBSD są różnice dla "portów" na poszczególne platformy sprzętowe.

Sugeruję najpierw przysiąść fałdów – potem dopiero "produkować się" po forach z takimi mądrościami. Że to niby "na czymkolwiek nie zainstalujesz – jak Ci nie powiedzą, to nie zauważysz różnicy". Totalna bzdura.

> nie dość, że system wspiera całą gamę urządzeń wchodzącej

> w skład danej architektury,

Nieprawda. Przykład: o ile mi dobrze wiadomo, to np. OpenBSD do dziś dnia nie obsługuje głupiego floppy na SPARC64, bo po prostu twórcy "uznali to za zbędne" (tak, takie właśnie było uzasadnienie).

> ale oferuje też maksymalnie jednolite środowisko na wszystkich

> platformach

Bzdura. Porównaj sobie np. zachowanie i możliwości NetBSD/OpenBSD – w trybie znakowym – na Intelu, i choćby na wspomnianym SPARC64.

Sorry: nie zdążyłeś za wiele zobaczyć i osobiście przetestować – tylko najwyraźniej przepisujesz jakieś slogany reklamowe.

Odnosząc się do owego "maksymalnie jednolitego środowiska": to właśnie Linux zapewnia praktycznie takie samo środowisko trybu znakowego na SPARC64, co na Intelu – natomiast nie dotyczy to ŻADNEGO z xBSD, gdzie trzeba nieźle się gimnastykować podczas pracy z beznadziejnym terminalem "sun". Linux zaś – dzięki framebufferowi – dostarcza na SPARC64 terminal… "linux", właśnie taki sam, jak na Intelu. I dzięki takim (zdawałoby się) "drobiazgom" właśnie pracując z Linuksem na różnych platformach, w najmniejszy sposób muszę zmieniać swoje przyzwyczajenia.

Fanboye xBSD: jesteście żenujący w tak nieudolnej reklamie systemów, których nawet bliżej nie poznaliście. Sami nie wiecie, co właściwie reklamujecie.

@ó: Problem w tym, ze jesli chcesz miec dzialajacego Linuksa na sparc64, to masz wybor miedzy Debianem i Aurorą – ktora pod niczym innym niz sparc64 nie chodzi. Z tym, ze kiedy ostatnio sprawdzalem, plytki instalacyjne Debiana mialy zwalony bootloader i nie doczekalo sie to poprawki od prawie roku, wiec wybor byl miedzy Aurorą i Aurorą. Wole nie myslec, co w przypadku mniej popularnych architektur. Zreszta i tak pierwsze lepsze FAQ poswiecone sparcom mowilo wyraznie, ze Linux ma troche popsute zarzadzanie pamiecia, w zwiazku z tym dziala na nich beznadziejnie. Zmienilo sie to w koncu?

Co do zachowania i mozliwosci – no, wykaz sie. Czym kluczowym w trybie znakowym rozni sie NetBSD na intelu i sparc64? Tylko prosze – mow o naprawde istotnych rzeczach, a nie o funkcjonalnosci, ktorej wylaczna rola na wszystkich uniksowych stacjach roboczych wyprodukowanych po 1995 roku bylo doprowadzenie do dzialania X11.

Btw, jak pod tym Linuksowym framebufferem dziala STOP-a? Bo wiesz, to akurat _jest_ kluczowy ficzer. ;->

To zes pocelowal – Arch Linux na pokladzie. Moze jednak na stale przeniose sie na NetBSD, bo z hecklerami chce miec jak najmniej wspolnego.

Co rozumiem osobiscie przez skrajna portownosc? Latwosc przystosowania systemu do nowej platformy – przykladowo odmiana ARMa. W przypadku NetBSD wymagana ilosc kodowania jest mocno ograniczona dzieki mocnym abstrakcjom – m.in. podsystemy bus_dma, uvm, bus_space, pmap.

Linux jest obecny na wiekszej ilosc platform m.in. dzieki wykorzystaniu wspanialego "uClibc" i innych "ciekawych" rozwiazan jak to sam opisales.

EOT, liczylem na ciekawa dyskusje, a dostalem po przyslowiowym ryju.

> To zes pocelowal – Arch Linux na pokladzie. Moze jednak na stale

> przeniose sie na NetBSD, bo z hecklerami chce miec jak najmniej

> wspolnego.

A przenoś się. Ktoś Ci broni?

> W przypadku NetBSD wymagana ilosc kodowania jest mocno ograniczona

> dzieki mocnym abstrakcjom – m.in. podsystemy bus_dma, uvm,

> bus_space, pmap.

Nie wiem – ale nie wykluczam. Tyle, że co mnie to właściwie obchodzi? Co mnie interesują "podsystemy"? Czy ja używam programów, hulających w określonym środowisku – czy "podsystemów" jeno? Niech się mordują z "podsystemami" programiści danego zespołu – ja to oceniam z pozycji użytkownika.

I w ogóle jak to się ma do tego, co pisałeś przedtem? Najpierw jakieś uwagi o "gołym jajku" – a teraz (ni z gruszki, ni z pietruszki), nagle coś o "podsystemach".

> Linux jest obecny na wiekszej ilosc platform m.in. dzieki

> wykorzystaniu wspanialego “uClibc” i innych “ciekawych”

> rozwiazan jak to sam opisales.

…no i bardzo dobrze. Najwyraźniej te rozwiązania "sprawdzają się w praniu".

> EOT, liczylem na ciekawa dyskusje, a dostalem po przyslowiowym

> ryju.

Po "przysłowiowym" ryju? Jak brzmi to przysłowie o ryju?

> Problem w tym, ze jesli chcesz miec dzialajacego Linuksa na

> sparc64, to masz wybor miedzy Debianem i Aurorą – ktora pod niczym

> innym niz sparc64 nie chodzi.

Tutaj zupełnie niedawno jeszcze Twój kolega-BSDylman narzekał na mnogość dystrybucji w Linuksie (tam wyżej widać)… uzgodnijcie może zatem wreszcie wersję: czy: "dużo dystrybucji to źle" – czy też: "mało dystrybucji to źle"?

Coś ciężko Wam dogodzić; gdy chodzi o Linuksa, to dla Was KAŻDA ewentualność przemawia na jego niekorzyść.

> Z tym, ze kiedy ostatnio sprawdzalem, plytki instalacyjne

> Debiana mialy zwalony bootloader

A to ciekawe, że moje płytki Lenny'ego nie wiedzą, że to niby "mają zwalony bootloader" – bo przecież nie mógłbym wtedy na swego Ultra 10 systemu "zapodać"… dobrze, że one takie nieświadome.

> Czym kluczowym w trybie znakowym rozni sie NetBSD na intelu i

> sparc64?

W trybie znakowym? Pisałem już: tryb znakowy Debiana na SPARC64 odpowiada trybowi znakowemu Debiana na x86 (jedyna różnica: na sparcu musi być framebuffer, ale to nie wadzi). Natomiast w przypadku NetBSD kicha: ot, "terminal sun", w rzeczy samej nadający się jedynie do jak najszybszego odpalenia X-ów, i ucieczki w XTerm.

> Btw, jak pod tym Linuksowym framebufferem dziala STOP-a? Bo wiesz,

> to akurat _jest_ kluczowy ficzer. ;->

A ja nawet nie wiem, co to owa "STOP-a" – z czego wnoszę, że to nic kluczowego, przynajmniej dla mnie (albo nie kojarzę skrótu). Dla mnie praca na SPARC64 pod Debianem jest po prostu normalna: i narodowe robaczki widać, i semigrafikę takoż. Nie trzeba na serwer dawać X-ów, żeby uniknąć zbędnej gimnastyki na klawiaturze.

> Roznica polega na przyklad w tym, ze w czasie, gdy wszystkie

> BSD od niepamietnych czasow mialy newbus i busdma [..]

…różnica polega na tym, że ja dokonuję oceny z punktu widzenia użytkownika – a Ty i Kolega (jak rozumiem) z punktu widzenia programisty.

Otóż stwierdzić tu należy, iż nawet, jeśli naprawdę takie czy inne rozwiązania (jeśli chodzi o "bebechy") xBSD mogły mieć lepiej urządzone (a czemu nie…), to jakoś summa-summarum Linux i tak rozwija się szybciej, i jest o wiele bardziej używalny, niż każdy z xBSD. I jakoś ma więcej programistów – którzy przecież mogliby się obrazić na to, że "Linux nadal mial oddzielne API do kazdej z szyn i kupe ifdefow w celu obchodzenia szczegolow sprzetu". Ale jakoś "obchodzą szczegóły sprzętu", i trzymają się Linuksa, a nie uciekają do xBSD.

Więc co mi za różnica, że np. pewne rzeczy mogłyby być (z programistycznego punktu widzenia) rozwiązane lepiej – skoro jednak wszystko to zebrane do kupy już dzisiaj oferuje mi sprawniejszą i wygodniejszą pracę, niż którykolwiek z BSD? A te lepsze rozwiązania i tak z czasem zostaną zaimplementowane, jeśli okażą się potrzebne.

> udev? litosci.

Sorry: teraz ewidentnie widać, że po prostu trollujesz.

Udev jest i działa. Pewnie, że wymagał całej serii poprawek i modyfikacji (i zapewne będzie ich więcej) – niemniej jednak działa. Słówko "litości" nie jest żadnym argumentem.

@ó: Napisales wczesniej, cytuje, "To zamiast używać 10 dystrybucji naraz – wybierz sobie jedną.". Problem w tym, ze w Linuksie jest to niemozliwe – bo wiekszosci dystrybucji nie ma na wiekszosc platform, wiec o Ubuntu na sparcu czy RHEL na AXP moge zapomniec.

Co do Lenny'ego – no ok, skoro dziala na U10, to na U5 rowniez – wiec w koncu, po roku, poprawili. Pytanie tylko, dlaczego musialo to tyle trwac?

Co do STOP-a – no ok, dziekuje za zademonstrowanie, ze nie masz pojecia o sprzecie, ktorego uzywasz. O ile terminal tekstowy w praktyce jest nieistotny – bo i tak sie go nie uzywa, XTerm jest lepszy pod kazdym wzgledem i w NetBSD, i w Linuksie (dzialajacy UTF8, antyaliasing, kerning i nieporownywalnie lepsza predkosc dzialania) – o tyle dostep do firmware'u – wrecz przeciwnie.

Co do "punktu widzenia uzytkownika" – zwroc uwage na to, co napisalem powyzej: NetBSD jest przenosne, Linux zostal co najwyzej poprzenaszany. I przyklady mechanizmow, ktorych Linux dopiero sie dorabia, sa przykladem na slaba przenosnosc nadrabianą bruteforcem.

A co do udev – heh, wlasnie problem w tym, ze udev jest gorszy od mechanizmow uzywanych przez chyba kazdy system konkurencyjny – od Windows (ktory ma w pelni funkcjonalny, dynamiczny devfs) po Solarisa (ktory ma devfs troche mniej dynamiczny, ale nie wymagajacy userlandowego helpera). Mniejsza juz o idiotyczny design i wynikajace z niego race conditions, ale sytuacja, w ktorej kernel nie potrafi o wlasnych silach nawet znalezc sobie sprzetu, nie jest normalna. Poza tym udev to powrot do starych ograniczen, chociazby z koniecznoscia alokacji numerkow dla urzadzen. Wreszcie, udev uniemozliwia Linuksowi zrobienie tego, co zrobiono we FreeBSD – wywalenia _masy_ skomplikowanego kodu z filesystemow i VFS-a, ktory zajmowal sie obsluga urzadzen. Wiec w Linuksie caly ten kod trzeba trzymac – i krap sie nawarstwia.

> wiekszosci dystrybucji nie ma na wiekszosc platform, wiec o

> Ubuntu na sparcu czy RHEL na AXP moge zapomniec.

…i tu z pomocą przychodzi łatwość tworzenia dystrybucji: nie ma na określoną platformę jednej – to może inna się znajdzie. Ostatecznie zawsze możesz jeszcze osobiście "przeportować" swoją ulubioną dystrybucję, korzystając ze źródeł.

> Pytanie tylko, dlaczego musialo to tyle trwac?

To do mnie pytanie? Moja odpowiedź: nie wiem. I w ogóle nie wiem, ile trwało. U mnie działa.

> Co do STOP-a – no ok, dziekuje za zademonstrowanie, ze nie masz

> pojecia o sprzecie, ktorego uzywasz.

Mam takie pojęcie, jakie jest mi potrzebne. Z faktu, że nie musiałem doszukiwać się dotąd informacji dot. "STOP" (czymkolwiek toto jest) jasno wynika, że u Ciebie zapewne znowu coś się chrzani, a u mnie – popatrz tylko – znowu działa "bez niczego". Albo, że chodzi o "fejczer" niezbyt potrzebny, rzadko używany.

> terminal tekstowy w praktyce jest nieistotny – bo i tak sie go nie

> uzywa, XTerm jest lepszy pod kazdym wzgledem i w NetBSD, i w

> Linuksie (dzialajacy UTF8, antyaliasing, kerning i

> nieporownywalnie lepsza predkosc dzialania)

"Srutu-tutu majtki z drutu" – tak można podsumować te wywody. Jasne, na serwer będę specjalnie X-y instalował, oraz fonty z antyaliasingiem i kerningiem. Faktycznie, tam są najbardziej potrzebne.

> o tyle dostep do firmware’u – wrecz przeciwnie

O to chodziło Ci ze STOP-em? Nigdy nie potrzebowałem dobierać się do firmware'u "z poziomu działającego systemu". U mnie wszystko – raz ustawione – jakoś (popatrz, popatrz!) prawidłowo działa. Może dlatego, że korzystam z Linuksa?

> Co do “punktu widzenia uzytkownika” – zwroc uwage na to,

> co napisalem powyzej: NetBSD jest przenosne, Linux zostal

> co najwyzej poprzenaszany

Z punktu widzenia użytkownika: żadna różnica. Ma działać – i już. I działa.

To tak, jak z samochodem: ma spełniać zadanie, do jakiego jest przeznaczony. A czy silnik jest konstrukcją oryginalną, czy licencyjną, czy został wykombinowany w jakiś inny sposób – to już kierowcę niespecjalnie musi obchodzić, skoro działa.

> A co do udev [..]

…a co do udev, to jest to tylko Twoja najzupełniej prywatna opinia, którą mogłeś zapisać znacznie krócej, np. "udev mi się nie podoba". Akurat tyle samo treści – a jakie zwięzłe, nieprawdaż?

"Design" ma "idiotyczny"? Otwarte pole do popisu dla Ciebie – przyłącz się, jesteś ponoć "fachowcem, który zna się na sprzęcie, którego używa" – zaprojektuj to lepiej. Pokaż światu, co umiesz! Chyba, że – jak każdy krytyk – jesteś impotentem, który "wprawdzie wie jak – ale sam jakoś nie może…"? Zgadłem?

@ó: STOP-a to kombinacja klawiszy, ktorej uzywasz, zeby na przyklad wystartowac maszyne z CD (STOP-a, potem 'boot cd', jesli sciezki w OpenBoot masz dobrze poustawiane). Jestes pewien, ze widziales z bliska jakiegos sparca? ;->

Co do konsoli na serwerze – zwykle uzywa sie konsoli zdalnej, przez LOM czy (raczej kiedys) port szeregowy. Przy koniecznosci przytachania monitora i klawiatury (albo chociaz dociagniecia kabli), koniecznosc zainstalowania x11 jest niewielkim problemem. I znow – jestes pewien, ze widziales z bliska jakis serwer? ;->

Co do udeva – to zostalo zaprojektowane lepiej w innych systemach, i podalem ci konkretne przyklady. Naprawianie bledow projektowych w Linuksie i tlumaczenie jego developerom, dlaczego istniejacy mechanizm jest OKDR, byloby perwersyjnym hobby nawet jak na mnie.

…zastrzelimy – po prostu za bezmyślne powtarzanie frazesów.

Jeśli chcesz być wiarygodny: napisz, dlaczego – Twoim zdaniem – Linux:

- nie nadaje się do routingu i firewallingu

- nie nadaje się do "generalnego serwowania"

- nie cechuje się innowacyjnością (tak rozumiem ten "research"), tudzież nie znajdujemy(?) w nim oryginalnych rozwiązań

Odpowiedź – rzecz jasna – uzasadnij.

@ó: Porownaj sobie skladnie pf-a (BSD) i iptables (Linux). Potem zastanow sie, gdzie w Linuksowym iptables jest na przyklad dzialajaca normalizacja pakietow. Dzialajaca, czyli nie w stadium eksperymentalnym i nie wykladajaca kernela co godzine. O failowerze do firewalla nie wspomne, co by nie kopac lezacego.

Co do "generalnego serwowania" – alez nadaje sie. Windows tez sie nadaje. Z tym, ze pod FreeBSD mozna na przyklad uzywac ZFS-a, a w Linuksie trzeba meczyc sie z recznym rozszerzaniem LV, jak w latach dziewiecdziesiatych, kiedy LVM-y byly na topie.

Co do innowacyjnosci – oho, moj ulubiony temat. Ok, wskaz jakies oryginalne rozwiazanie w Linuksie. ;->

> gdzie w Linuksowym iptables jest na przyklad dzialajaca

> normalizacja pakietow

Ale mi jest niepotrzebna "normalizacja pakietów". I dla milionów innych użytkowników IPTables najwyraźniej również nie jest to rzecz pierwszej potrzeby.

Dla mnie – na przykład – o wiele niezbędniejszy jest bezbłędnie działający w trybie znakowym terminal. Żebym miał zarówno polskie znaki, jak i semigrafikę w trybie czysto znakowym, bez potrzeby w ogóle instalowania X-ów. Który z *BSD to ma – zgadnij, Koteczku? Odpowiedź : ŻADEN.

> pod FreeBSD mozna na przyklad uzywac ZFS-a

Jakoś użytkownikom "top 500" to nie przeszkadza. Sprawdź, pod jakimż-to systemem zdecydowana większość tych big-ironów pracuje.

To by nam chyba załatwiało temat "generalnego serwowania".

> wskaz jakies oryginalne rozwiazanie w Linuksie.

Ha, o gustach się nie dyskutuje – a kwestia "oryginalności" jest uznaniowa przecież (nie ma OBIEKTYWNYCH kryteriów "oryginalności"). Ale proszę – pierwszy z brzegu – czy np. udev nie jest oryginalnym, choćby z tego względu, że obecnym jedynie w Linuksie rozwiązaniem?

Inne oryginalne rozwiązania zapodam, kiedy CHOCIAŻ JEDEN z systemów BSD dorobi się wreszcie – po wielu latach – tak oryginalnego i innowacyjnego rozwiązania, jak prawidłowo działający w trybie znakowym terminal.

@ó: Dla milionow innych uzytkownikow kompletnie zbedne jest cokolwiek innego niz Windows.

Co do terminala – coz, widocznie rzeczywiscie dla ciebie Linux jest lepszy. W realnych zastosowaniach terminal znakowy potrzebny nie jest (bo dostep albo jest przez siec, albo uzywa sie X11), a wiekszosc systemow jest robionych wlasnie pod katem realnych zastosowan, a nie dlatego, ze komus sie nudzilo.

Co do TOP500 – TOP500 ma dokladnie zero wspolnego z 'generalnym serwowaniem' – i typ obciazen, i sposob uzywania maszyn sa kompletnie inne.

Co do udev – wiesz, na takiej zasadzie, to Windowsowy blue screen jest oryginalnym rozwiazaniem, bo zaden inny system tak nie ma. Mowmy moze o jakichs istotnych rozwiazaniach. W przypadku innych systemow bez problemu mozna podac przyklad originalnego mechanizmu, ktory skopiowaly – lub przynajmniej nosza sie z tym zamiarem – inne systemy – w Solarisie bedzie to na przyklad slab allocator, PAM czy NSS. W BSD – chociazby jaile. A w Linuksie?

> W realnych zastosowaniach terminal znakowy potrzebny nie jest

No jasne. W pełni go zastępuje "normalizacja pakietów".

> TOP500 ma dokladnie zero wspolnego z ‘generalnym serwowaniem’

A tak, jasne. Poprzestańmy zatem na konstatacji, że Linux nadaje się na komputery, a xBSD – co najwyżej na komputerki.

> Co do udev – wiesz, na takiej zasadzie, to Windowsowy blue screen

> jest oryginalnym rozwiazaniem, bo zaden inny system tak nie ma.

> Mowmy moze o jakichs istotnych rozwiazaniach.

Taaaa, "mów do mnie jeszcze". "Jeśli czegoś nie ma w xBSD – to znaczy, że to nie jest istotne, tak"? To o kernel-based mode-setting już nawet nie wspomnę, bo to też "nieistotne" – jako, że xBSD nie dorobi się tego przez 10 najbliższych lat.

@ó: Terminal znakowy realizowany przez kernel jest nedzna, uboga funkcjonalnie (brak sensownych czcionek, chociazby – i mechanizmow renderingu, jak antyaliasing) i nedzna wydajnosciowo (brak mozliwosci uzycia wiekszej czesci mechanizmow akceleracji) namiastka XTerma lub czegokolwiek innego w trybie graficznym.

Co do TOP500 – dowiedz sie w wolnej chwili, czym sie roznia obciazenia obliczeniowe od typowo io-bound. Roznice sa potezne; ogolnie to pierwsze jest dla systemu duzo latwiejsze, bo czasu w kernelu spedza sie pomijalnie malo, wiec waskie gardla sa mniej zauwazalne.

A co do modesetting – na twoim miejscu poczekalbym, az dorobi sie go Linux – jakies dwadziescia lat po Windows NT i dziesiec po MacOS X. Znaczy, zakladajac, ze specjalisci od Linuksa sie pospiesza. Do FreeBSD wystarczy to przeportowac, tak jak przeportowano DRI.

> Terminal znakowy realizowany przez kernel jest nedzna, uboga

> funkcjonalnie (brak sensownych czcionek, chociazby – i mechanizmow

> renderingu, jak antyaliasing) i nedzna wydajnosciowo (brak

> mozliwosci uzycia wiekszej czesci mechanizmow akceleracji)

> namiastka XTerma lub czegokolwiek innego w trybie graficznym.

Sorry, ale zaczynasz w zapale bredzić. Niestety.

Terminal znakowy NIE MOŻE BYĆ "namiastką" XTerma, bo najpierw były terminale znakowe, a rozmaite XTermy dopiero później.

A te renderingi i antyaliasingi – kto Ci naopowiadał, że na serwerze-routerze-firewallu (na przykład) są to rzeczy pierwszej potrzeby? Aha, i jeszcze "akceleracja" – chyba po to, żeby administrator sieci mógł sobie na serwerach w Quake'a zagrywać.

> Co do TOP500 – dowiedz sie w wolnej chwili [..]

…dobrze, to w wolnej chwili będę się dowiadywał, a na chwilę obecną – niewolną – przesłanie dla mnie (i dla milionów innych zainteresowanych tematem) jest jasne: Linux nadaje się na najrozmaitsze "rozmiary i kalibry sprzętu" (ładnie się skaluje), i stosowany jest – można rzec – w "pełnej rozpiętości" zadań (od "embedded", jak gumstix, aż do superkomputerów) – a xBSD (mimo, iż rzekomo pod każdym względem lepsze) już niekoniecznie. No i co Ty właściwie chcesz mi tłumaczyć, że to przemawia na niekorzyść Linuksa? Masz spore zdolności interpretacyjne, jak widzę.

Co do "obciążeń": no są obciążenia, i Linux sobie z tymi obciążeniami znakomicie radzi. W czym więc problem? Ja nie widzę.

Pełno jest porównań "Linux vs BSD" w Sieci, które wcale nie są jednoznacznie po stronie xBSD. Ot, znalazłem szukając "na chybcika" coś niezbyt świeżego, ale ciekawego: http://bulk.fefe.de/scalability/ – poczytaj sobie w wolnej chwili.

> A co do modesetting – na twoim miejscu poczekalbym, az dorobi sie

> go Linux

Kwestia dosłownie miesięcy – zajrzyj sobie na bloga jglisse.

> Do FreeBSD wystarczy to przeportowac, tak jak przeportowano DRI.

Ja raczej sądzę, że "tak, jak przeportowano przyzwoity terminal znakowy". …czyli: "na święty nigdy" Przecież ważniejsze jest, żeby kernel xBSD działał na setce procesorów, niż żeby się jakiś luser grafiką bawił. Albo, niż żeby mógł sobie z dyskietki na SPARC64 korzystać – niech się, zacofaniec, nauczy, że dyskietki są już niemodne, i szkoda czasu na pisanie obsługi. "Niech se sam napisze – i patcha zapoda, chętnie przyjmiemy".

Taki właśnie jest zatęchły światek xBSD. Spektakularne "fejczery" na pierwszym miejscu (wiadomo: reklama, "hype" itd.) – a te prozaiczne, ale NAJBARDZIEJ POTRZEBNE użytkownikom sprawy, to już "jak czasu i chęci starczy". Niestety: z reguły jakoś nie starcza, i proponuje się użytkownikom, żeby "sami se napisali – tu nikt nie jest na ich usługi".

@ó: Do serwerow jest dostep zdalny; konsola znakowa jest wiec kompletnie nieistotna.

Co do porownan wydajnosci – znalazles fajny benchmark, tylko ze historyczny. Troche bardziej wspolczesny przyklad wydajnosci pod obciazeniem (w dodatku produkcyjnym, tzn. nie jest to benchmark syntetyczny) masz na przyklad tutaj: http://people.freebsd.org/~kris/scaling/bind-pt-2…

Co do modesetting – jak nie zapomne, to za "pare miesiecy" przypomne ci tego posta i zapytam "i co, gdzie jest ten modesetting"?. ;->

W przypadku BSD na pierwszym miejscu sa wlasnie rzeczy _najbardziej potrzebne_. Konsola tekstowa i na serwerach, i na desktopach sluzy wylacznie do naprawienia, odpowiednio, zdalnego dostepu i x11. I, inaczej niz w Linuksie, male sa szanse, ze ktos znudzony bedzie wywracal ten kod do gory nogami, ryzykujac wprowadzenie nowych bledow, zeby ktos mogl sobie uzywac konsoli w sposob inny niz reszta swiata, bo na przyklad organicznie nie lubi x11 – developer Xorg przejechal mu kota albo cos.