osn.jogger.pl

W wiadomości o ficzerach FreeBSD 8 Paweł i Trasz zrobili sobie małego flejma próbując jeden drugiemu udowodnić dlaczego to ich system jest fajniejszy. Ten flejm jak i cała reszta nie wniosą raczej nic do poprawy systemów operacyjnych (chyba, że Trasz zacznie tuningować FreeBSD w kierunku rozwiązań używanych w Linuksie w co wątpię :)), jednak często skłaniają ludzi do gdybania – "a co by było, gdyby mój system to miał?".

Wiem, że temat systemów operacyjnych nie jest super ekscytujący dla większości ludzi – ot używa się tego i tyle. Czasami wchodzi się w różne techniczne zagadnienia budowy poszczególnych os'ów i poznaje technologie, jednak na co dzień nie przykładamy do tego większego znaczenia co tak naprawdę siedzi "pod maską". Ale czy to oznacza, że nigdy się nie zastanawialiśmy co chcielibyśmy mieć w systemie, którego używamy? Jeśli moglibyście zaprojektować system z klocków lego, to co byście do niego włożyli? Na co byście postawili w swoim ultimate operating system?

Ja z niejednego pieca chleb już jadłem i moje zdanie na temat designu systemu operacyjnego wygląda tak, że dla użytkownika końcowego i tak liczy się przede wszystkim spora baza programów oraz sterowników. Czego mi brakuje w systemie, którego używam na co dzień na desktopie? Braku wirusów i innego malware – reszta jest ok. Może tylko by się przydało wsparcie dla wielu różnych systemów plików :). System którego używam do serwerów niestety nie ma ZFS (przydatna bestia) – z reszty jestem raczej zadowolony – o ile tylko można być zadowolonym z systemu operacyjnego. A czego Wam na co dzień brakuje w Waszych systemach?

W ramach prac nad MikeOS w wersji 3.4 alpha został udostępniony interpreter języka BASIC. W wersji 3.4 beta1 interpreter został włączony do jądra systemu.

Bardzo dyskusyjną sprawą odnośnie designu systemów operacyjnych jest włączenie interpretera języka BASIC do jądra systemu – nie kojarzę drugiego systemu z takim ficzerem. Jednak na pewno dołączenie interpretera zwiększy znacząco ilość programów dostępnych na ten system – Mike myśli głównie o grach :). Trzeba tylko poczekać na to aż możliwości języka wyjdą trochę poza podstawowe polecenia PRINT LET ALERT INPUT GOTO GOSUB RETURN CLS CURSOR REM END...

Wszystkich zainteresowanych tym OS'em zachęcam do pobrania najnowszej paczki.

Dzisiaj została udostępniona wersja BETA1 systemu FreeBSD 8. Przyjrzyjmy się ciekawszym zmianą jakie są wprowadzane w nowej wersji jądra.

Duże zmiany w stosie USB:

• nowe API wspierające muteksy
• wiele sterowników przestało używać giant lock
• warstwa kompatybilności z linuksowym USB
• nowy backend UGEN i biblioteka libusb
• nowy usbconfig ułatwiający konfigurację
• i wiele innych

Lepsze wsparcie dla wyciągania zamontowanych urządzeń
Użytkownicy często zgłaszali błędy jądra wynikające z odłączania na ciepło urządzeń bez wcześniejszego odmontowania znajdującego się na nich systemu plików. Może niezbyt ekscytujący ficzer, ale deweloperem jest nasz rodak – Edward Tomasz Napierala, który jest znanym, lecz często wyszydzanym ekspertem od systemów operacyjnych.

Zwiększony limit pamięci jądra na AMD64
Limit pamięci z której może korzystać jądro systemu został zwiększony z 2 do 512 GB. Dawne ograniczenie potrafiło bardzo przeszkadzać użytkownikom ZFS.

Jails v2
Nowa wersja Jails otrzymała kilka fajnych ficzerów jak:

• wsparcie dla TCP/IPv6
• wsparcie dla wielu adresów ip
• wsparcie dla SCTP
• możliwość ograniczania jaila do określonych procesorów

Lekkie wątki dla jądra
Zmiana z wątków wagi ciężkiej na wątki wagi lekkiej używające mniej pamięci oraz wymagające mniejszej ilości operacji blokowania.

Planista ULE 3.0
Planista będzie teraz działał bardziej inteligentnie dzięki wykorzystaniu informacji o dostępnych procesorach takich jak ilość pamięci cache, rdzeni czy obecność HT. Ulepszono też możliwości bindowania procesów do określonych procesorów za pomocą cpuset.

FreeBSD 8 przyniesie dużo więcej zmian z którymi można się zapoznać czytając artykuł What's cooking for FreeBSD 8.

