Czy uważasz, że zarządzane systemy operacyjne to dobry pomysł? [Zamknięte]

Zarządzane systemy operacyjne, takie jak Microsoft Singularity i JNode, są dość interesującą koncepcją. Zasadniczo system operacyjny jest ładowany za pomocą kodu napisanego w języku niskiego poziomu (C / C ++ / Assembly), który zasadniczo implementuje maszynę wirtualną. Reszta systemu operacyjnego (i wszystkich aplikacji użytkownika) działa na maszynie wirtualnej. Jest w tym kilka wspaniałych rzeczy. Na przykład nagle zmienia się arbitralne wskaźniki. A jeśli dobrze napisane, pozbędziesz się mnóstwo starszej wersji, którą ma obecnie większość współczesnych systemów operacyjnych.

Jednak wadą jest to, że jesteś znacznie dalej od sprzętu, a jako programista tracisz możliwość zejścia na niższy poziom abstrakcji i brudzenia rąk.

Jakie są twoje opinie na ten temat?

Myślę, że to kolejny przypadek, w którym „to zależy”.

Jeśli piszesz aplikacje, takie jak przeglądarki internetowe, edytory tekstu itp., W których błyskawiczna wydajność niekoniecznie stanowi problem, to podejście ma swoje zalety. Stosując to podejście, możesz zaoferować swoim klientom bezpieczniejsze i bardziej kontrolowane doświadczenie. Ograniczasz nie tylko szkody wyrządzone przez szkodliwe oprogramowanie, ale także działasz w bardziej spójnym środowisku.

To jak różnica między grami na konsole a grami na PC. Te pierwsze dokładnie wiedzą, z jakim sprzętem muszą pracować, więc mogą skorzystać z tej wiedzy, podczas gdy te drugie muszą być w stanie poradzić sobie z szerszą gamą kart graficznych, kart dźwiękowych, prędkości dysków twardych itp.

Będą jednak aplikacje (takie jak gry!), Które wymagają dostępu na niskim poziomie i nadal będą musiały być uruchamiane „natywnie”.

Podobnie jak języki zarządzane, będziesz musiał użyć odpowiedniego narzędzia do pracy.

Generalnie myślę, że to dobry pomysł, ale ponieważ nie ma ich zbyt wiele w pobliżu lub jest blisko do pełnego upieczenia, bardzo trudno jest powiedzieć, jak poradziliby sobie w prawdziwym świecie. Chciałbym, żeby stwardnienie rozsiane zaktualizowało projekt Singularity, abyśmy mogli zobaczyć, dokąd to zmierza, ale zgaduję, że część z nich jest opracowywana w jakiejś wersji systemu Windows

Myślę, że korzyści z w pełni zarządzanego systemu operacyjnego są ogromne i może to naprawdę być przyszłość, ale minie wiele lat.

Dobry zarządzany system operacyjny zapewni Ci wszystkie punkty wejścia potrzebne do wykonywania wszystkich potrzebnych zadań na niskim poziomie, niezależnie od zarządzania: wychwytywania przerwań i wykonywania operacji we / wy za pomocą urządzeń. C # pozwala również na niebezpieczny kod (radzenie sobie ze wskaźnikami), ale będzie dozwolony tylko w „sterownikach urządzeń” (co będzie po prostu innym rodzajem procesu izolowanego programowo).

Korzyści w zakresie bezpieczeństwa, jednolitości, przenośności, a zwłaszcza niezawodności z pewnością przewyższą wszelkie wady wydajności. Wtedy w pełni zarządzany system jest zaskakująco szybki, ponieważ nie trzeba już przełączać kontekstu.

Zarządzane systemy operacyjne są prawdopodobnie jak mikrokernele - poświęcasz wydajność w imię bezpieczeństwa.

Mogą występować podobne problemy, ponieważ wymagają podziału kodu na 2 części:

• Jądro niskiego poziomu napisane w C / asembler
• Jądro wyższego poziomu napisane w języku zarządzanym

W zależności od kosztów bezpiecznego wejścia / wyjścia z języka HL może to powodować podobne problemy jak mikrojądra - być może nieco szybsze (opuszczanie HL jest szybsze niż zmiana pełnego kontekstu, ale na przykład JNI jest dość kosztowny).

Aplikacja użytkownika prawdopodobnie również potrzebuje osobnych kontekstów, ponieważ wiele aplikacji jest pisanych na innych platformach (np. C, Java lub .Net). W tych samych przypadkach aplikacje mogą być związane z procesorem (kompilatory, konwertery muzyki itp.) I wymagają nawet optymalizacji asemblera, aby działać z wystarczającą prędkością. Poza tym - ochrona MMU zaimplementowana w języku HL prawdopodobnie nie będzie tak szybka jak sprzętowa, nawet jeśli może być znacznie bardziej dopracowana.

Również język HL nie jest biegły w operacjach niskiego poziomu. Chociaż oprogramowanie jest zwykle projektowane z zastosowaniem „dobrej” praktyki kodowania, sterowniki nie są konieczne. Nie sądzę, że będą chronić przed co najmniej niektórymi błędami, ponieważ jądra wymagają czasami pamięci do zarządzania ręką.

Wreszcie nie sądzę, aby taki system operacyjny wymagałby pełnej maszyny wirtualnej. Ponieważ system operacyjny nie może być zbudowany z zasadą kompilacji po uruchomieniu, wszędzie języki HL (nawet z GC i spółką) byłyby lepszymi kandydatami.

