A Microsoft publikálta a Singularity projektjének forrását a Codeplex-re

Microsoft, Windows

A Microsoft közreadta a Singularity névre hallgató kutatási projektjéből származó forráskódokata Codeplex-en egy tudományos, !kereskedelmi licenc alatt. A Singularity Research Development Kit a Microsoft Research Singularity projektjén alapul. Tartalmazza a forráskódot, a build-eléshez szükséges "szerszámokat", tesztkészleteket, a tervezési dokumentációt, stb. A Singularity RDK licence itt olvasható.

( trey | 2008. 03. 05., sze – 19:29 )

Nekem tűnik csak úgy, hogy ezzel a lépéssel elismerte az MS, hogy ez a projekt vakvágány volt?

--
trey @ gépház

Works4me ;)

Egyébként about-ból egy rövid idézet:

Slowly, ideas from Plan 9 are being adopted by other systems. Plan 9 was the first operating system with complete support for the UTF-8 Unicode character set encoding. The dump file system has been mimicked in Athena’s OldFiles directories or Network Appliance’s .snapshot directories. The flexible rfork(2) system call, the basis of lightweight threads, was adopted as is by the various BSD derivatives and reincarnated on Linux as clone(2). The simple file protocol 9P has been implemented on early versions of FreeBSD and current versions of Linux.

( Nerdman | 2008. 03. 05., sze – 20:30 )

Én arra vagyok kiváncsi, hogy hogyan voltak képesek megírni C#-ben a kernelt, és hogyan építették rá a rendszer többi részét mikor a C# nem egy rendszerközeli nyelvnek készült (azóta olvastam, hogy Assembly betéteket is használtak hozzá), és egyáltalán miért tették (ez utóbbit illetően már szorgalmasan olvasom a dokumentációt).

Ha valamit esetleg elírtam elnézést, abszolút kezdő vagyok, még csak egy hónapja tanulok C#-ben programozni, a .NET keretrendszer alaposztályainak eljárásait sem ismerem, magával a C# nyelvvel, és az objektum-orientált szemlélettel ismerkedem.

Számomra ez azért is érdekes, mert én pl. a Java nyelvről sem tudom elképzelni, hogy erősen rendszerközeli programok írására használnák, mondjuk az ismereteim eléggé hiányosak a Java-ról. A .NET keretrendszerre és C#-re épülő operációs rendszer meg már túl magas.

Update: http://channel9.msdn.com/ShowPost.aspx?PostID=68302
Kezdek megvilágosodni a fenti linken található kommentektől.
_______________________________________________
Keep It Arch Linux | Simple Xfce | Stupid! Fluxbox

Gondolom csináltak egy olyan osztályt, amelynek függvényei lekezelték a szükséges nagyon alacsony szintű feladatokat, a többi vezérlés meg átadásra került a C#-nek. Ezt írja a wikipedia is a megjelölt linken:

"The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it calls the kernel, whose runtime and garbage collector are written in C# and run in unsafe mode."

Kíváncsi lennék, hogy fejlesztők szemszögéből milyen előnyöket tudtak kiaknázni a C nyelvvel szembeállítva?

"Kíváncsi lennék, hogy fejlesztők szemszögéből milyen előnyöket tudtak kiaknázni a C nyelvvel szembeállítva?"

FIXME: Magának a C# nyelvnek vannak előnyei, a C-vel szemben máris ott van, hogy objektumorientált, a C++-hoz képest a C#-ben nincsenek olyanok, hogy makrók, többszörös öröklődés, virtuális alaposztályok, amik zavart és hibalehetőségeket okozhatnak, nem kell különböző műveleti jeleket (::, ., ->) használnunk, ha struktúrák tagjaival dolgozunk, ezenfelül kivételkezelés, szemétgyűjtés, bővíthető adattípusok, kódbiztonság.

Amennyit a fentiből részben laikusként részben sikerült levonni az annyi, hogy biztonságosabb, modern, és egyszerűbb a fejlesztés vele.
_______________________________________________
Keep It Arch Linux | Simple Xfce | Stupid! Fluxbox

Nem tudom, de szerintem ezek a képességek inkább hátrányok olyan, alacsonyszintű megoldásokat szükségszerűen felvonultató esetekben, mint egy oprendszer(?).
Biztonságkritikus területeken pl. előfordulhat, hogy az ilyesmik használata egyenesen tiltott. Egyébként az operációs rendszerek fejlesztéséhez nem értek.

> Biztonságkritikus területeken pl. előfordulhat, hogy az ilyesmik használata egyenesen tiltott.

Biztonságkritikus rendszerekben a rendszer rendszerének tervezője felállít egy szabályrendszert, aminek betartása pár alapvető dolgot garantál (pl real time válaszidők, memória nem fogy el, stb) és ellenőrizhető automatikusan.

Ezek elvileg mind megtehetők egy menedzselt nyelven is, az más kérdés, hogy még nincsenek rá keretrendszerek. De ennek nem elvi okai vannak, egyszerűen nincs még készen.

> a Java nyelvről sem tudom elképzelni, hogy erősen rendszerközeli programok írására használnák

letezik olyan mikrokontroller, amit java-ban lehet programozni. na annal rendszerkozelibbet eleg nehez talalni...