Czekając na zgodę JM na publikację tłumaczeń postanowiłem opublikować pierwsze z nich (jak się nie zgodzi, to zostanie usunięte :))

Oryginalną wersję transkrypcji można znaleźć na stronie www.kernelpodcast.org.

02/07/2009, nazywam się Jon Masters a to jest podsumowanie dzisiejszego ruchu na LKML.

W dzisiejszym odcinku: cgroups, kmemleak, OOM, VFAT oraz powrót Zero Page.

Cgroups. Paul Menage wysłał serię łatek RFC, które mają dodawać rozszerzenia hierarchii dla grup kontrolnych. Dzięki tej serii możemy otrzymać nazwaną hierarchię grup kontrolnych, hierarchię bez przywiązanych podsystemów oraz podsystemy cgroup które mogą zostać powiązane z wieloma hierarchiami. Przykładowe zastosowania zostały wysłane razem z serią, która zawiera 9 łatek.

Kmemleak. W celu zmniejszenia błędów pierwszego rodzaju (false positives – gdy kmemleak twierdzi, że coś jest wyciekiem pamięci a tak naprawdę wszystko działa w porządku) Catalin Marinas wysłał łatkę, dzięki której zaalokowane obiekty będą lepiej obsługiwane podczas skanowania kmemleakiem. Dzięki łatce kmemleak będzie sprawdzał czy alokacja została wykonana po tym jak zaczął skanować listę. Jeśli tak, to przeskanuje listę ponownie i powtórzy test alokacji zanim zgłosi problem. Jeśli system jest zbyt zajęty żeby przeskanować daną listę kmemleak da za wygraną po określonej ilości prób (25 w wysłanej łatce). Z tą łatką (i prawdopodobnie innymi – nie było to sprecyzowane) Catalin otrzymuje wiele raportów na temat wyciekającej pamięci w iwlwifi i nie jest pewien czy te raporty są tylko szumem czy prawdziwym błędem, który wymaga usunięcia. Catalin dodaje "Nie jestem zaznajomiony z tym kodem więc każda pomoc będzie mile widziana". Możliwe, że ktoś pomoże i rzuci okiem na ten sterownik.

OOM. Minchan Kim dołączył do toczącej się debaty o tym dlaczego konkretna łatka (która miała mieć wpływ tylko na maszyny bez swap) wywołała wiele sytuacji OOM gdy teoretycznie łatka poprawiała wydajność odzyskiwania stron do momentu, gdy zostaje użyty specyficzny test wystawiający system na fork bomb. Minchan wyciągnął wniosek, że David Howells "miał szczęście" przy używaniu nieproduktywnego algorytmu i poinformował, że Rik van Riel pracuje aktualnie nad przyspieszoną wersją odzyskiwania stron, która powinna pomóc.

VFAT. Nadal toczy się dyskusja nad implementacją VFAT. James Bottomley i Alan Cox dyskutowali na temat w jaki sposób producenci powinni dostarczać łatki spoza drzewa. Alan uważa, że producenci dystrybucji i tak dostarczają łatki nie zważając na życzenia społeczności rozwijającej jądro, więc jedna dodatkowa nie będzie wielkim problemem. Z kolei James jako kontrargument przedstawił, że to jest sprzeczne z ideą że społeczność rozwijająca jądro jest przeciwna rzeczom długo rozwijanym poza drzewem (tu chodzi chyba o jakieś łatki, które dany producent miałby trzymać tylko dla siebie a nie na przykład o reiser4 – przyp. tłum.). James bronił zaangażowanie Linux Foundation przeciw czemuś co opisał jako "teorie spiskowe". Później Jan Engelhardt, Ted Ts'o i Andrew Tridgell prowadzili rozmowę skupioną nad ilością urządzeń z którym Jan miał problemy po użyciu zmodyfikowanych wersji VFAT przy pomocy łatek będących aktualnie w obiegu.

Zero Page (ponownie). Kamezawa Hiroyu napisał odnośnie usunięcia (w 2.6.24 w październiku 2007) wsparcia dla zero page (umożliwiającego takie rzeczy jak alokacja rzadko rozsianych tablic w przestrzeni użytkownika, które inaczej byłyby ciągłe) – na razie niewielu z jego użytkowników to zauważyło, ponieważ ciągle używają jąder w stylu 2.6.18 z Red Hat Enterprise Linux 5. Ponieważ jest wielu świadomych użytkowników zero page (do których Avi Kivity później dodał KVM w kontekście jego procesu migracji) zasugerował reimplementacje która naprawi problemy ze zliczaniem referencji i inne wady, które posiadała stara wersja.

Więcej informacji można znaleźć w oryginalnej transkrypcji. Zachęcam do wysłuchania podcastu.