Na przykład nagle zmienia się arbitralne wskaźniki.

System operacyjny jest z natury niski. Do sprzętu przekazujesz nie tylko „dowolny wskaźnik”, ale prawdopodobnie adres fizyczny, a nie wirtualny. Niektóre DMA mogą obsłużyć tylko pierwsze 16 MB pamięci. Chociaż taki system operacyjny może znacznie uprościć, nie pozbędzie się adresów.

A jeśli dobrze napisane, pozbędziesz się mnóstwo starszej wersji, którą ma obecnie większość współczesnych systemów operacyjnych.

1. Istnieje wiele starszych urządzeń. Znacznie więcej niż w oprogramowaniu. Najpierw zaczynasz w trybie rzeczywistym, następnie włącz bramę A20 (nie pytaj), przejdź do trybu chronionego, a następnie do trybu długiego.
2. Kompatybilność API / ABI jest dobra. Powiedz, że napisali taki system operacyjny - co byś na nim uruchomił? Firefox - nie (C i C ++ przy użyciu WinAPI). Java - prawdopodobnie musiała zostać przeniesiona lub miała kilka drobnych problemów przez ikvm - chyba że korzystała z JNI. Wydaje mi się, że MSSQL (i na pewno Oracle, MySQL, Postgresql ...) nie jest napisany w języku zarządzanym, więc nie byłby odpowiedni dla serwera.
3. Nawet kompatybilność z błędami jest „dobra”. AFAIK MS spędza dużo czasu na testowaniu i sprawdzaniu, czy niektóre oprogramowanie nie korzysta z API w sposób inteligentny (nieprawidłowy odczyt). Podobnie jak problem z użyciem wskaźnika za freenim, gdy system Windows faktycznie zaczął zwalniać pamięć.

Myślę, że zyska popularność w tym samym czasie, co mikrojądra.

Osobiście uważam, że pomysł zarządzanego systemu operacyjnego przypomina komunizm: dobry w teorii, ale niepraktyczny do wdrożenia.

Problem polega na tym, że po prostu nie widzę żadnego sposobu na uruchomienie zarządzanego systemu operacyjnego bez całkowitego przepisania go od zera (i mam nadzieję, że ktoś może udowodnić, że się mylę z tej strony). Ponadto, w jaki sposób dopasowujesz dekady niezarządzanego kodu do zarządzanego systemu operacyjnego?

Jądra najpopularniejszych systemów operacyjnych są testowane w bitwie i dojrzewały przez kilka dziesięcioleci. Nie przepisujesz ich po prostu pod wpływem kaprysu. Nie wspominając już o tym, że historia jest pełna przykładów projektów procesorów i architektur jądra, które były niezaprzeczalnie lepsze, ale nigdy nie były w stanie przekonać nikogo, że warto je zmienić.

Wreszcie, w jaki sposób firma taka jak Microsoft lub Apple zamierza sprzedać zarządzany system operacyjny klientom? Czy przeciętny użytkownik komputera będzie dbał nawet o to, czy jego system operacyjny jest zarządzany czy niezarządzany?

W związku z powyższym mam nadzieję, że się mylę i że zarządzane systemy operacyjne staną się rzeczywistością. Ale jestem sceptyczny. Jeśli kiedykolwiek to zobaczymy, prawdopodobnie nie będzie to przez kolejną dekadę lub dwie.

Kod zarządzany to tylko ekstrapolacja tego, co kupuje dziś wirtualna pamięć, a mianowicie zdolność komputera do odmowy dostępu do zasobów.

IBM robi to już na swoich systemach mainframe (nazywają to po prostu czymś innym), więc moim zdaniem jest to tylko kwestia czasu, zanim stanie się to w systemach dostępnych dla ogółu społeczeństwa.

Czy obchodzi Cię, czy laptop Google (na którym działa Chrome i właściwie nic więcej) działa na zarządzanym kodzie, czy nie?

Jednak wadą jest to, że jesteś znacznie dalej od sprzętu, a jako programista tracisz możliwość zejścia na niższy poziom abstrakcji i brudzenia rąk.

To nie jest tak naprawdę prawda. Na przykład w JNode istnieje Unsafeklasa (i inne), która umożliwia dostęp do lokalizacji pamięci i tak dalej. Istnieje również kilka klas / metod „magicznych”, które są tłumaczone na uprzywilejowane instrukcje przez kompilator JIT. Dostęp do tych klas / metod jest (lub będzie) ograniczony przez menedżera bezpieczeństwa, kompilator JIT i tak dalej. Ale jeśli piszesz kod, który wykonuje się na poziomie systemu operacyjnego, te funkcje są dostępne.

Zastrzeżeniem jest (oczywiście) to, że nieprawidłowe użycie Unsafei powiązane klasy mogą prowadzić do awarii systemu operacyjnego natychmiast lub w dół ścieżki.

Wątpię w ich przydatność dla komputerów stacjonarnych. Ale czas może udowodnić, że się mylę w tej kwestii.

Jednak moim ciekawym potencjałem jest system operacyjny serwera, a dokładniej system gościa w środowisku zwirtualizowanym. Nigdy nie przyszło mi do głowy, aby zainstalować pełną instalację serwera Windows w środowisku serwera wirtualnego, wiedząc, ile uruchomionych niepotrzebnych usług, w tym pełny GUI.

Teraz jest bardziej sensowne instalowanie czegoś takiego jak Singularity na serwerze wirtualnym do obsługi aplikacji ASP.NET. Zakładając, że mogą zachować lekki system operacyjny.