SharpOS 0.0.1

2 stycznia 2008

Wydano pierwszą wersję SharpOS — systemu operacyjnego, napisanego w całości w języku C#. Największym problemem tego “proof-of-concept” systemu był fakt, że… C#, jako zarządzalny język, nie jest stworzony do pisania tak niskopoziomowych programów, jak jądro systemu operacyjnego.

Twórcy SharpOS piszą, że mimo, iż celem było napisanie systemu w C#, infrastruktura, jaką stworzyli pozwala na napisanie jądra w dowolnym języku, produkującym bytecode dla Common Intermediate Language.

Więcej o SharpOS przeczytacie na stronie projektu.

Inny ciekawy projekt tego typu to JNode, czyli system operacyjny napisany całkowicie w Javie (jednak ze wstawkami w assemblerze). Ostatnia jego wersja — 0.2.5 — wydana została we wrześniu 2007 roku i udostępnia nawet interfejs graficzny, umożliwiający uruchamianie prostych programów w Javie.

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

25 odpowiedzi na „SharpOS 0.0.1”

dlaczego

2 stycznia 2008

fajne, ale chyba nowy system microsoftu tez jest w Dot NIET i uruchamia programy 100 razy szybciej niz linux

Odpowiedz
1. jellonek
  
  2 stycznia 2008
  
  nie zupelnie… symphony (czy jak to sie tam nazywalo) jest czysto laboratoryjnym rozwiazaniem i nie tyle "uruchamia programy" ile cos koncepcyjnie zblizonego do programow. nie jest tez nastepca visty, jeszcze dlugo polezy w dziale R&D…
  
  Odpowiedz
  1. Magnes
    
    2 stycznia 2008
    
    Singularity.
    
    Odpowiedz
    1. jellonek
      
      2 stycznia 2008
      
      ototo 😉
      sie mi nazwa zapomniala sie 😉
      
      Odpowiedz
    2. misio pysio
      
      3 stycznia 2008
      
      a Pan jellonek to ten z sosnowca? 😉
      
      Odpowiedz
    3. jellonek
      
      3 stycznia 2008
      
      nie, ten z Lublina, ktory ganial sie z jelonkiem w Sosnowcu 😉
      
      Odpowiedz
    4. jellonek
      
      3 stycznia 2008
      
      twu, w suscu
      
      Odpowiedz
Goofy

3 stycznia 2008

Z zalozenia system nigdy nie bedzie w 100% w C#, bo C# nie jest kompilowane bezposrednio do kodu wykonywalnego. Jestem kiepski z teorii jezykow pprogramowania, wybaczcie. Taki system po prostu nie moze byc szybszy od tych napisanych w takich jezykach jak C czy C++. Cokolwiek nie zrobicie, zawsze proces wykonania dannej czynnosci bedzie mail jeden dodatkowy etap – maszyne wirtualna.

@dlaczego, zanim rzucisz taki komentarz postaraj sie o jakies teoretyczne zaplecze w temacie.Mozna zrobic wiele rzeczy na komputerze, nawet okroic binarke z 3998 bitow do 45, tak zeby progra dalej dzialal… (przy pewnych zalozeniach) btw. to sie nazywa optymalizacja 😉

