Miałeś podać _wnioski_. To znaczy wymień, jakie kategorie zostały przetestowane, ale na końcu podaj “najszybszy okazał się X” albo trudno wskazać jednoznacznego zwycięzcę. nie mam czasu czytać całości, a z chęcią bym się dowiedział:)

Albo chociaż pod każdym z testów zaznacz wyraźnie która wersja wygrała, bo tak to ciężko się połapać, szczególnie jeśli chodzi o FreeBSD.

Tu się nie da wskazać zwyciezcy, różne schedulery, różne konfiguracje jąder, różne kompilacje, systemy plików – widać, ze Debian podobnie jest wydajny z jadrem linux jak freebsd, mimo, ze jest optymalizowany pod linuksa. Konfiguracja standardowa FreeBSD jest nastawiona na bezpieczenstwo nie wydajność – wiec już samo założenie porównania jest bez sensu. To jak porównywać limuzyne do samochodu formuły 1 – co z tego ze to i to jeżdzi jak ma inne przeznaczenie. Test byłby ok jak by konfiguracje były identyczne, optymalizacje identyczne, i funkcje bezpieczenstwa identyczne… ale czy sie tak da?

@konski_pytong: i tu się mylisz. Porównywać można i to właśnie zrobili. Wyciągać należy jednak sensowne wnioski. W twoim przykładzie samochodowym- jeśli okazało by się, że limuzyna ma zbliżone do f1 przyspieszenie 0-100, to co to oznacza? Ano to, że coś w F1 skopali.

Wniosek twój jest zbliżony do tego co napisali autorzy testu- czyli ze FB ma inne założenia, więc totalnie nie rozumiem o co ci chodzi. Osobiście zdziwiła mnie przewaga Debiana/kFB nad FB i pozostanie dla mnie zagadką dlaczego widzisz jakąś optymalizację po Linuksa, skoro w testach zmiana jądra praktycznie jest niezauważalna.

Test jak test- acha z opisu wychodzi, że Debian miał domyślne jądro Linuksa (i386), a Debian/kFB miał optymalizację dla i686. Może to niedopisanie, ale pewnie i tak niewiele by zmieniło.

Nie wiem czemu od razu podpinasz ideologię.

> pozostanie dla mnie zagadką dlaczego widzisz jakąś optymalizację po Linuksa, skoro w
> testach zmiana jądra praktycznie jest niezauważalna.

A czasami wręcz się okazuje, że kFreeBSD jest wydajniejszy niż Linux.

Ta rzekoma optymalizacja to oczywiście wymysł, pakiety dla kFreeBSD są kompilowane inaczej niźli dla Linuksa.

