Styczniowe wiadomości nt. Hurda
- Dodano: 1 lutego 2010
- Wprowadził: azhag
- Komentarze: 26
Powstanie projektu Arch Hurd, przygotowania do konferencji FOSDEM, praca naukowa o technologii Mobile Objects w systemie Hurd.
W ostatnim miesiącu ukazała się pierwsza działająca wersja systemu Arch GNU/Hurd, kolejnej — obok Debiana — dystrybucji Hurda. Już teraz projekt Arch Hurd udostępnia 66% oprogramowania dostępnego w debianowym wydaniu Hurda.
Projekt Hurd zorganizował spotkanie w trakcie konferencji FOSDEM, która odbędzie się w dniach 6-7 lutego w Brukseli. W spotkaniu udział weźmie ośmiu deweloperów Hurda, sześciu z nich spotka się również z ludźmi z FSF Europe. Drugiego dnia konferencji Olaf Buddenhagen przedstawi dwie prezentacje w ramach Alt-OS Devroom: Dlaczego ludzie wciąż tworzą Hurda? (o 10:30) oraz Portowanie sterowników grafiki KGI z Linuksa do GNU Hurda (o 13:00).
Carl Fredrik Hammar napisał oraz złożył, a następnie obronił z wyróżnieniem, dysertację pt. Generalizing mobility for the Hurd, w której opisał wykorzystanie technologii Mobile Objects w Hurdzie. W streszczeniu pracy czytamy:
The GNU Hurd features mobile objects in its implementation of filesystem backing stores. This thesis investigates the limitations and security concerns these objects present, and how they can be overcome. This is done in preparation for new applications that feature mobile code and mobile objects. In addition, one such application is studied and implemented, in which mobile code is used to make the ioctl system call more extensible.
Więcej informacji: http://www.bddebian.com:8888/~hurd-web/n...010-01-31/
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
26 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Tutaj widziałem identyczne tłumaczenie:
http://dug.net.pl/news/53/
Może się czepiam, lecz mógłby to ktoś jakoś wyjaśnić?
na DUG-u: „Dodany przez azhag”
tutaj: „Wprowadził: azhag”
A to pirat! Nie dość, że ukradł własność intelektualną, to jeszcze tożsamość!
Dobrze. Myślałem, że poniżej w podlinkowanym tekście znajdują się tylko komentarze.
Właściwie to po co to samo w dwóch miejscach ?
Bo osnews jest agregatorem newsów. Mimo zapewne niezbyt uciążliwej możliwości bycia na bieżąco z wieloma serwisami, wolę być na bieżąco z zaledwie kilkoma i z nich czerpać wiedzę, której akurat nie mam ochoty zgłębiać studiując każdy news.
Skoro ludzie zaplusowali, to znaczy że to ciekawe i tyle.
No szkoda że Hurd nie cieszy się taki zainteresowaniem jak Linux bo z tego co można zauważyć że w systemach operacyjnych królują jądra monolityczne.
Systemy o otwartym kodzie jakie znam które mają mikro jądro to Minix, HaikuOS i ReactOS.
Mam odczucie że mikro jądro lepiej nadają się na desktopy ale pewnie nie każdy się zemną zgodzi.
No ok ale podaj za tym jakieś zalety. Jedyne co przekazałeś, to to, że jeśli chcesz stworzyć niszowy system, którego nikt rozsądny nie użyje zaopatrz go w mikrojądro.
Czemu się nadają? Bo komunikaty między procesami działają wolniej niż wywołanie funkcji systemowej? Bo transfery pamięci to tam porażka?
A spróbuj zrobić to samo co w Minixie na jądrze monolitycznym i wiesz co nie zrobisz bo się nie da, jeżeli wystąpi jakaś awaria w jądrze monolitycznym to wszystko pada. Ja wiem że mikro jądra nie są wydajne tak jak monolityczne ale łatwiej je rozbudować bez konieczności babrania się w całym jądrze.
A sarkazm powinien być karalny najlepiej śmiercią
Wymienione przez Ciebie elementy to prawda, ale dalej to nie są atuty dla desktopu, lecz raczej dla serwerów. W desktopie liczy się czas reakcji i aplikacje w przestrzeni użytkownika i wydajna komunikacja z i/o. Nie twierdzę, że albo jedno albo drugie jest idealne. Systemy odnoszące sukces zwykle biorą po trochu z każdego rozwiązania.
A jednak nie wziąłem trzeciej opcji pod uwagę a mianowicie tak zwane hybrydy bo nawet w Windowsie na jądrze NT można coś takiego spotkać choć może Windows nie jest najlepszym przykładem
to jednak faktycznie czerpać można z różnych rozwiązań po trochu tworząc coś dostosowanego do potrzeb.
Bardzo podobne argumenty słyszałem dawno temu, w czasach DOS.
Wtedy też różnego rodzaju "specjaliści" twierdzili że wielozadaniowość to strata czasu procesora, chroniona pamięć wymaga ciągłego kopiowania itd itp…
Nie posiadam możliwości porównania, więc może masz rację, ale…
Czy rzeczywiście podsystem dysków musi być w tym samym obszarze pamięci co podsystem karty graficznej? Czy pomiędzy nimi w ogóle odbywa się jakakolwiek komunikacja?
Czy oddzielenie stosu IP, nie poprawi przypadkiem bezpieczeństwa?
To są pierwsze zalety mikrokernela jakie przyszły mi do głowy.
Tak lekko offtopic… Mi się ciągle marzy system, który potrafił by scalić mechanizmy wirtualizacji z normalnym zarządzaniem systemem… by można było pojedynczy program zamrozić i przenieść na inną maszynę… by można było odizolować poszczególne aplikacje, tak mocno jakby znajdowały się na różnych komputerach.
no właśnie, kernel powinien dostarczać wyłącznie standardowej abstrakcji sprzętu w postaci bloków czy strumieni, żadnych protokołów i systemów plików
Zabieg porównania mnie z jakimiś konserwatywnymi programistami to strzał kulą w płot. Nie mówimy tu o tym czy coś wprowadzać, czy nie, lecz o tym które rozwiązanie może wydawać się lepsze. Moim zdaniem żadne.
Systemy, które odniosły sukces to takie, które czerpią z obydwu źródeł jednocześnie.
Akademickie bajania o czystości rasowej rozwiązań ładnych na papierze to bajania. W życiu liczy się to co się sprawdza w praktyce.
Co do twoich marzeń to wolałbym rozwiązanie polegające na stworzeniu frameworka serializacji modelu danych. To pozwalałoby na przywracanie stanu aplikacji na wielu architekturach. Wziąwszy pod uwagę odpowiednią ilość metadanych także na innych aplikacjach.
Co do podsystemu dysku i karty graficznej, to muszą być w takich miejscach, aby było możliwie łatwe przekazywanie fragmentów pamięci bez kopiowania.
Sorry, jeśli uraziłem Cię moim porównaniem, nie taka była moja intencja. Rzecz w tym że często rozwiązania, pozornie bardziej kosztowne, w dalszej perspektywie przynoszą liczne korzyści.
Linux ze swoimi modułami i licznymi wątkami kernela jest znacznie bliższy mikrokernelowi, niż jakieś 10 lat temu i wydaje mi się że taki ewolucyjny model jest najlepszy. Niestety, wciąż brakuje głównej zalety jaką była by pełna separacja poszczególnych podsystemów. Może kiedyś przy okazji zabaw z wirtualizacją ktoś wprowadzi podobne rozwiązanie? Nie pamiętam, czy KVM to potrafi, ale przykładowo w VMWare możliwe jest udostępnienie konkretnego urządzenia na magistrali PCI dla systemu gościa – z tego miejsca, droga do sterowników działających w odseparowanej przestrzeni jest już znacznie bliższa… ale znów zacząłem gdybać.
ps.
Wciąż nie widzę do czego może przydać się przekazywanie fragmentów pamięci pomiędzy kartą graficzną a dyskiem lub stosem ip?
Nic nie szkodzi
Chodzi o to by przekazywać w wydajny sposób fragmenty pamięci między systemem operacyjnym i sterownikami, a aplikacjami użytkownika. Najłatwiej to robić przez udostępnianie pamięci i przekazywanie wskaźnika.
W czystym mikrokernelu, gdzie "świętym Graalem" jest izolacja przekazywanie polegałoby na pompowaniu komunikatów przez multiplekser jądra. To nie jest fajne przy ładowaniu danych z dysku, czy sieci. Do karty graficznej część można zoptymalizować ładując wcześniej do jej pamięci, ale dynamika sceny może wymagać więcej.
ReactOS raczej nie posiada mikrojądra, choć pewne zalążki/przymiarki pewnie tak. Co do Haiku OS, to są osoby, które by się kłóciły.
Każdy praktycznie stosowany system ma jądro monolityczne (lub "hybrydowe"). Dotyczy to nawet Mac OSa (opartego na kodzie mikrojądra Mach).
A systemy czasu rzeczywistego ? Qnx , Rtmos , FreeRtos ?
Wątpie aby miały duże jądra zwłaszcza że przy ich zastosowaniach jest wskazane minimalne jądro
One nie są do wszystkiego.
Żaden system nie jest do wszystkiego , a tworzenie przesadnie wielu niepowiązanych ze sobą zastosowań jest błędem .
Hurd przypomina Brezniewa. Dogorywa od lat sztucznie podtrzymywany przy zyciu.
Hurd po prostu wolno się rozwija, ale jednak się rozwija. Skoro jest już nowa dystrybucja na nim oparta, to nie można w to wątpić. Spieranie się o to która konstrukcja jest lepsza – z monolitycznym, czy mikrokernelem – ma sens wyłącznie rozrywkowy. Pewnie w różnych zastosowaniach praktycznych oba warianty znajdą potwierdzenie swoich zalet. Z tego, że Linux jest OK, nie wynika, że Hurd nie ma racji bytu i vice versa.
Co do OS-ów opartych na podobnych założeniach, to z pewnością należy wymienić QNX, który od wielu lat skutecznie działa. Jest komercyjny, ale, jak MacOSX, oferuje dostęp do kodu źródłowego kernela.
Jeśli programy będą działać prawidłowo to nie widzę problemu aby tak silna dystrybucja jak Arch uniezależniła się od Jądra Linuxa , jest to wręcz wskazane
Każda wolna alternatywa jest dobra i mam szacunek do tworzących go ludzi, bo dzięki nim nie muszę nabijać kasy jakiejś skąpej korporacji (mimo iż mnie stać), ale mogę wybrać system zrobiony dla ludzi przez ludzi.
Aż niekiedy wraca wiara w dobro człowieka
Za ArchHurd.org:
"You now have an Arch Hurd system up and running! Admittedly, it's fairly useless at the moment and lacking some important things, but it boots."
Nie wątpie w umiejętności Aarona i całej ekipy programistów Arch ale
hmm… wygląda to na projekt bardzo bardzo hobbistyczny, zapewne nigdy nie stanie się tak duży jak ArchLinux.