Odpowiedz
1. Marcin "Ktos&qu
  
  3 stycznia 2008
  
  Tak, ale jest taka kwestia, że Singularity faktycznie w niektórych momentach pracy systemu (bodaj przełączaniu kontekstu, nie pamiętam dokładnie) jest szybszy nie tylko od Linuksa, ale od każdego innego systemu operacyjnego.
  
  Bo to, że jest on napisany w C#, to taki dodatek. Ważniejsze jest to, że wykorzystuje programową izolację procesów (Software-Isolated Processes – SIP), zamiast tego, co stosowano dotychczas – jak poziomy pracy procesora czy oddzielne przestrzenie adresowe.
  
  Odpowiedz
  1. mario
    
    3 stycznia 2008
    
    W takim razie jest to jedna wielka kicha – bo jeden błąd w systemie wiesza wszystkie aplikacje. W Javie można też wykonywać w kontekście jednego procesu kilka programów w osobnych wątkach, wystarczy to do tego porównać – wtedy wywalenie się JavaVM to wywalenie się wszystkich aplikacji. Moim zdaniem lepiej wprowadzić zmiany w procesorach pozwalające na szybszy context-switch zamiast robić takie dziadostwo na poziomie softwareu.
    
    Odpowiedz
    1. trasz
      
      3 stycznia 2008
      
      Rownie dobrze mozna argumentowac, ze jeden blad w procesorze wywala caly system.
      
      Poczytaj o OS/400, opiera sie na troche podobnych zalozeniach – wszystko w jednej przestrzeni adresowej, w VM itd.
      
      Odpowiedz
    2. dna
      
      3 stycznia 2008
      
      "lepiej wprowadzić zmiany w procesorach pozwalające na szybszy context-switch"
      
      Poniekąd właśnie to robią – dorzucają nowe rdzenie do procesorów. Największą bolączką przełączania kontekstów jest konieczność wypełniania na nowo Cache'u procesora.
      
      Odpowiedz
    3. mario
      
      3 stycznia 2008
      
      @trasz: ja tutaj mówię o błędzie w bibliotece systemowej, jeśli proces będzie kompletnie niezależny to błąd w bibliotece systemowej zniszczy tylko ten proces w przypadku SIP wszystkie!
      
      Przy bardzo małym jądrze, tak małym aby trudno było w nim zrobić błąd, może to mieć sens, bo procesy zgłaszały by wyjątki do czegoś bardziej nadrzędnego, zakładając że acces violation się nie zdarzy jest OK. Oszczędzało by się czas na mapowaniu pamięci przy pełnym context switch, choć moim zdaniem założenie, że nie będzie błędów ochrony jest z góry błędne. Nie wiem czy warto tak ryzykować i co z programami, które odwołują się głąbiej, bliżej sprzętu? Przy pełnym context-switchu działały by one zdecydowanie bezpieczniej dla całego systemu.
      
      Odpowiedz
    4. mario
      
      3 stycznia 2008
      
      @dna: moim zdaniem algorytmy utrzymywania cacheu powinny być sprzężone z OSem, bo tylko OS wie jaki proces i jak często potrzebuje czasu i może powiedzieć procesorowi aby starał się utrzymywać dane fragmenty pamięci w cacheu z większym priorytetem niż inne, było by to na pewno lepsze niż czyszczenie cacheu.
      
      Dochodzi jeszcze jeden problem, wiele urządzeń korzystających z BusMasteringu mogą modyfikować pamięć RAM, taka modyfikacja kończy się sygnałem czyszczenia cacheu, tutaj nie pomoże OS zarządzający procesami w sposób SIP. Dopiero lepsze dopracowanie algorytmów zarządzania pamięcią i BUS Masteringiem mogą to rozwiązać (np. oznaczenie fragmentów pamięci, których nie wolno cacheować).
      
      Odpowiedz
2. jellonek
  
  3 stycznia 2008
  
  c# jako zwykly jezyk moze byc kompilowany do kodu natywnego. gdybys zajrzal pod linki np. pod ten, byc moze zrozumialbys ze przynajmniej subset jezyka mozna juz w tej chwili kompilowac do kodu natywnego…
  w tym przypadku calosc dziala bez maszyny wirtualnej (w czyms ona musi byc napisana).
  jak widzisz implementacja ximiana i ms to nie jedyne podejscie do tego samego tematu…
  co do twojego przykladu – to sie nazywa optymalizacja wielkosci programu 😛 – co nalezy odroznic od optymalizacji predkosci dzialania programu/algorytmu…
  
  Odpowiedz
  1. mario
    
    3 stycznia 2008
    
    Nie tyle język co wirtualna maszyna CLR (.NET) i Javy są kompilatorami JIT i podczas załadowania klasy do pamięci kompilują ją do kodu natywnego. Oczywiście pewna strata na wydajności jest, ale nie jest tak duża jak w przypadku interpretacji byte-codeu.
    
    Odpowiedz
    1. jellonek
      
      3 stycznia 2008
      
      zgadza sie, ale ja pisze o jezykach, a nie o maszynach wirtualnych w ktorych ich kod posredni jest domyslnie wykonywany.
      zarowno jave (gcj), jak i c# (wspomniany SharpOS.AOT) tycza sie jezykow programowania, a nie maszyn wirtualnych.
      w artykule masz rowniez mowe o systemie w calosci napisanym w c#, a nie systemie opierajacym sie o CLR.
      .
      rozjasnilem troche?
      .
      btw. zarowno hotspot, jak i ms clr, to interpretery wykorzystujace czesciowo kompilacje jit. tak wiec to nadal interpretacja bytecode, a nie jego kompilacja. inne podejscie to (na przykladzie chociazby tcc) calkowita kompilacja kodu przed przystapieniem do jego wykonywania, a nie tylko wywolywanych fragmentow (jak to sie robi w jit, przy uzyciu "odskoczni").
      
      Odpowiedz
    2. mario
      
      3 stycznia 2008
      
      @jellonek: ja może przytoczę kawałek newsa
      
      Twórcy SharpOS piszą, że mimo, iż celem było napisanie systemu w C#, infrastruktura, jaką stworzyli pozwala na napisanie jądra w dowolnym języku, produkującym bytecode dla Common Intermediate Language.
      
      Odpowiedz
    3. jellonek
      
      3 stycznia 2008
      
      The SharpOS project is aimed at writing an operating system in 100% C#. This originally proved to be a problem of nearly philosophical proportions because C# is a managed language, and by nature isn’t designed for such low-level uses as developing an operating system kernel. Please note that although our goal is to create an operating system in C#, the infrastructure we have created allows kernels to be written in any language that targets the Common Intermediate Language bytecodes and exposes pointers and unsafe code.
      
      cytowane z linku podanego przez autora newsa.
      .
      michuk to tylko przetlumaczyl. ich celem nadal jest stworzenie systemu w C#. ich infrastruktura pozwala na wykorzystanie kodu binarnego ukierunkowanego na CIL, ale nie wynia z tego ze beda uzywali vm CLR (co bylo by lekko bez sensu na poziomie kernela). byc moze aplikacje wyzszego poziomu rzeczywiscie beda sie opieraly o srodowisko CLR, ale nie kernel. kernel ma byc kompilowany przy pomocy:SharpOS’s AOT Compiler, which is used to compile IL assemblies into a native kernel image.
      .
      mam nadzieje ze dosc jasno wytlumaczylem 😉
      
      Odpowiedz
