Következő Visual Studio és .NET 3.5 SP1

1. Pörögnek a fiúk. Lassan itt a nyakunkon a .NET Framework 3.51 – SP1

és…
2. Készülget az új Visual Studio – Team System is (kódneve: "Rosario"). A projekt és csapatmunkára meg a tervezési részeken erősítenek nagyon.

• Rosario April 2008 CTP Investigation (Part 1)
• Rosario April 2008 CTP Investigation (Part 2)
• Rosario April 2008 CTP Investigation (Part 3)

 

Kedves IDE!

Nahát ez édekes! Sose gondoltam volna, hogy a Nagy Kékség cumója végez az első helyen. Annak viszont örülök, hogy a NetBeans, ha csak picivel is, de megelőzte az Eclipse-t. tavaly a Java tanulmányaim során volt szerencsém mindkettőhöz és hát… az Eclipse-t fél óra után kihajítottam a kukába. Lassú is volt és – a számomra legalábbis – használhatatlanulul bonyolult, nehézkes, no meg csapnivaló.

 

"Az Evans Data világszerte mintegy 1200 fejlesztő megkérdezésével készített tanulmánya szerint az integrált fejlesztőkörnyezetek közül az IBM RAD a legkedveltebb a saját felhasználói körében, de az Oracle JDevelopert, a Microsoft Visual Studiót és a Sun Studiót is sokan szeretik. A legelterjedtebb nyílt forrású környezetek közül a NetBeans a hetedik, a MyEclipse pedig csak a nyolcadik helyet szerezte meg a rangsorban."

 

Részletek itt.

.NET App Domain

Elfoglaltságom miatt sajnos ritkán tudok írni, de akkor viszont jó hosszút (hja kérem, a technológiafejlesztés vezetőnek sanyarú sora van arrafelé, amerre én dolgozom).

 

Valamikor régen (úgy 6-7 évvel ezelőtt lehetett) nekem teljesen misztikusnak és túlbonyolítottnak tűnt a .NET-nél alkalmazott Application Domain (vagy App Domain) megoldás. Jelenleg pedig épp ellenkezőleg, úgy gondolom, hogy egy jól átgondolt tervezés része, mely nélkül nem lenne a .NET olyan rugalmas, mint amilyen. Azok kedvéért, akik – mint ahogy én is régen – most vannak "App Domain válságban" megpróbálom röviden leírni a lényeget.

 

Minden .NET-es komponensnek és alkalmazásnak szüksége van a saját működéshez egy menedzselt környezetre. Azonban a mögöttes operációs rendszer semmit se tud, semmit se tudhat arról, hogy mi az a menedzselt kód vagy környezet, ő csak natív folyamatokat (processzeket), illetve azok futtatását képes biztosítani. A folyamatok a legfontosabb, önállóan, egymástól elkülönítve futattható egységek. Ezek az operációs rendszerbeli folyamatok még annak sincsenek tudatában, hogy a .NET létezik, mindössze biztosítják a működéshez szükséges nyers elemeket, úgy mint memória, leíró táblák, stb. Egy menedzselt kód (pl.: .NET komponens vagy alkalmazás, de ugyanez igaz lenne a Java-ra is) ennélfogva nem képes direktben futni natív operációs rendszerbeli folyamatként. Szükséges, hogy legyen valami híd a menedzselt kód és a nem menedzselt kód (natív folyamat) között. Ezt az elképzelést, ezt a hidat nevezik a .NET-ben Application Domain-nek (vagy App Domain-nek).

 

Most esetleg mindenki gondolhatná, hogy "Hohó, akkor hát a .NET App Domain a natív folyamatnak megfelelő párhuzam, igaz?" Hát… nem. Legalábbis nem így. Nem képezhető le az 1:1-es párhuzam, mert az App Domain ennél még egy picivel több. Az App Domain-re tekintsünk úgy, mint egy .NET-es logikai folyamatra (logical process), amely biztosan hozzá kapcsolódik, vagy hozzá kötődik egy natív, fizikai, operációs rendszerbeli folyamathoz. Olyannyira, hogy egy fizikai folyamathoz több .NET-es logikai folyamat, azaz App Domain is tartozhat (Kedves Hölgyeim és Uraim, bizony itt van a kutya elásva!). Hogy miért van ez így? Hmmm. A gondos tervezés miatt.

 

