Niemal równolegle wydano nowe wersje dwóch systemów z rodziny BSD: OpenBSD 4.8 oraz DragonFly BSD 2.8.2.
Zmiany OpenBSD 4.8:
- Poprawa wychodzenia z trybu suspend dla maszyn z kartami graficznymi Nvidii, Intela oraz ATI.
- Sterowniki dla Sony ACPI, kart sieciowych SIS, RTL8168E oraz Intela.
- Umożliwiono sprzętową akcelerację graficzną w procesorach core i3/i5.
- Naprawa lockingu w sterowniku NTFS (sterownik jest nadal w fazie eksperymentalnej).
- Dodanie demona LDAP
.
- Aktualizacja IKE do wersji drugiej, Mandoca do wersji 1.10.5 oraz OpenSSH do wersji 5.6.
- Drobne zmiany w demonach routingu, SCSI oraz stosie graficznym.
- Możliwość kompilacji OpenBSD za pomocą zwykłego GCC4 na większości architektur (OpenBSD standardowo korzysta z własnej wersji GCC).
Zmiany w DragonFlyBSD 2.8.x są raczej kosmetyczne, jednak z racji ominięcia faktu wydania linii 2.8 na OSnews.pl opiszę ją bliżej.
DragonFly BSD jest forkiem FreeBSD nastawionym na multiprocesorowość i
HPC, z tego powodu główne podsystemy zarządzające procesorami,
pamięcią oraz dyskami zostały całkowicie przepisane. Zaimplementowano w
nim też nowoczesny system plików HAMMER, z punktu widzenia użytkownika
zbliżony do ZFS.
Główne zmiany w wydaniu 2.8:
- Możliwość szyfrowania dysków obsługiwanych przez systemy plików UFS oraz HAMMER w tym partycji /root.
- Ulepszenia w SMP – wprowadzenie softlockingu dla AHCI oraz stosu sieciowego, ma to zwiększyć odporność na błędy oraz uniezależnić sterownik dysku od stosowania lockingu.
- Aktualizacja stosu sieciowego dla Wi-Fi (przeportowana z FreeBSD).
- Aktualizacja Packet Filter do wersji 4.2 (port z OpenBSD).
- Przyspieszenie działania całego systemu min. dzięki redukcji ilości sprawdzanych sum kontrolnych.
Z wieści dodam też 2 rzeczy odnośnie FreeBSD.
1) Praca w chmurze – devowie tego systemu podeszli do tego tematu poważnie i powstaje pierwsze komercyjne rozwiązanie stosujące freebsd w tej dziedzinie.
http://www.freebsdnews.net/2010/11/02/cloudsigma-launches-freebsd-8-1-zfs-cloud/
Dodatkowo jeden z developerów stworzył distro freebsd skrojone pod chmurę :
http://www.shiningsilence.com/dbsdlog/2010/10/22/6650.html
2) Letni Raport Kwartalny dla tego systemu :
http://www.freebsdnews.net/2010/11/02/freebsd-quarterly-status-report-jul-%E2%80%93-sep-2010/
*BSD Rulez! 🙂
HAMMER jako system plików implementuje wiele ciekawych pomysłów, ale ma wprost kuriozalne ograniczenia…
Jeszcze go nie testowałem (HAMMERA), Dfly w tym samym celu co OpenIndiane – czyli przetestowania Draco/llvm pod danym systemem 🙂
Ważne że próbują coś nowego wprowadzić wiem że to ryzykowne , ale lepsze to niż tylko zmieniać menadżer okien / pakietów.
Zwłaszcza że Dilton nie raz udowodnił że na pisaniu osów zna się bardzo dobrze – więc o przyszłość jego projektu się nie obawiam.
@Reddie: O jakie ograniczenia ci chodzi? Zapewne o reblocking w crontabie, który może być problematyczny jeśli korzysta się z laptopa odpalanego na kilka godzin dziennie etc.
Co do HAMMERa to zamieszczałem mały przykład na co pozwala ten system plików, na swojej stronie.
@blinkkin: tak, to główne ograniczenie 🙂 O ile rozumiem, że DragonFly jest systemem serwerowym, tak systemy plików z wbudowaną funkcją snapshotów mają przyszłość również na desktopie. Niestety podejście HAMMERa takie zastosowanie praktycznie wyklucza, a szkoda, bo byłaby ciekawa alternatywa dla ZFS bez patentów Oracle 😉
@Reddie: HAMMER posiada „fine-graned history” (brakuje mi dobrego polskiego odpowiednika). System plików zachowuje się bardzo podobnie jak systemy kontroli wersji (git, cvs etc) tylko bez branchów i mergowania. Oznacza to, że w łatwy sposób można uzyskać dostęp do historycznej wersji pliku – każda zmiana, jaka mieści się w obrębie ustawień.
Przykład praktyczny: serwer PostgreSQL. Normalnie dumpy bazy danych zapisywane były by jako nazwa_pliku-data. Można oczywiście wykorzystać np. gita i po prostu nadpisać plik i zrobić commita. Jednak otwarto źródłowe systemy kontroli wersji kuleją, jeśli chodzi o duże binarne pliki – Perforce daje rade. I tutaj z pomocą przychodzi HAMMER – po prostu nadpisujemy backupa, a dostęp do historycznych wersji można uzyskać m.in. za pomocą undo.
Snapshoty natomiast to tylko symboliczne odniesienia do numerów transakcyjnych o których pisałem na swojej stronie. To co robi reblocker to ucinanie niepotrzebnej historii (30+ dni etc). Optymalnie HAMMER powinien wykorzystywać maksymalną „objętość” dysku.
Problem z reblockerem pojawia się w przypadku maszyn, które działają kilka godzin dziennie – zadanie w crontabie może się nie uruchomić. W tym przypadku dysk może zapełnić się naprawdę szybko. Istnieje jednak możliwość ręcznego odpalenia „hammer cleanup”. Rozwiązaniem pewnie mógłby być demon, który czyści niepotrzebną historię stopniowo, a nie skokowo. Ku takiemu rozwiązaniu składania się nawet Matt Dillon.