Tak, w tym miesiącu mamy drobne opóźnienie. Arne Babenhauserheide, który zainicjował sam projekt i tworzył pierwsze szkice wszystkich comiesięcznych wiadomości na temat Hurda od czerwca 2009 (tak, to już półtora roku!), zajął się innymi obowiązkami — jego żona urodziła pierwszego potomka dewelopera Hurda (wg naszej najlepszej wiedzy): – W zeszły piątek mój syn Leandro wkroczył do naszego zimnego i zbyt jasnego, acz przyjaznego świata, (...)

Życzymy im powodzenia w nowych obowiązkach rodzicielskich!

Thomas Schwinge, który dotychczas współtworzył i publikował wiadomości, przejmie ten obowiązek — przynajmniej tymczasowo (miej to na uwadze, Arne).

Ale mamy też jakieś informacje o Hurdzie, jak najbardziej.

Olaf Buddenhagen opublikował łatkę, która pozwala uzyskać liczbę portów proc i libps aby dodać nowy RPC — w wyniku czego zainicjował dyskusję z Samuelem Thibaultem, który złożył propozycję, aby zamiast dodawać tę funkcjonalność sformułowaną ad hoc, poszukać bardziej ogólniejszego rozwiązania. W końcu zgodzili się, że owa funkcjonalność jest wystarczająco przydatna i łatka została zatwierdzona.

Istotnym jest aby dobrze projektować interfejsy (w tym wypadku do RPC), jednak z drugiej strony to co obecnie tworzymy nie musi trwać wiecznie, co wyjaśnia Olaf Buddenhagen: – Cóż, już posiadamy mechanizm do tworzenia protokołów komunikacyjnych: nazywa się on RPC... :) Postarajmy się nie wynajdywać kolejnego ogólnego mechanizmu ponad RPC – pisze na liście dyskusyjnej – Jeśli za dziesięć lat rzeczywiście skończymy z pół tuzinem różnych sposobów pobierania informacji, nadal będziemy mogli je zastąpić nowym RPC spełniającym ich zadanie...

Thomas Schwinge przeniósł kilka pakietów (gopherfs, netio, tarfs) z repozytorium hurdextras do inkubatora; dostępne one są już jako pakiety dla Debiana GNU/Hurda. Tarfs i gopherfs zostały doprowadzone do używalności przez Manuela Menala.

Podobna procedura spotkała nową implementację procfs stworzoną przez Jérémie'ego Koeniga; jest ona już używana w Debianie GNU/Hurdzie.

Jérémie Koenig odnalazł pewne problemy podczas dostarczania sygnałów — okazuje się, że nie są dostarczane zgodnie z oczekiwaniami. Roland McGrath, autor kwestionowanego kodu, dokonał pewnego spostrzeżenia na ten temat: – Nie chodzi o to, że to jest błąd, po prostu Hurd nigdy nie był zgodny ze specyfikacją POSIX-1996, która dotyczy semantyki sygnałów wielowątkowych. – wyjaśnia – Implementacja hurdowa jest starsza niż owa specyfikacja. – W następnej wiadomości kontynuje: – *Semantyka sygnałów w Hurdzie jest obecnie wyraźnie określona. Nie jest zgodna z POSIX-1996 w przypadku gdy na jeden proces przypadka wiele wątków.

To wyjaśnia różnice między Hurdem a najnowszymi uniksowymi systemami, takimi jak Linux. Neal Walfield, główny autor libpthread, oświadczył, że *nie widzi żadnych przekonujących powodów, aby nie przyjąć POSIX-ową/linuksową semantykę sygnałów, a porzucić tę z Hurda. Zatem Jérémie Koenig wysłał pierwszą łatę. Skoro już zaczęto pracować nad tą kwestią, Samuel Thibault dokonał kilku kolejnych zmian i sam również wysłał łatkę do glibc, która naprawia funkcje związane z przechwytywanem sygnałów. Ponadto nadal aktualny jest projekt zmiany hurdowych bibliotek i serwerów z cthread (libthread) z Macha na libpthread; prawdopodobnie modernizacja systemu sygnałów będzie możliwa podczaj jego realizacji.

Manuel Menal naprawił błąd, który występował podczas wysyłania deskryptorów plików posiadających SCM_RIGHTS przez gniazda PF_LOCAL. Ustalił ponadto, iż ów błąd powodował, że separacja praw demona SSH nie działała na GNU/Hurdzie — obecnie opisywany błąd został naprawiony, można już używać ustawienia UsePrivilegeSeparation yes.

Michael Banck, na podstawie odzewu od użytkowników, dokonał kilku zmian w pakiecie crosshurd i dodał do repozytorium nową wersję.

Z innych kwestii, deweloperzy Arch Hurda słusznie stwierdzili, że skoro spakietowali już wszechmocnego GNU Emacsa, wszystkie pakiety z aplikacjami dla użytkownika zostały przeportowane. Gdyby tylko wszyscy używali Emacsa...

Na koniec — we właściwym ku temu miejscu — przypomnijmy, że krążą plotki iż nasi koledzy z wydziału ds. Duke Nukem Forever znów poważnie biorą się do roboty. Zobaczymy. :-)

Źródło: http://www.gnu.org/software/hurd/news/2010-09.html