Képzeljük el mi van akkor, ha van több, önálló feladattal is rendelkező komponensünk. Az egyik pl.: fájl beolvasást csinál, a másik feldolgozza annak tartalmát, a harmadik megjeleníti az eredményt, a negyedik pedig továbbítja a már feldolgozott eredményt egy másik számítógépre. Ha ezek a komponensek natív környezetben íródtak volna, akkor amikor közülük bármelyik is leállna fatális hibával, bizony az az egész folyamatot magával rántaná az enyészet felé, benne a maradék három, egyébként jól működő komponenssel (és talán még az őket meghívó klienssel együtt is). Ez kérem súlyos pazarlás. Egy olyan menedzselt környezetben, mint amilyen a .NET ez nem fordulhat elő akkor, ha az egyes komponenseket besoroljuk logikai folyamtokba, azaz App Domain-ekbe. Persze nem ez az egyetlen ok, de mi most erről beszélünk. Egy App Domain-ben akárhány Assembly (DLL komponens vagy futtatható EXE), egy fizikai folyamatba pedig akárhány App Domain tartozhat. Bármely komponens hibája esetén csak az a logikai folyamat (App Domain) omlana össze, amelyikbe az illető tartozott. A többi logikai folyamat (App Domain) és maga a natív, operációs rendszerbeli fizikai folyamat (processz) továbbra is működőképes maradna. Ez látszólag kis dolog, valójában óriási. Ne csak egyszerű alkalmazásokban gondolkodjunk, melyek többnyire egy logikai és fizikai folyamatba tartoznak, hanem arra is gondoljunk, hogy a komolyabb, főleg elosztott rendszerek több folyamaton is dolgoznak, azok különféle számítógépeken lehetnek, esetleg szerverfarmokon, melyek között fizikai kapcsolatot, együttműködést kell teremteni, no és persze megtartani. Egy ilyen helyzetben, ha megfelelően van kezelve a hiba, akkor arról a többiek legjobb esetben tudomást se szereznek.

 

A másik ok, hogy ezek az App Domain-ek létrejöttek az a biztonság. Sokan azt gonolják, hogy a Microsoft egy gonosz pénzeszsák, aki egyébként fütyül a biztonságra, csak a dollárjait számolgatja. Ez régen talán így is volt (annak is megvolt az oka), de manapság már ha biztonságról van szó, teljesen másképp gondolkodnak (jó, a dollárjaik számolgatását persze ma sem adták fel, valószínűleg azt most is épp oly szorgosan teszik, mint korábban, de hát… ilyen a kapitalizmus, nem igaz?).

 

Felmerülhet a kérdés, hogy frankó, de mennyibe kerül nekünk ez az App Domain-esdi, logikai folyamatosdi játék? Úgy értem teljesítményben okoz-e hátrányt? Igen, okoz, de nem túl sokat. Az előny, amit cserébe érte kapunk sokkal több, mint az elvesztegetett teljesítmény. Hogy mégy egy ilyen előnyt említsek itt van pl.: a hibakeresés, nyomkövetés (debug-olás). Összetett architektúránál ez igen komoly feladat lehet. A .NET-ben minden egyes App Domain külön-külön debug-olható, külön külön elindítható, leállítható, bármelyikhez becsatlakozhatunk menet közben, persze betartva az ekkor érvényes szabályokat. Az egyes komponensek áthívhatnak egy másik komponensbe még akkor is, ha azok ténylegesen egy másik App Domain-ben (másik logikai folyamatba) vannak. Fizikailag ezek egy folyamathatáron belül vannak, hiszen már tudjuk, hogy egy natív fizikai folyamat több logikait, azaz több App Domain-t is tartalmazhat. Teljesítmény szempontjából összességében mégis "olcsóbb" logikai folyamatokat menedzselni a fizikai folyamton belül, mint sok-sok, egymástól teljesen elkülönített fizikai folyamatot kezelni. A .NET szigorú biztonsági határvonalat épít az egyes App Domain-ek közé, az egyikben lévő komponens csak úgy nem tud a másikhoz fordulni (esetleg benne kárt tenni), hacsak… az a másik engedélyt nem ad neki erre a műveletre.

 