3. dlaczego
  
  3 stycznia 2008
  
  zarzucasz mi niewiedzę? A to ciekawe. w ktorym miejscu? Bo ja zarzucam Ci, że czytac ze zrozumieniem nie potrafisz.
  
  Odpowiedz
  1. jellonek
    
    3 stycznia 2008
    
    napisales dosc wyraznie ze nowe dziecko ms uruchamia programy 100 razy szybciej niz linux, co jest oczywista nieprawda…
    btw. spokojniej – musicie sie od razu czyms "obrzucac"? 🙂
    btw2. poki co, tego nowego dziecka ms jeszcze nigdzie nie obejrzysz (poza ich propagandowymi filmikami – z reszta – fajnymi 😉 ), tak wiec nie ma szans na pozytywne zweryfikowanie twojego porownania wzgledem linuksa. dlatego tez zostales odeslany na drzewo, tj. doczytac…
    
    Odpowiedz
    1. dlaczego
      
      3 stycznia 2008
      
      zauważ, że jak Ty piszesz, ze sie nie znam i musze doczytac by sie wogole wypowiadać to jest ok, ale jak napisalem, ze nie czytasz ze zrozumieniem to jest juz bee 😉
      
      Co do meritum. No cóż. mogę tylko powiedzieć, że Singularity faktycznie uruchamia programy dużo szybciej niż Linux i tu się po prostu mylisz myslać inaczej. Mogę Cie więc odesłac na drzewo, (tj. doczytaj) ale nie chcę. Bo nie chce być nie delikatny.
      
      Odpowiedz
    2. jellonek
      
      3 stycznia 2008
      
      😉
      poprzednio pisales nie do mnie, tak wiec chyba komentarzy rowniez ze zrozumieniem czytac nie umiesz 😛
      skoro "faktycznie" to prosze o jakies fakty. prosze o jakiekolwiek wiarygodne zrodlo potwierdzajace ta "faktycznosc".
      .
      chyba ze chodzi o fakanie 😉
      
      Odpowiedz
dmilith

18 października 2008

smutni jesteście. co mi po 100 krotnym (komu te bajki? skąd te dane? od CEO m$? ;>) przyśpieszeniu uruchamiania kodu, skoro to coś, znając m$ będzie tak stabilne i wspaniałe jak ich inne systemy. jak na razie m$ się nie udało zrobić ani razu tego co głosili w swej propagandzie (w reklamie też są słabi). przypomnijcie sobie proces instalacji windowsa 98 i te śmieszne zapewnienia o stabilności solidności i t d… to samo z Windowsem XP odnośnie bezpieczeństwa.. itd.. Wybaczcie, pozostanę przy "wolnym" Linuxie. (flejmować nie będę, że w efekcie chodzi szybciej niż Windows..)

Co do wydajności.. Nie wciskajcie ludziom kitu o tym, że Singularity czy jak go tam zwą jest szybszy skoro nie ma jeszcze nawet głupiego demo tego Super Systemu. Ja też potrafię napisać z kolegami z roku jądro, które będzie super szybkie i będzie wykonywało 1/100000 tego co jest powszechnie używane na codzień w takim Linuxie (tudzież Windowsie)..

Podsumuję, że oceniać i rzucać na siebie głupimi gadkami będziecie jak skończą to coś. Jednak pozostanę sceptyczny. Sama architektura x86 to coś od czego powinno się zacząć zmiany (patrzeć np na tłumaczenie rozkazów CISC na RISC w procesorach x86 w celu zachowania kretyńskiej zgodności z architekturą sprzed ponad 20 lat to też genialne podejście).

Sami zobaczycie że to będzie kolejny niewypał. W m$ nie pracuje się żeby zrobić coś dobrze, tylko po to żeby dobrze zarobić i zarabiać. A który genialny programista (tak, genialny. m$ bierze samych wymiataczy co tu dużo mówić), będzie tak głupi by napisać coś do końca dobrze? Przecież o to chodzi by praca była.. ;}

Odpowiedz
computer

10 marca 2011

Properly this sort of information is essentially worth looking for, excellent info for readers and undoubtedly shows high quality writing. Its cool to have these types of posts around to help keep the information and facts flow. Assisting these who seriously appreciate this, fantastic perform! Thanks again for taking the time to put this on the internet. I unquestionably liked each aspect of it.

Odpowiedz