Najśmieszniejsze zaś jest podnoszenie larum, że FreeBSD nie był optymalnie skonfigurowany, że stare lub testowe jądro, etc., jakby Debian GNU/* był skonfigurowany optymalnie i miał inne jądra.

Czyli w sensie wydajności debian k/freebsd jest już używalny ?

nie.

Poza tym chyba jest różnica jaki scheduler ma w kompilowane jądro..
Domyślne flagi FreeBSD, a flagi Debian/kFreeBSD są inne niż w artykule nie było, ze samemu kompilowali jadro i base system.. Domyśle innego schdeulera znajdziemy w FreeBSD, a innego w Debian/kFreeBSD itd.

Łe myślałem że można się przenosić .

/etc w debianie k/freebsd jest debianowskie czy bsdowskie ?

Niestety debianowe, choć kilka plików dotyczących bezpośrednio jadra BSD znajdzie się już w /etc. Niestety ładu znanego z FreeBSD niema i raczej się nie zapowida, ba jest jeszcze wieksze zamieszanie, bo nie wiadomo co gdzie szukać, czy bedzie to w jendym pliku czy w 3.. a dokumentacji brak. Ot taka ciekawostka.

Tragedia a powoli zastanawiałem się nad migracją na tego egzotyka , ale niestety pakiety to istotna sprawa ale /etc jak dla mnie jest najistotniejsze .

Z tym ładem to zależy co kto lubi.
Pamiętam, że 3bsd zakłada, że w /etc są ustawienia systemu /usr/share/etc programów a w /usr/local/etc (lub podobne ścieżki) programów zainstalowanych przez użytkownika. Ma to jakiś sens i milion lat temu w linuksie też tak bywało. Jednak dnia pewnego na drodze uzgodnień twórcy dystrybucji uznałi, że należy parę rzeczy inaczej uporządkować. Stwierdzili, że lepiej wszystkie ustawienia trzymać w jednym katalogu etc a nie trzech.

@bobycob: Nie ma /usr/share/etc. Rozdzial na /etc i /usr/local/cerb ma bardzo duzy sens – dzieki temu jest jasny podzial miedzy “rdzen systemu” i dodatkowe aplikacje. To jedna z tych rzeczy, ktorych w Linuksie brakuje, btw.

TY chyba nie, wiesz o czym piszesz.. w freebsd samba ma jeden plik, a nie dziesięć.. nikt niczego nie dziali nie potrzebnie na małe pliczki. A porządek zwiazany z plikami jądra, systemu, oprogramowania w freebsd jest wzorcowy.

@trash: Tylko w przypadku dystrybucji Linuksa taki model się nie sprawdza. Po pierwsze apt/yum wrzuca zazwyczaj binarki do /usr/bin.

Po drugie ciężko o rozróżnienie samego systemu (base) od programów – przecież nawet jądro jest pod kontrolą menadżera pakietów, podobnie GNU coreutils i tak dalej. Nie wspominając o tym, że userland jest zazwyczaj dosyć obszerny.

Po trzecie większość linuksowych dystrybucji celuje obecnie w desktopy. Tacy użytkownicy zazwyczaj tworzą jedną dużą partycję. Zresztą chyba automaty podczas instalacji sugerują takie rozwiązanie?

Podsumowując takie rozwiązanie nie ma większego sensu, jeśli chodzi o Linuksa. Natomiast systemy BSD to już inna bajka. Wiadomo co jest systemem, a co pochodzi z portów. Usunięcie lub zniknięcie /usr/local nie spowoduje większych konsekwencji (nie uszkodzi to samego systemu).

Co ciekawe FreeBSD, NetBSD i OpenBSD różnią na tle tego, gdzie znajdziemy pliki konfiguracyjne. W przypadku OpenBSD programy wrzucają wszystko do /etc, FreeBSD do /usr/local/etc. Natomiast NetBSD wrzuca wszystko prócz skryptów rc.d do /usr/pkg/etc.

Dlatego juz dawien dawno pisalem ze OpenBSD ma idealnie stworzona konfiguracje i pliki konfiguracyjne . Dlatego kazdemu kto glebiej chce poznac dzialanie i konfiguracje unixow polecam ten system . Jeszcze do tego ich FAQ , po prostu bajka <3

Ot wystarczy odhaszowac , choc w innych bsd tez jest grubo lepiej niz w linuxie i tworzenie smietnika pod pozorem “szturmu na desktop” mija sie z celem po prostu lenistwo i robienie na szybko przez programistow robia swoje .

“Kupa jest dobra – miliony much nie moga sie mylic”:P
Poczytaj sobie o benchmarkach linux z BFS.

a może jaśnie oświecony raczy się podzielić wiedzą

BFS jest faktycznie szybki shelderem , ale nikt nie zgodził się na wsadzenie go jako domyślny shelder w linuxie .

Mam nadzieje że go chociaż użyją w innym systemie

a co to jest shelder ?

Shelder to taki program na poziomie jądra który szereguje ci procesy , nadaje im priorytety , wyklucza konflikty między nimi , a czasem nawet może przydzielać im zasoby .

A nie scheduler?

Tak literowka xD

Nie chodzi o optymalizacje systemu, tylko samych benchmarkow.

Racja w standardowej konfiguracji i z wszystkimi opcjami zabezpieczeń. Niemniej można przecie zrobić testna szybkość wykonywania snapshotów – gwarantuje, że w FreeBSD będą przeprowadzane najszybciej. Zresztą jeśli chodzi o burst rate to FreeBSD bije na głowę Linux, jednak kupę pasma “marnuje” na zabiegi związane z bezpieczeństwem.

@krzabr: Jeśli chodzi o pojedynczy dysk i “zimny” zapis/odczyt, to rzeczywiście lepiej sprawdza się stary UFS2. Jednak należy pamiętać, że nie w takim celu został stworzony ZFS.

Po pierwsze ZFS to nie tylko system plików, ale także menadżer woluminów logicznych. Robi to ogromną różnicę w przypadku RAIDów o dużej objętości – ZFS ma pojęcie o logicznej strukturze macierzy.

Sekundo ZFS posiada możliwość cachowania (za ten zwrot przepraszam purystów językowych) zapisu/odczytu np. na szybkich dyskach SSD. Podobnej funkcjonalności niedawno dorobiło się DragonFly BSD i system plików HAMMER w postaci swapcache. Różnice w wydajności z włączonym i wyłączonym swapcachem były spore (nie chce mi się szukać odnośnika do porównania).

Podsumowując ZFS nie zostało stworzone z myślą o komputerach domowych.

Czym takie “cachowanie” (kaszowanie?:D) różni się od standardowego w linuksie?
Pamiętam kiedyś przeszukiwałem CD pod kąŧem określonego łańcucha, później drugie przy drugim wyszukiwaniu cd nie było już używane. Przeszukiwanie zostało błyskawicznie wykonane z pamięci kaszy

Cachowanie w ZFS z wykorzystaniem SSD poprawia czas dostępu do macierzy/dysku. Operacje zapisu sa wykonywane w pierwszej kolejnosci na dysku SSD (czas dostępu rzędu 1ms) a następnie dane sa w wolnych cyklach IO przesyłane na macierz.
Zwiększa to radykalnie ilość możliwych operacji zapisu w jedn. czasu – TPS. Natomiast poprawa przy ciągłym zapisie/odczycie dużych porcji danych jest niewielka.

@bobycob: Zastosowaniem. Blinkkinowi chodzi o cache devices, czyli szybki dysk (solid-state, na przyklad, tzn. takie cos z DIMM-ami w srodku podpinane przez SATA), ale stosunkowo maly (ze wzgledow ekonomicznych) dysk, na ktorym ZFS trzyma sobie najczesciej odczytywane dane. Cache’owanie w pamieci to osobny mechanizm.

a widzisz teraz rozumiem – niektórym trzeba jak krowie na rowie

@Blink : No właśnie dlatego przydatne by było wdrążenie do freebsd nowego szybkiego konwencjonalnego systemu plików bądz znaczne przyśpieszenie UFS2 , ot dla komputerów domowych i embeed .

@krzabr: W tym, co jest istotne, UFS2 nie jest wolniejszy od filesystemow dostepnych pod Linuksem. Oczywiscie zakladajac, ze uzywasz SUJ-a albo wlaczysz tryb async, tak jak w Linuksie.

Owszem jest dosc szybki , ale widac ze i ext4 i ntfs ostatnio przyspieszyly .

async – jeszcze nie stosowalem , ale jesli mowisz ze to pomaga z szybkoscia to chetnie go sprawdze .

Ale Core 2 Duo ma dwa rdzenie.

O szlachetna sztuko ironii, gdzieżeś ty, gdzieżeś?

pewnie pod FB ma 4 (2 dodatkowe za os), ale pod Debianem tylko 2;)

Na specyfikacji>/a> Intela ma tylko 2. Czterordzeniowe procesory mają oznaczenie Q9000/Q9100.

http://ark.intel.com/Product.aspx?id=33917

http://www.entity.cc/ICONS/free-emoticons.htm

@konski_pytong: proszę cię, wiem że bycie fanbojem wymaga poświęceń, ale nie zwalnia od myślenia. Jak masz napisać bzdurę, to nie pisz. Jak nie wiesz czym się różni Hyper Thread od rdzenia, to doczytaj nie racz ludzi swoimi przemyśleniami, bo ośmieszasz stajnię BSD.

Swoją droga przypominasz mi najka… czyżby kolejne wcielenie?

@konski_pytong: przepraszam ten procek nie ma HT. Powinienem jednak sprawdzić skąd znalazłeś w nim 4 rdzenie, ale błędnie jak wdać uznałem, że zwyczajnie pomyliłeś się a nie świadomie napisałeś bzdurę.

Przepraszam- następnym razem założę, że fanbojizm jest u ciebie dominującą nad myśleniem cechą, podczas komentowania tematów drażliwych.

Jesteś idiota, czy czytać nie potrafisz?
:] = ironia
azhag szukał ironii to mu ją dałem..

@konski_pytong: ironia subtelna jak u Palikota- i ten szanujący oponenta w dyskusji język- nic dodać nic ująć. Miszczu pełną parą- aleś nam pokazał…

PS.
Nauczka na przyszłość- nie podejmować z Tobą polemiki.

A jakiej polemiki oczekiwałeś z gościem, który ma kompleks małego ptaszka?

oj żebyś tylko ty miał taki “kompleks”

nie życz bliźniemu co tobie nie miłe

@krzy3: odpowiem zbiorczo tobie i Edkowi.

Benchmark, o ile mi wiadomo, ma mierzyć prędkość, z jaką benchmarkowane urządzenie/program/system/kernel wykonuje daną czynność. Jeśli na systemie A domyślne flagi kompilacji to i386 a na systemie B i686, to takie np. szyfrowanie będzie działało szybciej na systemie B. Oczywiście możliwe, że system B jest na tyle kijowy, iż różnica i tak będzie na korzyść systemu A – benchmark również to pokaże! Ogólnie, w temacie tego kompilowania benchmarków: nie ma kompletnie znaczenia, że są skompilowane z różnymi optymalizacjami, bo domyślne flagi również wpływają na wydajność _systemu_. Podobnie nie ma znaczenia to, że gdzieś jest starszy kompilator i można łatwo przekompilować cały system nowym – testujemy domyślną wydajność, period. Jak FreeBSD dorobi się clanga to Edek będzie pisał to samo

Oczywiście to o czym piszę nie wyklucza błędów na poziomie kodu benchmarka, które – jeśli mają miejsce – istotnie taki benchmark eliminują.

@Reddie: Ktorego slowa w “pomiary robione przez Phoronixa nijak sie maja do rzeczywistej wydajnosci mierzonej benchmarkami aplikacyjnymi” nie rozumiesz? Ok, wyjasnienie autorstwa krzy3 jest troche dlugie i wymaga minium wiedzy na temat teorii pomiarow i zasady dzialania komputerow, ale powyzsze zdanie powinno byc dosyc zrozumiale.

Mnie i tak zdziwiło że freebsd wypadło porównywalnie , spodziewałem się znacznie gorszych wyników a w przypadku debiana k/freebsd tragicznej wydajności więc nie jest aż tak źle .

@Edek: którego słowa w “pomiary robione przez Phoroniksa mają mierzyć wydajność systemu na domyślnej konfiguracji” nie rozumiesz?

Nie bo to nie logiczne. Robimy test “desktopowy”, a w szramki stają system desktopowy i system strikte serwerowy. Przecie nie trzeba tu nic testować, by znać odpowiedz co będzie szybsze. To jakby organizować wyścigi F1 i 4×4 na jednym torze..

> Benchmark, o ile mi wiadomo, ma mierzyć prędkość, z jaką benchmarkowane urządzenie/program/system/kernel wykonuje daną czynność.

Termometr który masz za oknem nie mierzy temperatury powietrza, tylko własną. Cała sztuka polega na tym, aby z jego wskazania móc wnioskować o temperaturze powietrza. Bo to jest akurat dla nas interesujące.

Podobnie benchmark mierzy prędkość wykonywania benchmarku. Cała sztuka polega na tym by tak zaprojektować testy, aby prędkość wykonywania benchmarku była w sensowny sposób związana z prędkością wykonywania zadać rzeczywistych. Jeśli chcemy mierzyć wydajność szyfrowania, to wynik nie powinien zależeć od rodzaju używanego linkera. Jeśli zależy, to znaczy, że albo w systemie coś jest fundamentalnie poknocone, albo że test jest zły. Ponieważ żadnego nie wyeliminowano, z doświadczenia obstawiam to drugie.

Niezgodności wyników które są w teście jednoznacznie wskazują na to, że benchmark Phoronixa nie mierzy nic poza czasem wykonywania benchmarku Phoronixa. Ergo wnioskowanie na jego podstawie o wydajności systemu w zastosowaniach rzeczywistych jest niemożliwe.

Addendum:

Jeśli chodzi o wpływ kompilatora, to w takich zastosowaniach jak szyfrowanie oczywiście ma on znaczenie i test powinien go uwzględniać. Ale Phoronix zrobił 2 testy na szyfrowanie: jeden GNUPG, a drugi GCryptem — i dostal rozbieżne wyniki. Kompilator był ten sam, więc należy uznać, że jeden z testów był wadliwy. Obstawiam, że wadliwy był test z GCryptem i w rzeczywsitości mierzył wydajność linkera.

P.S. Jak widzę wyniki testu z GCryptem zostały już ze strony skasowane. Hehehe.

@konski_pytong: Debian desktopowy? Toś przywalił…

@krzy3: Dziękuję za rzeczową odpowiedź. Jak dla mnie temat wyczerpany

To porównaj prace planisty w dowolnym linuksie a w freebsd, oraz ilość softu strikte desktopowego.

Debian i FreeBSD maja zblizona liczbe domyslnych paczek , zblizone zastosowania oraz targety , jedyny plus to moze to ze debian moze domyslnie zainstalowac srodowisko graficzne z poziomu graficznego , w fbsd trzba troche pogrzebac zeby to zrobic .

Wiec imo testy i porownania obu systemow maja sens , no chyba ze ktos mi wyskoczy ze targetem fbsd nie sa serwery ? TO w takim razie co ? Skoro embeed jest w powijakach , rt ten system nigdy nie byl , a na desktop trzeba szukac innego distra .

@krzabr: Embedded. Serio. Embedded FreeBSD napedza cala mase sprzetu, od wiekszosci routerow szkieletowych (Juniper), przez duza czesc enterprise’owych NAS-ow (NetApp, Isilon), roznych IDS-ow, IPS-ow i EPS-ow (NETASQ, Niksun, Packet Forensics). Nawet Silicon Graphics sprzedaje sprzet chodzacy na pochodnej FreeBSD do serwowania storage’u swoim linuksowym klastrom.

To oczywiscie “duze” embedded. “Małe” embedded we FreeBSD zrobilo w ciagu ostatniego roku ogromne postepy (w pelni funkcjonalne sa porty na MIPS, MIPS64, ARM oraz PowerPC/PowerPC 64), ale niespecjalnie jest jeszcze kojarzone przez potencjalnych klientow.

@Edek: to, co wymieniłeś, jest napędzane nie FreeBSD a zamkniętymi forkami FreeBSD.

@Reddie: Bez znaczenia – to, co jest z Linuksa w embedded, to tez zwykle jakies przyciete na miare forki, a nie waniliowy kernel.

@krzy3: “Reasumując — twórca tego testu za moich czasów wyleciałby ze studiów na pierwszym roku na pracowni fizycznej, najpóźniej na drugim na miernictwie.”

Uważaj, żebyś nie zdeżył się z samolotem, nosząc głowę wysoko w chmurach. Mało kogo interesują Twoje nudnawe informatyczne studia.

Tfu, elyty, tfu!

Widac tam embeeded nabiera nowego znaczenia

Na maly embeed podzial od lat jest niezmienny – Systemy RT , Systemy Wbudowane na Forkach Linuxa i NetBSD .

Reddie – Jest tez mnostwo malych urzadzen napedzanych forkami linuxa , tak odleglymi od glownej galezi ze maja osobne , api , scheldery a kompilowane sa przez zupelnie dziwaczne kompilatory C

@krzabr: no i co z tego?

To że przypieprzasz się do zamkniętych forków Fbsd , a w linuxie embeeded powstają podobne twory . Ot np dynamicznie ładowane zamknięte moduły do jądra . Tylko inaczej się to nazywa , ale strategia działania niemalże identyczna .

@krzabr: ale co z tego że powstają? Czy ja podaję je jako argument na to, że embedded jest targetem Linuksa albo że Linux jest na tym odcinku intensywnie rozwijany? Bo Edek podaje.

Nawet argument “u was biją murzynów” trzeba umieć stosować.

Reddie 29 lipca 2010 o godz. 0:32 #

@Edek: to, co wymieniłeś, jest napędzane nie FreeBSD a zamkniętymi forkami FreeBSD.

Reddie 30 lipca 2010 o godz. 16:45 #

@krzabr: ale co z tego że powstają? Czy ja podaję je jako argument na to, że embedded jest targetem Linuksa albo że Linux jest na tym odcinku intensywnie rozwijany? Bo Edek podaje.

Nawet argument “u was biją murzynów” trzeba umieć stosować.

Czasem czytaj co sam piszesz

@krzabr: czytaj ze zrozumieniem, zawsze.

źdatyzc mejmó ejN

Ein Reich ! Ein Volk ! Ein Gnu !
Hejl Stallmann ! Hajlł Konkin !