Wydano kolejną wersję wysoce przenośnego systemu operacyjnego NetBSD. Wprowadzono wiele zmian, główny nacisk położono na wirtualizację w xenie, poprawki do jądra oraz lepszą współpracę systemu z X.org.
Zmiany obejmują.
System:
- Znaczne ulepszenie działania systemu w Xenie dodano m.in. obsługę PCI pass-through oraz i386PAE w dom0.
- W jądrze dodano poprawki do planisty, poprawiono zgodność z POSIX-em, uodporniono system na panikę jądra w przypadku załadowania uszkodzonego modułu ELF, drobne poprawki w FFS.
- Usprawniono współpracę z systemami plików innymi niż FFS.
- Aktualizacja podsystemu graficznego X.org.
- Usprawnienie biblioteki wątkowania.
Sterowniki:
- Dodanie nowych sterowników sieciowych, dźwięku, usprawnienie działania sterowników dysków.
- Mapy parzystości w RAIDframe poprawiające wydajność ponownego zapisu po nieczystym wyłączeniu systemu.
- Poprawka usprawniająca działanie systemu w przypadku korzystania z hubów USB i czytników kart.
- Wsparcie dla procesorów Intel Core i7, Atom i Xeon.
Architektura Sparc64:
- Naprawa regresji dyskowej przy dużym obciążeniu.
- Dodanie sterownika sunleo.
- Wprowadzenie monitora urządzeń dla tej architektury.
- Poprawki dotychczas wykrytych błędów i mniejsze zmiany na różnych architekturach.
System jest dostępny dla ponad 50 architektur.
Wydanie to jest dedykowane tragicznie zmarłemu w wypadku drogowym wieloletniemu developerowi PkgSrc i NetBSD – Marttiemu Kuparinenowi.
Mirrory obrazów ISO.
Od dawna jestem sympatykiem tego systemu, jednak FreeBSD posiada odrobinę więcej sterowników. W tym wydaniu w końcu działa moja sieciówka bezprzewodowa na Atherosie (Samsung NC10), ale wciąż nie ma sterownika do Ethernetu (Marvell Yukon, bug zgłoszony kilka miesięcy temu, a można go przeportować z FBSD, bo tam jest).
Od literówek i błedów to jest formularz zgłaszania. Może jakieś komentarze na temat newsa?
Brak sterowników jest główną przyczyną dla której *BSD nie gości na moim dysku na stałe.
Na marginesie: nie przesiadają się na Wayland?;) Bo odniosłem wrażenie, że nie są zadowoleni z x.org(nikt nie jest).
> przypadku załadowania uszkodzonego moduły ELF
Pyrrusowe zwyciestwo. Kernel jako taki przezyje, ale
system bez ELF i tak w praktyce jest bezuzyteczny.
Prawdopodobnie chodzi o systemy wbudowane gdzie jest uruchomianych stale kilka programów i w razie niedopatrzenia przy „stawianiu” embeedu , system mógł działać i dalej wykonywać te programy.
„przenośny system operacyjny” – trochę to dziwnie brzmi. a co by oznaczało że system jest „nieprzenośny”…
@makak – Znając życie freebsd stworzy fork waylanda który jest w obecnej chwili zbyt mocno związany z kernelem linuxa , kwestia czasu zwłaszcza że mają zasoby , reszta rodziny BSD jest mniej lub bardziej zależna od standardowych narzędzi.
Ostatecznie jak xws kogoś bardzo denerwuje może zainstalować microwindows lub coś podobnego , działa całkiem nieźle 🙂
http://www.netbsd.org/about/portability.html
@b. – Duże systemy (monolity) są bardzo trudne w przenoszeniu , specjalnie w tym celu tworzy się gałęzie jądra , sheldery , narzędzia , api , pół userlandu a nawet specjalne kompilatory pod daną architekturę.
NetBSD jest inne , tu API , kernel , userland , pakiety a nawet planista jest wspólny dla wszystkich arch. Wszystko w jednym wielkim drzewie kodu , co na tak rozbudowany system jest ewenementem.
O przemyślanych podstawach świadczy chociażby fakt że 2 kolejne systemy pod względem przenośności mają tylko 26 (Contiki OS) i 13 (RTEMS) architektur , systemy które są znacznie mniejsze i są prawdę mówiąc ascetyczne (rtems).
Ukazuje to z jak dobrze zaplanowanym i trzymanym systemem mamy do czynienia , fakt na desktop wypada blado ale w embeed króluje i jak masz stare urządzenie które chcesz ożywić to najpierw przeszukaj dokumentacje netbsd czy ktoś nie zrobił już takiego portu 😉
Niewykluczone też że jak dalej devovie NetBSD będą tak uparci i zdeterminowani to doczekamy się wspólnego kompilatora pod wszystkie obsługiwane przez nich architektury – PCC , fakt to odległa przyszłość ale technicznie możliwa , zwłaszcza mając takich ludzi , a uwierzcie mi taki kompilator ułatwiłby życie wielu programistom.
> NetBSD jest inne , tu API , kernel , userland , pakiety a nawet planista jest
> wspólny dla wszystkich arch. Wszystko w jednym wielkim drzewie kodu , co na
> tak rozbudowany system jest ewenementem.
Ze co?? API, kernel, userspace i scheduler sa wspolne we wszystkich
OSach z jakimi mialem do czynienia bez wzgledu na platforme.
No właśnie nie bardzo samo api z punktu widzenia programisty wygląda niemal identycznie jednak sama implementacja na różnych architekturach może być różna.
Kernel również, dla przykładu uClinux jest znacznie mniejszy i wiele elementów jest napisanych od zera aby działały, znowu z punktu widzenia nie sysdevelopera wszystko wygląda identycznie.
Scheduler – w samym tylko linuxie znam 3 – BFS , CFS i główny prowadzony przez Torvaldsa.
Userspace – j/w w samym linuxie nie distra gnu/linuxa mają różne US , przykładowo pakiety deb debiana działają na zmodyfikowanym jądrze freebsd czy hurda a nie działają na wielu distrach , dlaczego ? Mają własną kombinacje US , nie będę wspominał o takich dziwadłach jak rythmbox , android czy uClinux gdzie większość systemu jest zaprojektowana pod distro, a pokrewienstwo między nimi a mainline jest niewiele mniejsze niż dfly a freebsd 🙂
//Edit co do api przypomniała mi się sytuacja z opensolarisem na porty system z i arm gdzie część aplikacji trzeba było przebudowywać na poziomie kodu źródłowego a wiele elementów pisać od zera 🙂
Nie scheduler tylko schelder;)
@krzabr, nie wiem, czy mam teraz powaznie traktowac co tam popisales. Zwlaszcza
o tych strasznych zmianach w API pomiedzy platformami, KONKRETY poprosze tutaj.
Wtret o roznych wersjach schedulera pozostawie bez komentarza.
W obu przypadkach, najwyrazniej nie odrozniasz gdzie konczy sie
kod zalezny od platformy a gdzie nie.
Jak gdzies wczesniej sam napisales, zamiast trolowac przejrzyj sobie
choc pobieznie zrodla linucha czy solarisa.
Na pewno o to chodzi? Myślałem, że to nie dotyczy samego modułu do obsługi czegokolwiek w formacie ELF, tylko pojedynczych modułów skompilowanych do formatu ELF, które mają być ładowane do jądra.
Akurat na źródła linuxa miałem okazje rzucić okiem , jakoś tak się składa że kod niektórych architektur jest trzymany w osobnych gałęziach i z tego co wiem w mainline kernel ma moduły dla danej architektury i podczas kompilacji są one wybierane.
Z OpenSolarisem dla systemu Z i ARM było podobnie , dla przykładu ARM zmiany były duże – statycznie zlinkowane jądro , wyzbycie się ładowania modułów , podmiana ZFS na CZFS , czy zaniechanie niektórych rozwiązań w jądre.
Co do przenośności proszę bardzo zwykła funkcja pthreads jest inaczej zaimplementowana w zależności od architektury,.
Co do planisty – radzę sprawdzić z jakiego korzysta android.
> niektórych architektur jest trzymany w osobnych gałęziach i z tego co wiem w
> mainline kernel ma moduły dla danej architektury i podczas kompilacji są one
> wybierane.
Kod specyficzny dla wszystkich architektur jest
w kernelu linucha trzymany w podkatalogu arch:
$ ls -1 /usr/src/linux-2.6.31.13/arch | head -5
alpha
arm
avr32
blackfin
cris
W NetBSD zupelnie podobnie:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/
> Z OpenSolarisem dla systemu Z i ARM było podobnie , dla przykładu ARM zmiany
> były duże – statycznie zlinkowane jądro , wyzbycie się ładowania modułów ,
> podmiana ZFS na CZFS , czy zaniechanie niektórych rozwiązań w jądre.
Od kiedy OpenSolaris oficjalnie wspiera ARMa? Afair to SPARC i Intel.
Notabene organizacja zrodel kernela Solarisa jest troche inna niz
linucha czy nietbsd, ale idea oddzielenia zrodel specyficznych dla
platform od wspolnego codebase tez oczywiscie tam jest.
> Co do przenośności proszę bardzo zwykła funkcja pthreads jest inaczej
> zaimplementowana w zależności od architektury,.
1. Pthreads to nie funkcja, to funkcjonalnosc.
2. Pthreads w linuchu i solarisie sa jak najbardziej zaimplementowane
w sposob przenosny, przestan siac FUD.
3. Na najnizszym poziomie, wielowatkowosc musi byc zaimplementowana
w sposob zalezny od architektury. Rozne procesory dostarczaja roznych
mechanizmow do uzyskanie atomicznosci i wylacznosci, stad mikroskopijna
czesc wielowatkowosci musi byc zalezna od platformy.
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/include/lock.h
static __inline int
__cpu_simple_lock_try(__cpu_simple_lock_t *lockp)
{
…
val = __SIMPLELOCK_LOCKED;
__asm volatile („xchgb %0,(%2)” :
I w linuchu zupelnie podobnie, dla x86 uzywa sie xchgb, dla innych
architektur sa to inne podkatalogi z innymi implementacjami.
> Co do planisty – radzę sprawdzić z jakiego korzysta android.
Od kiedy scheduler androida jest w drzewie zrodel linucha?
Sluchaj, jak sforkuje NetBSD pod jakas specjalizowana platforme to ktos
bedzie mogl powiedziec „hej, NetBSD jest nieprzenosne bo ktos tam zrobil
jakiegos forka i wymozdzyl sobie nieprzenosny scheduler”.
Tu masz pliki sched* dla linucha:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=tree;f=kernel
Ktore konkretnie kawalki w nich sa nieprzenosne?
Ano , widać byłem w błędzie.
Tylko w takim razie co mam rozumieć jako przenośność netbsd ?
Gdyby nie był taki przenośny w porównaniu z linuchem czy innymi systemami to jego twórcy nie chwalli by się tym .
O to mi chodziło – na niskim poziomie schelder , większość funkcji , przerwań czy odnoszenie się do sprzętu może być inne , dlatego powstały wysokopoziomowe interfejsy aby końcowy programista nie musiał sobie tym zaprzątać głowy i jego program działał na możliwie wielu architekturach , choć bebechy mogą być inne zależnie od architektury.
> Tylko w takim razie co mam rozumieć jako przenośność netbsd ?
Moze to taka sama propaganda jak z ta rzekoma linuksiana stabilnoscia
i bezpieczenstwem, tak samo utarlo sie i powtarza sie, ze NetBSD
jest super przenosne a inni sa sto lat za nim.
Chyba glowna roznica to to, ze systemy takie jak Darwin, Winda, Solaris
i Linux sa napedzane przez firmy. Ich rozwoj jest dyktowany modelem
biznesowym a nie hobbystycznymi pobudkami paru kolesi jak w NetBSD.
To, ze np Solaris wspiera tylko SPARC i Intel nie wynika z tego, ze
jest skopany. Jaki interes mial SUN w ladowaniu czasu i zasobow ludzkich
w obsluge niszowych platform takich jak iyonix, pica, walnut czy co tam
jeszcze wspiera NetBSD? (nawet nie wiem co to za platformy sa)
Polecam prezentacje Davida Maxwella pod tytułem The NetBSD Way – sporo tam porównań z Linuksem, ale bez zbędnej propagandy. Temat przenośności jest opisywany mniej więcej od 17 minuty.
Takie GCC wspiera np. PDP-11 czy VAXa, nie wiem po jaką cholerę?
„linuksiana” stabilność i bezpieczeństwo to nie jest taka znowu wielka propaganda, w tym sensie że nic bardziej stabilnego ani bezpieczniejszego nie ma. (Co można dowieść – nikt znający się na rzeczy nie postawi np. firmowego routera/firewalla w oparciu o komputer z windowsem. Większość kupi sobie gotową skrzynkę, a w niej będzie coś opartego na linuksie).
Określenie „przenośność” netbsd jest trochę niefortunne. Czyli chodzi o to, że ten system operacyjny może być zainstalowany na wielu platformach sprzętowych, może obsługiwać wiele różnych typów/rodzin układów mikroprocesorowych.
Ta dyskusja ma jeden fajny motyw – można dzięki niej uzmysłowić – o czym się zapomina czasem – jak bardzo działanie komputera jest uzależnione od budowy procesora, jak architektura, czyli fizyczny sposób działania procesora determinuje „wygląd” oprogramowania… Myślimy o tym jak o czystej abstrakcji, a to po prostu urządzenie elektryczne, tyle że bardzo skomplikowane.
przenośność NetBSD polega na tym, że obsługuje najwięcej różnych komputerowych „architektur” i jest to, owszem, jest propaganda, ale (jak się zdaje) zupełnie prawdziwa. Podobnie jak ta o stabilności „linuksa” (systemy bazujące na linuksie na ogół są bardzo stabilne).
Tak, tylko, że ta „przenośnosć” nie wynika z jakiejś szczególnie wyrafinowanej konstrukcji systemu, tylko z faktu, że twórcom NetBSD wciąż chce się kompilować system na sprzęt typu PDP-9, natomiast twórcom innych systemów chce się trochę mniej.
@Jarek
Obsługa ARM i PowerPC by jednakowoż nie zaszkodziła, prawda…?