Mindezek tetején, minden folyamaton belül ott csücsül a .NET keretrendszer megfelelő része azért, hogy mindig figyelje, felügyelje (menedzselje) az ő hatáskörébe került folyamatokat.

 

Még nem beszéltünk a logikai folyamatokon belüli szálakról (therads), a távoli kapcsolatokról, App Domain-ek menedzseléséről, beágyazásukról (hosztolásukról)… és attól tartok most nem is fogunk. Egyelőre legyen elég ennyi. Borzasztó nagy és komoly téma ez, melynek részleteit a .NET Remoting tárgyköre dolgozza fel. Akit ennél több is érdekel, az javaslom kapjon elő egy könyvet és olvasson sokat.

 

A végére érdemes ideírnom azt is, hogy ki volt az, aki úgy igazán megvilágította számomra ezt a területet a .NET-en belül (meg még sok mást is). Nos, az illetőt úgy hívják, hogy Juval Löwy, a könyet pedig .NET Components. Juval egy IDesign nevű céget vezet, és egyben Microsoft Regionális Igazgatója valahol Silicon Valley-ben. Tevékenyen részt vesz a .NET jövőjének kialakításában, rengeteg cikket és néhány könyvet is írt már (annyira tökéletes az angolsága, hogy az általa leírtakat szinte folyékonyan lehet olvasni úgy, mintha magyarul írta volna).

Amit a Kurt jól elk…rt

Pár napja szegény Debian Linux projekten röhög a fél villág. Az egyik bamba projekttagnak (kódkabantartónak) Kurt Roeckxnek sikerült jól el…rontania a Debian által terjesztett disztribúció OpenSSL csomagját (melyre egyébként az összes Debian disztribúció, pl.: Ubuntu, Xandros, Linspire, UHU is alapul). Az történt ugyanis, hogy egy "md_rand.c" fájlban hibásnak vélt néhány utasítást, majd jól kiiktatta őket. Ezzel viszont olyan probléma-lavinát indított el az OpenSSL-en belül, hogy azóta se győzik takarítani utána a romokat.

 

Részletek itt és itt.

 

(az eredeti linkekért köszönet az egyik kedves olvasómnak)

 

Az azért érdekelne, hogy engedhetnek kritikus kódok közelébe egy olyasvalakit, aki nem odaillő. Megnézte valaki? Tesztelte valaki? Pedig ez már nem is az első eset. Vagy ennyire megérzik Ian Murdock hiányát? (Ian Murdock volt a Debian alapítója, a volt barátnője neve pedig Debra, Ian jelenleg az OpenSolaris-on ügyködik)

A négy kernel meséje

Most olvastam egy érdekes összehasonlítást, amelyben a lentebb felsorolt négy kernel forráskódjait vetették össze.

 

• FreeBSD
• Linux
• OpenSolaris
• Windows Research Kernel (WRK)

Aki esetleg az utolsó soron meglepődött picit (hogy mit keres itt egy Windows kernel forrás), annak kedvéért álljon itt némi magyarázat:

"The Windows Research Kernel (WRK) packages core Microsoft Windows XP x64/Server 2003 SP1 kernel source code with an environment for building and testing experimental versions of the Windows kernel for use in teaching and research. The WRK includes source for processes, threads, LPC, virtual memory, scheduler, object manager, I/O manager, synchronization, worker threads, kernel heap manager, and other core NTOS functionality."

 

Részletek (angolul) itt.