Milyen hatással volt a nyílt forrás a Windows Server 2008 fejlesztésére?

Címkék

Sam Ramji, a Microsoft nyílt forrású szoftverlaborjának igazgatója egy írásban foglalta össze a nyílt forrású fejlesztés, a nyílt forrású projektek főbb erősségeit és azt, hogy hogyan hatottak ezek az elvek a Windows Server 2008 fejlesztésére.

  • moduláris felépítés
  • programnyelvbeli változatosság
  • visszajelzés(ek)re épülő fejlesztés
  • meghatározott feladatra, meghatározott céllal történő fejlesztés
  • rendszeradminisztrátorok, akik kódot írnak
  • szabványokra épülő kommunikáció

Az igazgató - aki szerint ezek a dolgok működnek jól a nyílt forrású közösségben - példákat ír arra, hogy hogyan alkalmazták ezeket az elveket a Windows Server 2008 fejlesztése során. Bevallotta, hogy tanultak és folyamatosan tanulnak a nyílt forrású fejlesztési elvekből.

Sam Ramji előadást fog tartani erről San Francisco-ban az Open Source Business Conference rendezvényen, aholis a Linux Foundation részéről Jim Zemlin fog beszélni arról, hogy "Mit tanulhat a nyílt forrás a Microsoft-tól és a proprietary világtól" címmel.

A cikk elolvasható Port25 oldalán.

Hozzászólások

A Microsoft ingyenes rendszergazda képzésének (http://www.microsoft.com/hun/it/start.aspx) debreceni előadásán, az egyik előadó --a nevére nem emlékszem, szóval az aki erősen túlzásba vitte a "jópofizást"--, azt állította, hogy a Windows 2008 Serverben "Indián verő webszerver lesz!"

Véleményed szerint hol lesz a nagy kitörési pont? Azaz kik azok, akik azok, akik gyakorlatilag ingyen elérhető Apache helyett majd pénzért vesznek IIS szervert?

(Itt jelezném, mi __nem__ váltunk, bármilyen csábító is az IIS-sel a PHP :)))

--
trey @ gépház

azok fogják választani, akiknek már most nagyrészt windows serverük van és nincs kedvük csak a web miatt egy linuxhoz/apache-hoz értő rendszergazdát alkalmazni. Ahol már be van vezetve egy jól menedzselt windows server hálózat, ott nem érdemes egy külön linux szerverrel szórakozni... Az IT vezetőknek egy nagy érv, többtől is hallottam már.

B10

"ott nem érdemes egy külön linux szerverrel szórakozni."

Oh, mert az Apache nem fut Windows-on, ugye? :) Nem egy helyen láttam, hogy inkább valami Apache+MySQL+PHP mágikus install csomagból azt tettek fel a "jólképzett Windows adminok", minthogy az IIS-sel szarakodtak volna.

--
trey @ gépház

" Milyen hatással volt a nyílt forrás a Windows Server 2008 fejlesztésére?"

" * moduláris felépítés
* programnyelvbeli változatosság
* visszajelzés(ek)re épülő fejlesztés
* meghatározott feladatra, meghatározott céllal történő fejlesztés
* rendszeradminisztrátorok, akik kódot írnak
* szabványokra épülő kommunikáció "

A Win2003 eddig mi volt bakker?

Ezek csak lopni tudnak.

Hánynom kell tőlük.

Már csak a forráskódok közzé tétele és megszületik az openWin. De nem szeretnék addig fél lábon állni.
Az tetszik még, amikor telepíted az új M$ agyrémet, akkor azt a régebbi verziók elé helyezik, amivel kvázi elismerik az előd összes hibáját. Ez is csak egy ilyen eszköz lesz szerintem.

Milyen hatással volt a nyílt forrás a Windows Server 2008 fejlesztésére?

Jó. :)

init();

Meglepő, h a tanult dolgok közt ott a szabvány szó is xD
Egyébként szépen csavarják a dolgokat. Háttérbe szorítják, h a M$ tanult a nyílt forrástól, és az kerül a rivaldafénybe, h olyan előadások lesznek, h a nyílt forráskód mit tanulhat a M$-tól.
________________________________________________
Attól, hogy más hülye, te még lehetnél normális.

visszajelzés(ek)re épülő fejlesztés

Hö-hö... magyarul eddig leszarták a visszajelzéseket. Oszt csodálkoznak azon, hogy No Windows, No Gates, only an Apache inside...

Ez mind szép és jó, de tekintve hogy a compatibilitás miatt megmarad a rettenetes mennyiségű minősíthetelen win32 api
azért ettől sem várnék csodát. Amíg az ms nem képes meglépni azt a lépést, hogy nincs régi api vagy max. emuláltan wirtuális környezetben, addig szar marad bármit is csinálnak.
---
A tehén egy olyan szerkezet, ami ihatóvá teszi a füvet.

Szerintem ezt te nem gondoltad at. Nem a MS miatt kell a szargany winapi, hanem a kedves 3rdparty szoftvergyartok miatt, akik nem kepesek tisztessegesen hasznalni az uj apikat, hanem ganyolnak a regivel. Tul sok szoftver lenne hirtelen unsupported, es ezt a cegek nem feltetlen vennek jo szivvel, kulonosen hogy egyes cegek olyan sw-ket hasznalnak, amiknek mar a fejleszto cege reg a fold alatt rothad.

+1

Amúgy ez egy ördögi kör, a Microsoft fejére hullt vissza a feldobott Win32 gané. Kitörni úgy lehetett volna, hogy bizony EOL-re teszik a Win32-t és elkezdik sokkal erőteljesebben nyomni pl. a .NET-et. Nem mondom, ez nem egy fájdalommentes lépés, de áldozatot kell tudni hozni. Ezt szalasztották el a Longhorn katasztrófája utáni tűzoltásban. Ugye akkor sokkar erősebben hangsúlyozták a váltást .NET környezetre.

Az Apple anno kicsiben simán megtette, hogy először az OS 9 finom szólva elavult és nagyon gáz API salátáját kifésülte, adta helyette a Carbont, 5-6 év eltelte után pedig lövi kifele a Carbont is elavultság okán. Van is nyavalygás miatta, de átkényszerítik a fejlesztőket modernebb API-k használatára.

De Microsoftnál nem tették meg ezt a lépést (se), csak odázzák az előrelépést. Márpedig ez visszahúz az általuk teremtett mocsárba igen rendesen.

--
Kinek nem inge, ne vegye gatyára

Egy probléma van a .NET APIval, nevezetesen hogy egy jelentős része úgy készült, hogy a win32 apira tettek egy ojjektumorientált .NET réteget.

Az a része, ami ECMA standard még nagyjából rendesen van specifikálva, a többi meg egyre gányabb, ahogy haladunk a kevésbé használt fícsörök felé.

Nem tudom, hogy most hogy áll, de 2 éve még az UDP API alig működött és a win32 API-ból volt átmásolva a(z eleve szar) dokumentáció. 1 éve még voltak hibák a timerekkel (még az ECMA standard által specifikált timer implementációjával is). Ja és geci vagyok és egyikről sem küldtem bugreportot.

Dokumentáltság és megbízhatóság területén a versenytárs Java magasról veri a .NET-et.

Hat,ezt is megeltuk.
A picipuha azzal akar meggyozni a termeke josagaraol , hogy mennyi mindent vett at a nyilt vilagtol..

A vilag valtozott, erzem a foldben, erzem a levegoben, erzem az MicroS marketingben..