#14Urak, mielott tuz ala veszitek egymast az elkovetkezendo 100-150 HSZ-ben:
A Singularity egy teljesen alapoktol ujratervezett es irt operacios rendszer. Nem alacsonyszintu nyelveket hasznalnak a kernel irasara, hanem a C# egy subsetjet, a Sing#-ot ami egy fejlett objektumorientalt nyelv es kimondottan rendszerszoftverek irasara fejlesztettek ki.
A mai operacios rendszerek a memoriat alapvetoen ket fo egysegre osztjak. UNIX-os korokben ezt hivjak kernelspace-nek es userspace-nek. Ez nem valami feature, hanem egy 60-as 70-es evekben alkototott modszer, hogy fizikailag elszeparalja a rendszerszoftvereket a felhasznaloi szoftverektol igy a teljes rendszer hibaturese es biztonsagossaga novelheto.
Az objektumorientalt nyelvek csak kesobb jelentek meg amelyek megoldast nyujthattak volna a problemaa, de a hardware - es kulonosen a memoria - arak azok tovabbra is az egekben voltak. Az objektumorientalt nyelvek - feladattol fuggoen - altalaban tobb rendszereroforrast emesztenek fel, viszont toredeke energiaval lehet fejleszteni, karbantartani oket, nem beszelve a kodujrahasznalhatosagra gazdagabb lehetosegek vannak, igy komplex szoftvereknel a teljes kodmeret toredekere csokkentheto. Ebbol termeszetesen az is kovetkezik, hogy hibalehetoseg is es a karbantartashoz szukseges fejlesztoi garda is csokken.
Azota az objektumorientalt nyelvek is messze jobbak mint akkoriban, ill. a hardware arak is elerhetobb aron vannak, viszont az emberi tenyezo a legnagyobb problema. Ahogy a szamitogepek elterjedtek ugy kialakult a "sok birka egy helyen" hatas. Na ez egy erdekes jelenseg, mert amikor ez koma eleri az embereket, onnettol kezdve nem kepesek az orruknal tovabb latni, csak habozas nelkul mennek a tomeg utan. Olyankor ha valaki megszolal, hogy "emberek, aljunk mar meg egy kicsit gondoljuk vegig ezt ujra" akkor a nagyjabol a 80 szazalek heves kopkodesbe kezd. (tobbek kozott ezert egtem ki es mondhatnam az undor elfog a mai "szamitastechnikatol" vagy "informatikatol")
Magyarul, van egy visszamaradott tomeghiszteria ami ott kezdodik, hogy valaki egyszer azt mondta, hogy: "objektumorientalt nyelvben orultseg kernelt irni, mert a teljes rendszer lassu lesz". Az mar mas kerdes, hogy azota a hardware arak jelentosen csokkentek es a nyelvek is alkalmasak, a lenyeg a birkaoszton. Szemelyes meggyozodesem es tapasztalatom, hogy napjainkban aki ilyet allit az vagy nem tudja, hogy egy operacios rendszer hogy mukodik, vagy nem programozott meg objektumorientalt nyelvben vagy ha igen akkor az egesz emberiseg halas lenne ha abbahagyna.
Es akkor vissza a singularity-re. A hagyomanyos operacios rendszereknel a kernelspace alatt allokalt memoria kozvetlenul irhato a kernel altal, ehhez a felhasznaloi programok nem ferhetnek hozza. Az utobbiaknak a kernelspacebol mappelt memoria all a rendelkezesere.
Miert vastagitottam ki? Azert mert ez onmagaban kepes 20-40%-os hatasfokveszteseget okozni. Ha ugyanezt az operacios rendszert objektumorientaltan keszitjuk el es az egyes szoftverkomponenseket hozzaferesi jogosultsagok szerint az osztalyokba/objektumokba valo szervezes altal izolaljuk el egymastol akkor ez a hatasfokveszteseg megszunik.
Helyette viszont meg fog jelenni egy masik hatasfokvezteseg, de egy alaposan atgondolt es odafigyelessel elkeszitett objektumorientalt OS-nel a legrosszabb esetben is az 5%-ot nem haladhatja meg!
A puffertulcsordulasi problemakat pedig azert szunteti meg, mert az objektumorientalt nyelveknel a memoria allokalas es cimkezeles transzparensen tortenik. Magyarul: nem a programozonak kell puffer-eket cimezgetni meg a szamlalojukat, mutatojukat szinkronban tartani, hanem egyreszt a nyelv tipusbisztos, masreszt pedig annak a programkonyvtarai mar tartalmazzak ezeket es konnyeden, bisztonsagosan felulirhatok is, ha valamilyen specialis viselkedesre akarjak azt birni (pl.: bizonyos elemek szurese a pufferbol, dinamikus meretezes, stb). Ezert van az, hogy nem fordulhat elo, hogy valamelyik puffer mutatoja tulcsordul es ilyenkor olyan cimtartomanyra mutathat ami mar egy masik program altal le van foglalva es akar mas jogosultsaggal fut.