igazabol a java is csak egy nyelv, ami egyfajta bytecode-ra lefordul, csak a legtobb cpu nem tudja nativan futtatni ezt a kodot, ezert emulalja, virtualis gepben futtatja. de attol meg leteznek java kepes cpu-k, sot egyes ujabb ARM-ok is tudnak nativ java kodot futtatni.
az mar mas kerdes, hogy milyen JRE-t hasznalnak hozza, de ahogy van a mobilokhoz is speci JRE, nyilvan van/lehet olyan is amiben az adott hw lowlevel funkcioi elerhetoek.

a C#-ot nem ismerem annyira, de amenyit lattam/hallottam belole elegge java koppintas az egesz, szal vszinu hasonlo a szitu azzal is.
az persze jo kerdes, hogy egy x86 cpu hogy futtatja a c# bytecode-ot? (vagy a c# azert csinal .exe-t mert az gyarilag x86 kod, es csak nem-x86 platformokon emulaljak? vagy nincs is c# nem x86-on?)

A'rpi

.NetMS verziojanal ket szitu van: vagy egy koztes kodra fordit amit utana egy VM-ben futtat, vagy x86 gepikodra. Az okosok az MS-nel az elobbi hasznalatat javasoljak, mert mereseik szerint akar 15%-kal is gyorsabb lehet, mint a nativ verzio. (Ezt vicces volt anno hallani toluk). Mono-t nem neztem, annyira nem erdekelt.

---
pontscho / fresh!mindworkz

Az okosok az MS-nel az elobbi hasznalatat javasoljak, mert mereseik szerint akar 15%-kal is gyorsabb lehet, mint a nativ verzio. (Ezt vicces volt anno hallani toluk).

Így van ez a Java-val is. Bizonyos esetekben egy köztes kód alapján generált runtime kódon sokat tud optimalizálni egy jól megírt VM, csak nem minden esetben éri meg, mert lehet, hogy mire kisakkozza az optimális kódot, addigra eltelik annyi idő, hogy elveszti az előnyét... ;)

mire kisakkozza az optimális kódot, addigra eltelik annyi idő, hogy elveszti az előnyét.

Igen, ezért érdemesebb az ilyen kódokat szerver alkalmazásokban használni, (és ezért is népszerűbb a Java szerver oldalon, mint desktopon) hiszen ott a kód fordítása és optimalizálása egyszer történik meg, de az optimalizált kód futtatásának haszna sok felhasználónál jelentkezik.

init();

A VM-ben futtatás nem teljesen igaz. A közteskódot (aka IL-t) Just-In-Time fordítja natív kódra.

(Akit esetleg érdekelnek a technikai részletek: a fordítás metódusonként történik. Ha egy metódus még nem volt fordítva, akkor az első utasítása egy továbbhívás a JIT compilerre. Minden további hívás már a natív, lefordult kódot hívja. Ezért lehet akár 15%-kal gyorsabb, mert a fordítás a futtató gépen történik - ennek előnyeit szerintem nem én fogom neked elmagyarázni... :) Az első indítás, futtatás elvileg kicsit lassabb, és bár biztos létezik olyan szituáció, amikor ez számít, de én úgy vettem észre, hogy egyszeri user számára a mai gépeken észrevehetetlen.)

de attol meg leteznek java kepes cpu-k, sot egyes ujabb ARM-ok is tudnak nativ java kodot futtatni.

Szerintetek olyan sokmagos processzorok elképzelhetőek, amelyekben néhány mag java bytekód futtatására van felkészítve/optimalizálva? Esetleg a jövőben megjelenhetnek olyan processzorok amelyeknél mondjuk bootoláskor BIOS-ból, (EFI-ből) állítható, hogy a processzor hogyan viselkedjen (pl. hány mag legyen java bytekód futtatására fenntartva)? Akkor gondolkodtam el ezen amikor az Intel demózta a 64 magos processzorát - mire lehetne ennyi magot kihasználni?.

init();

Ha jó tudom a Transmeta fejlesztett/gondolkodott hasonló processzoron. Mármint hogy a mag felett volt egy értelmező/fordító kód és ezen keresztül lehetett elérni a processzor, a kód persze cserélhető és így processzor képes lenne x86 vagy bármilyen más magnak mutatni magát kifelé. Mivel a kód a processzoron belül helyezkedne el mint egy microcode a fordítás sebessége nem lassítaná jelentősen a teljesítményt.

( -Atis- | 2008. 03. 06., cs – 10:28 )

szerintem trey azért rak ki ilyen cikkeket, hogy hergelje a közönséget :)
bár, a hozzászólások elolvasása után most épp neki habzik legjobban a szája :)
azt nem értem, ha ennyire frusztrálja a microsoftnak már a léte is, miért nem keres olyan munkát, ahol nem kell kapcsolatba kerülnie a termékeivel... :)

( Nagyapa | 2008. 03. 06., cs – 11:58 )

Bocs, még nem néztem. A pcforum.hu-n kint van a hír?

Így járt.

Az mindenképpen vicces volt, hogy miután megkapta a ban-t, máris kérte az új password-öt a másik, "Winember" account-jához, azonban mivel ott fake email volt megadva, hozzám pattant vissza a jelszóváltoztató levél. A raplit már leverte a Winember account-tal annak idején a fórumban (szintén a színezésért lett figyelmeztetve), így sajnálom, de a társaságára a továbbikaban nem tartok igényt. Pláne, hogy egyszer a "Winember"-rel már le is iratkozott. Most legalább véglegessé vált.

--
trey @ gépház