Microsoft: hallgatni arany? Vagy nem?

Titkosítás, biztonság, privát szféra

Az elmúlt napokban több oldalon is olvasni lehetett arról a feltételezésről, miszerint a Microsoft csendben javítja a nála felbukkanó biztonsági hibákat, és a havi security bulletin-jeiben szándékosan elhomályosítja a patchek azon részleteit, hogy azok mit is javítanak tulajdonképpen.
A témát az a Matthew Murphy vetette fel, aki szoros együttműködésben dolgozott az MSRC-vel (Microsoft Security Response Center) a múltban. Szerinte a szoftvergyártó félrevezette az ügyfeleit akkor, amikor nem közölte pontosan, hogy mit is javított az április 11-én kiadott MS06-015 bulletin-ben.

A szakember miután átvizsgálta a "kritkus" jelzővel illetett patch-et, amely a Windows Explorer-ben levő távoli kódfuttatást lehetővé tevő hibát javította, észrevette, hogy az más hibát is javít. Ez egészen a tegnapi napig csak feltételezés volt, mert tegnap a Microsoft elismerte, hogy szándékosan tart vissza információkat.

Egy tegnapi Eweek cikkben az olvasható, hogy a Microsoft hiszi, hogy a biztonsági javítások részleteinek visszatartása segít megvédeni az ügyfeleit a rosszfiúktól.

A Microsoft bevallotta, hogy a cégen belül felfedezett biztonsági hibák részleteit visszatartja, mert szerinte a részletek közlése segíti a támadókat.

A cikkben egy példát is hoztak a Microsoft takargatására, és arra, hogy ez nem újkeletű. A MS04-007 bulletin-je klasszikus példája a takargatásnak. A bulletin egy hiba javításáról szól, miközben hét hibát javít.

Az Eweek cikke itt.

Hát, köszönjük Microsoft a beismerést. Azt már csak remélni tudjuk, hogy az ilyen "független" tanulmányok a valós, és nem a bejelentett hibák alapján készülnek...

( zoli78 | 2006. 04. 20., cs – 20:34 )

hm. rá kéne alaposan mászni a témára a sajtóban, hogy a sok manager rádöbbenjen, hogy sokkal több hiba van az m$-ban, mint amennyi napfényre kerül. Én határozottan inkorrekt dolognak tartanám, ha az ügyfelemet nem értesíteném arról, hogy találtunk x hibát, melyet a következő patch fog javítani. Szerintem az ügyfélnek joga van tudni ezt.
Persze nagy cég a sok kis ügyféllel szemben megteheti ezt. De egy kisebb cég vajon megteheti-e ezt az ügyfelével.

Zoli

Nem ellenőriztem le, de nem hinnem hogy ezt valaki mind egyszerre committelte be a cvs-be/git-be. SzVSz changelogra egyebkent is alig van szükség ha hozzáférsz a git/cvs archívumhoz. Márpedig a legtöbb open source projektnél hozzáférsz, szóval szépen nyomon követheted hogy ki mit adott hozzá/módosított.

Ok és le is ellenőrzöd egyenként mindegyik committot, hogy tényleg azt csinálja-e, amit ír? Meg azt is, hogy a "fixed a small typo in xyz.c" az nem egy potenciálisan kritikus security hiba kijavítását takarja-e? Szerintem még a security-val foglalkozó cégek sem tudják az összes javított apró bug tényleges lehetséges következményeit visszamenőleg elenőrizni. Nincs erőforrásuk rá, és nem is igazán céljuk, hogy a már javított bugok súlyosságát megítéljék, inkább a még ismeretlenekre koncetrálnak.

---
Apparently the human mind is not unlike cookie dough.

Én nem ellenőrzök le semmit. De azt hiszem abban egyetértünk, hogy sokkal könnyebb megállapítani hogy mi változott mondjuk két release között bármilyen open source szoftverben mint azt hogy pontosan mit is csinál egy bináris patch. Csak ennyit akartam mondani. Valamint ahogy az előbb is megjegyeztem nem érdemes a changelogot nézegetni amikor egyből nézheted a diff-et is, persze a legjobb a kettő együtt.

Vagy ha gondolod kipróbálhatjuk. Adok neked egy programot bináris formában meg egy másikat forráskóddal együtt, szerinted melyikhez mennyi időre van szükséged ahhoz hogy megmond mit csinál?
(Ez persze csak gondolatkísérlet, valójában nem akarok adni semmit. :)

Jó, ok tény, binárisban az még kideríthető, hogy 1 helyett 7 hibát javít, az, hogy 101 helyett 107 hibát javít azt már nem. Forráskósban az, hogy 101 helyett 107 még megfelelően sok munkával kideríthető, de az, hogy 1001 helyet 1007 az már nem.

Javaslom szemléletformálónak ezt:
http://bingweb.binghamton.edu/~scraver/underhanded/index.html

Ha ~300 sor kódan el lehet rejteni egy képbe vízjelet rakó funkciót, úgy, hogy az még syntax highlighterrel se legyen gyanús, akkor mondjuk 300000 sor kódban mi mindent lehet elrejteni?
Jó persze itt most konkrétan nem arról volt szó, hogy szándékosan valami backdoort építsenek egy rendszerbe, de akár még ez is lehetséges, annak ellenére, hogy nyílt a forráskód és van peer review. Tény, hogy zárt forráskód esetén sokkal egyszerűbb kivitelezni, mert a forrásnak nem kell ártatlannak kinéznie, de mindenki számára olvasható forráskód esetén is simán lehetséges csak programozói leleményesség kérdése.

Ugyanez a helyzet a bugfixekkel. Rengeteg akár kritikus hiba van, aminek a javítását simán el lehet adni "code cleanup"-nak és ha valaki nem keresi kifejezetten benne a trükköt, akkor ránézésre eszébe sem fog jutni a patchről, hogy a kód átrendezésével mondjuk egy versenyhelyzet vagy egy tömb túlcímzési lehetőség is megszűnt.

Az opensource jó dolog, de sajnos nem csodaszer. Tény, hogy lényegesen nagyobb méretű programokat lehet átlátni, ha megvan a forráskód, de a mai bloatware cuccok már akkorára nőttek, hogy itt már a kód nyitottsága sem védi meg a felhasználót a programozó esetleges rossz szándékának kiszolgáltatottságtól.
---
Apparently the human mind is not unlike cookie dough.

"Az opensource jó dolog, de sajnos nem csodaszer. Tény, hogy lényegesen nagyobb méretű programokat lehet átlátni, ha megvan a forráskód, de a mai bloatware cuccok már akkorára nőttek, hogy itt már a kód nyitottsága sem védi meg a felhasználót a programozó esetleges rossz szándékának kiszolgáltatottságtól."

Tudsz olyan szuperbiztos rendszert, amelyet nem próbálnak majd meg, önző és gonosz tettekre felhasználni? Ilyen nem létezik, és soha nem is fog! Ha valaki előáll valami forradalmi világmegváltó dologgal, a 6 milliárd majomszabású közül, mindig akadnak majd olyanok, akik a saját hasznukra és más kárára fogják használni azt...
Az Open S. messze nem a nirvána, de mindenképpen egy lépés a sötötben tapogatózás világából, és véleményem szerint most ez a legjárhatóbb út, a security területén.

Javaslom szemléletformálónak ezt:
http://bingweb.binghamton.edu/~scraver/underhanded/index.html

Kicsit off, bocsi, de nekem ez az egyik kedvencem:

http://www.comsc.ucok.edu/~mcdaniel/mcdaniel/prog1/obfus.c

(A contestben nem talaltam, pedig asszem benne volt. Mondjuk nem is nagyon kerestem...)

A nagy érdeklődésre számot tartó opensource projekteknél minden területre lesz legalább egy olyan érdeklődő, aki meg fogja nézni, hogy mi is változott. Ezen embereknek a changelog inkább csak segítség, de nem az egyetlen lehetséges módja annak, hogy hamar megértsék, hogy a változások mit takarnak.
Persze van ellenpélda is: OpenOffice.org, a fejlesztői mag alig több 50 főnél, akik a sun-nál dolgoznak + egy-két fő máshonnan. A projekt olyan hatalmas és összetett, hogy el tudtak rejteni benne néhány meglepetést is (tic-tac-too, lövöldözős játék, meg hasonlók).
Nem arról van szó, hogy ne lenne ott a forráskódban, hanem arról, hogy olyan nagy a forráskód, hogy egy ember képtelen alaposan megismerni.

elmondtad párszor, hogy nem érdekel a kódolás, és nem is nagyon mélyedtél bele. akkor most
- vagy changelogot olvasol, és reménykedsz, hogy beleírják, hogy silentfixeltünk ám,
- vagy diffet olvasol, de ez a fentiek ismeretében nem biztos, hogy tökéletesen megnyugtató

amikor átnézed a commitokat (tetszőleges projektnél), akkor azt azért teszed,
- mert érdekel, hogy fixeltek-e olyan dolgot, ami téged is érinthet,
- vagy mert azt vizslatod, hogy elsumákoltak-e valamit (ez esetben az a kérdésem, hogy linux kernelnél szoktad-e figyelni)

Ezzel azt akartam mondani, hogy ha egy olyan 0, mint én rendszeresen érdeklődik a commit logok után (most az tök mindegy, hogy miért), akkor joggal feltételezhetjük, hogy rajtam kívül is nézik mások, akik talán még értenek is annyira hozzá, hogy meg tudják állapítani, hogy történt-e ilyen.

Egyetértünk?

--
trey @ gépház

Nem. Ez olyan, mint amikor egy kutató felteszi az életét arra, hogy minél alaposabban megértse a természet működését, egészen visszavezetve atomi szintig és biokémiai reakciókig, míg a másiknak fogalma sincs ilyen alaposan ezekről, helyette hamis hittel, feltételezésekkel és misztikus vallási dolgokkal próbálja kipótolni a hiányzó tudását. Lehet mindkettőt tudósnak, orvosnak vagy doktornak hívják, de csak az egyik az amelyik valóban a tudománnyal foglalkozik.

vagy lehet mas oka is, - csak joindulattal megkozelitve:
- nem erdekli a kodolas, de erdekli egy fejlesztes menete, mivel neha cikkeket is ir es nem art ha van valami fogalma egy fejlesztes meneterol,
- talan a baratnoje OpenBSD, dflyBSD hacker es csak ellenorizni akarja, hogy committol, vagy eppen randizik :-)

kodolas != csendzslog olvasgatas

---------------------
Ригидус а бетегадьбол

Kódolni nem kódolok, de azért a múltkor annyira azért bele tudtam rondítani a FreeBSD forrásába, hogy az addig nem támogatott merevlemez-vezérlőm az lett, és fel tudtam telepíteni egy olyan gépre, amin a változtatásom nélkül szarrá fagyott a sysinstall. :-)

Szóval azért érdemes nézegetni a commit logokat, mert lehet találni olyat, ami hasznos lehet a számomra egyik vagy másik projektnél. Igaz, hogy nem fejlesztek (mert nem elégít ki a kódolás), de aktívan bugreportolok, ami a fejlesztőknek talán nagyobb segítség, mintha amatőr módon kódolnék (mivel hozzájutok olyan vasakhoz, amikhez ők nem, vagy csak jóval később).

--
trey @ gépház

aktívan bugreportolok, ami a fejlesztőknek talán nagyobb segítség, mintha amatőr módon kódolnék (mivel hozzájutok olyan vasakhoz, amikhez ők nem, vagy csak jóval később)."

Hat igen, az is nagy segitseg, ha valaki rendelkezik hardverrel, plane ha tudja is, hogy hogyan segitsen a fejlesztoknek. :-)
---------------------
Ригидус а бетегадьбол

( snq- | 2006. 04. 20., cs – 20:55 )

>> a Microsoft hiszi, hogy a biztonsági javítások részleteinek visszatartása segít megvédeni az ügyfeleit a rosszfiúktól.
ami baromság, tekintve hogy nem 2 ember figyeli folyamatosan, hogy pontosan mit is tolnak ki patch címén

"tekintve hogy nem 2 ember figyeli folyamatosan, hogy pontosan mit is tolnak ki patch címén"

Sajnos igazad van:

"He said IT departments do not have the skill or resources to reverse-engineer every patch.

"They are simply left in the dark and may ignore a patch that is super-critical to their environment. Meanwhile, the bad guy has spent the time to find out what was silently fixed,"

Csak éppen a rosszfiúk azok.

--
trey @ gépház

De ha a rosszfiúk tudják a jó fiúk meg nem, akkor az rossz, nem?
Mert ha nem tudom milyen (engem is érintő) hibát javít a patch, akkor lehet, hogy nem is teszem fel (mert mondjuk az ismert hiba, ami javít engem nem érint), mert volt már olyan, hogy egy (esetleg irreleváns) javítás több releváns új hibát hozott.

Vagy rosszul gondolom?

Misi

Igen, nekem is ez jutott eszembe.
Ha van egy kellőképpen bevédett (mondjuk egy tűzfal mögött levő belső levelezésre használt exchange vagy file-szerver) ms windowsos szerver, aminek persze elvileg 7*24-et kellene mennie (más kérdés hogy nekem még nem volt szerencsém ilyenhez, viszont amit hetente kétszer oldalba kellett rúgni, már igen:), naszóval egy ilyen gépre nem biztos hogy minden vaczak peccset egyből, habozás nélkül felnyom az ember.
Aztán átjáróház.

>ms windowsos szerver, aminek persze elvileg 7*24-et kellene mennie

Anno 94-96 között volt szerenszém userként (majd power userként) egy Interactive UNIX-hoz. B;rmilyen hihetetlen de ez az Microosft terméke. _heti_ rendszerességgel keményre fagyott, ami az akkori UNIX-oks kozott sem volt szokas. a bugok szandekos bennehagyasa a kodban m$ talalmany.
http://hungarian.joelonsoftware.com/Articles/BugFixin.html
a pelda azert nem jó mert a szoftverfejlesztésnél tökmindegy, hogy 3, vagy 3millió példányban adod el a szoftvert. de a lenyeg, hogy a M$-nál szándékodsan nem javítják a hibákat, és ezt megpróbálják featureként beadni, és vannak olyan hülyék, akik ezt be is veszik.

Anr - http://andrej.initon.hu

Pontosítanék: azt ugyan nem tudom, Te min dolgoztál 94-96-ban, de:
az Interactive UNIX az Sun termék (egyébként "A Kodak Company") volt;
az M$ Jujnikszát Xenix-nek hívták, ezt vette meg később mindenki kedves SCO-ja, és SCO Xenix néven futtatta. Többek között ebből (is) lett a későbbi SCO UNIX, az ODT, illetve az OpenServer verzió.

( Previ | 2006. 04. 20., cs – 21:10 )

Nagyon csodás javítás lett ez a MS06-015, meglehetősen sok gépen szívunk vele (és nem csak mi), javasolt csak óvatosan telepíteni...

( anr | 2006. 04. 20., cs – 22:53 )

T. windowsbuzik (snq-,hunger,zsirfeka,...)

ugyanmar indokoljatok meg, hogy miert is jo _nektek_, hogy a Microsoft hazudik a biztonsagi bejelenesekben?
pl: egy 700 napos hibat ujnak tuntet fel. nem orom azt erezni, hogy 700 napja atjarohaz a windows-os szerver, es csak most van ra patch, az is "új"? Mi ebben az ami miatt meg sem fontoljátok, hogy meneküljetek a Microsoft programjaitól? nem egyszerü, tudom, probáltam. DE hasznos, és eredményes, pénzügyileg, időügyileg, emberszámügyileg, és bármi más paraméter szerint, amit lényeges. bár néha kell 3-6 hónap, hogy ez az előny nyilvánvaló legyen.

az óriási különbség a céges dobozeladásos szoftverfejlesztés(legjobb példa M$), és a szabad szoftver között, hogy a szabad szoftvernél a projektnél pontosan az a jó ami a felhasználóknak is jó, míg a céges dobozeladásos modellnél a cégnek a dobozszám a fontos, és ennek érdekében _BÁRMIT_ képes feláldozni, lop, csal, hazudik ha a körülmények úgy kivánják. korrektnek gondoljátok, hogy a Win NT 3.5, és 3.51 verziója között a kód több, mint felét ujrairták, de erről kussoltak? en nem gondolom, hogy az ugyfelek atverese korrekt magatartas, es azt sem, hogy egy cég ami ugy gondolja nem foghato meg (zárt a kód, aki rájön, azt bepereljük) nem fog mindenféle fondorlatos/gyalázatos eszközzel a felhasználókkal való kibaszásra törni (értsd: fizessen miné többet még akkor is, ha nincs miért)

Anr - http://andrej.initon.hu

>> T. windowsbuzik
nem anyáddal beszélsz

a silent fix-ek nem m$ specifikus "megoldások", és fentebb pont ökörségnek tituláltam ezeket

>> Mi ebben az ami miatt meg sem fontoljátok, hogy meneküljetek a Microsoft programjaitól?
képesség több (==1-nél több) szempont figyelembevételére?

>képesség több (==1-nél több) szempont figyelembevételére?
megvan a képességéged fél évnél hosszab távu előre látásra?
nem ugy tunik.
pedig érdemes, és _SOK_ pénzt hoz.

miért:
készitettem egy teljes backoffice rendszert egy brókercégnek. linux/mysql-en futott. elkértem azt a pénzt amit a brokercég korrektnek itélt a teljes rendszerért. nem Larry Elison/Bill Gates, hanem az ÉN bankszámlámon van az a pénz. azóta DK-Ázsiában élvezem a munka nélküliek kibasz jó életét. ti meg menjetek naponta és segitsetek a 1.0-ás usereknek, hogy "any key" nyomjanak a windozukn. ez a ti világmegváltásotok, az enyém meg itt van most éppen itt van thaiföldön. mindegyikönk elbassza az életét valahogy, az a kérdés mennyire élvezi közben;))))))))))))))))

Anr - http://andrej.initon.hu

készitettem egy teljes backoffice rendszert egy brókercégnek. linux/mysql-en futott. elkértem azt a pénzt amit a brokercég korrektnek itélt a teljes rendszerért. nem Larry Elison/Bill Gates, hanem az ÉN bankszámlámon van az a pénz. azóta DK-Ázsiában élvezem a munka nélküliek kibasz jó életét. ti meg menjetek naponta és segitsetek a 1.0-ás usereknek, hogy "any key" nyomjanak a windozukn. ez a ti világmegváltásotok, az enyém meg itt van most éppen itt van thaiföldön. mindegyikönk elbassza az életét valahogy, az a kérdés mennyire élvezi közben;))))))))))))))))

Arra a DrStock nevű tőzsdeügynöki szoftverre gondolsz, amelyet az eMIGRA Informatika Kft. (a volt munkáltatód) forgalmaz és a SWAP Tőzsdeügynöki Rt. használ?

Nos valóban büszke lehetsz rá, hisz 2004-ben a Pénzügyi Szervezetek Állami Felügyelete (PSZÁF) meg is birságolta őket, többek közt azért, mert az új csoda Linux/MySQL alapú rendszeretek még alapvető hozzáférés védelemmel sem rendelkezett (amelyet, még az előtte használt régi, elavult - Windowsos - Winterest értékpapír kezelő program is tudott.)

De idézem a határozatot:

7/a. A vizsgálat megállapítása szerint a hozzáférés védelem nincs szabályozva. A régebben használatos Winterest értékpapír kezelő programnál, valamint a régi és az új főkönyvi programoknál is kialakították a funkció szerinti jogköröket, de az új drStock rendszernek nincs jogosultságkezelési lehetősége sem. Az alkalmazottaknak az egyes rendszerekhez történő tényleges hozzáférési jogait az Rt. nem tudja dokumentálni.

Persze (gondolom nem kis seggberúgás után) elkészült a programotokhoz ez is ("Az Rt. által kifejtettek szerint a felhasználói jogosultságok kezelése a drStock szoftverben időközben elkészült."), de továbbra sem tűnik túl stabilnak a csoda Linux/MySQL alapú rendszeretek, hisz néha olyan bugok jönnek elő, amelyek miatt nektek (vagy az ott maradt fejlesztőknek, hisz te lekoccoltál a cégtől) még mindig közvetlenül az SQL adatbázisban kell kotorászni, hogy helyrejöjjön a rendszer:

7/b. A vizsgálat megállapította, hogy az Rt. a rendkívüli eseményeket nem dokumentálja. A drStock rendszer fejlesztőinek készült hibabejelentők alapján időnként előfordulnak olyan hibák, amelyek miatt az éles adatbázisban közvetlen beavatkozásokat, adatmódosításokat kell végezniük a fejlesztőknek. Az eddigiek során az éles adatbázisiban végrehajtott módosításokról semmilyen engedélyezési és megvalósítási dokumentum nem készült, nem rögzítik, hogy mikor, milyen okból kifolyóan, milyen adatokat változtattak.

Hát gratulálok a sikereidhez és további jó nyaralást kívánok thaiföldön! ;)

Én is izléstelennek tartottam a lefaszfejezésemet és a lebuzizásomat, dehát ilyen kibervilágban élünk... ;)

Van egy olyan mondás, hogy "amilyen az adjon Isten, olyan a fogadj Isten". Azt hiszem te sem viselkedsz másképp. Ennek ellenére nem kívánok 'folytatni' semmit, amennyiben nem kapok rá újabb okot.

Rendben, bár hozzá kell tennem, hogy semmiféle privát információ nem volt a hozzászólásomban, hisz a weboldalak publikusak, a srác pedig saját blogjában reklámozza a "programját", kisebb egotrip kiséretében:

A legnagyobb program amit készítettem az a drStock. Egy kozepes brókercég teljes backoffice rendszere. Üzleti logika tervezésnek 100%-a, a program arhitekturális felépítésének 60%, a kódolás 80%-át végeztem ezzel a két kezzemmel itt. 15 ember munkáját végeztem el!!! Aranyapáim lefuttattam a forráskód mérő programot(sloccount) a saját munkámra. Szerinte objektiven mérve 115,323 sor program keszült(ez nem a végleges szerintem, utána meg sokminden keszült el). 29.24 emberév munkája. A javaslata az, hogy 15.14 ember csinálja, es 1.93 év alatt fognak elkészülni(Ez stimmelt, én is nagyjábol ennyi idő alatt csináltam meg;-))))). A teljes becsült költseg: $ 3,950,512. Hé régimunkaadóim! Lógtok néhány százmillióval!;-))

Szóval részemről ennyi. ;)

Sokáig gondolkodtam, hogy hozzászóljak-e. Végül úgy döntöttem, hogy igen, mert többször snq, Hunger, Bástya_Elvtárs, stb. véleményével szembe mentem már, csak és kizárólag a saját tapasztalataimra alapozva. Most viszont azt mondom, hogy jelenleg a másik oldalnak van igaza. Egyrészt senki ne buzizza le a másikat, másrészt, ha lehet fikázni a Wines stuffokat, akkor miért ne lehetne egy Lines/MySQL-es programot, főleg úgy, hogy valaki ilyen tenyérbemászóan arogáns módon próbálja előadni, blogjában fényezi magát, miközben a különböző felügyeletek büntetik az ügyfelét a munkája miatt. Az ilyen megnyílvánulások többet ártanak a nyílt forráskódú törekvéseknek, mintha meg sem szólalna a nagy tudású fejlesztő úr.

a szabad szoftvernél a projektnél pontosan az a jó ami a felhasználóknak is jó

Ez nem igaz, lásd OpenBSD (hirtelen más nem jut eszembe). Olvasd el, egy-egy feature requestnél milyen pökhendi, bunkó megnyilatkozások vannak. Az jó XY-nak, hogy beír a levlistára, és 5 ember hülyézi le kapcsiból? Theo is csak fikázza a többi BSD-t, ld. amikor a Dragonfly-ról kérdezték, akkor nem nagyon volt kapaszkodója, ezért csak annyit mondott, hogy túl kicsi a dev. teamje.

Ez egy dolog, ezek emberi dolgok.. az LKML és a társai is tele vannak flamekkel, viharokkal, (akárcsak minden fórum, irc, levlista) de nem baj. Maga a kód a fontos, az, hogy ami benne van, a változások, a fejlesztések, tendenciák a nyilvánosság előtt zajlanak. A felhasználók maguk irányíthatják a tendenciákat, a folyamatokat, és ez nagyon jó mindenkinek. Ahogy fentebb írták, a zárt cuccok esetén a dobozszám a fontos, a nyílt forrás esetén pedig a felhasználók és a fejlesztők szabad akarata, befolyása, szabadsága.
Az, hogy bizonyos projektek vezetői, fejlesztői, ilyen-olyan "gyermeteg" vitákat és satöbbiket zajlanak, az egy dolog. És?
A kód nyílt, és a szoftver ebből áll.

( buran | 2006. 04. 21., p – 09:02 )

A MS-programozók is olyanok, mint a többi programozó: mivel folyamatosan fejlődni kell, sokszor kódolás közben tanulnak meg új technológiákat, rosszabb esetben programnyelvet, tehát az, hogy hibáznak, teljesen nyilvánvaló. Így hát felesleges arról beszélni, hogy "beépítik" a hibákat a programba... MS-nél (gondolom) a kódot látja a projekt team, jó esetben azok, akik a kódot átvizsgálják, meg a belső teszt során is sok bug ki tud jönni; de ez még mindig sokkal kevesebb, mint a nagyobb OSS projektek körül hemzsegő embertömeg.

;-(

Gondolom ezt a hozzászólást más cikkhez akartad postázni, mert ehhez a cikkhez konkrétan semmi köze.

Az Eweek cikkekben arról volt szó, hogy rejtegetik (titokban fixálnak), hogy _mit javítottak ki_. Senki nem beszélt arról, hogy mennyi hibát vétenek, vagy hogy építenek be. Meg hogy milyen skill-jeik vannak.

--
trey @ gépház

Arra reagáltam, hogy valaki azt mondta, hogy MS belegyártja a hibákat a szoftvereibe. Erre írtam, hogy mindenki belegyártja, CSAK az OSS szoftvereknél többen nézik a kódot. Ez egyenes hozzászólás a "nyílt vagy zárt forráskód" beszélgetésre, fentebb. "Képesség egynél több szempont figyelembe vételére? :-)"

De tulajdonképpen miért is írsz? Simán töröld le a hozzászólásokat, amit írok, persze a "windowsbuzik" meg "anyád" szintű hozzászólásokat hagyd meg, és akkor a fórum is eléri az irc-s szintet. Nem tudom, hogy miért kell beszólni folyamatosan a hozzászólásaimra. Ha az kell, hogy benne legyenek a kulcsszavak, akkor itt vannak: titokban,fixálják,Microsoft,hibák,Eweek,rejteget.

;-(

>> az OSS szoftvereknél többen nézik a kódot
ez önmagán kívül nem sok mindent jelent (pro/kontra), a módszeres tesztelést nem helyettesíti 30000 kódon átfutó Pistike

>> "Képesség egynél több szempont figyelembe vételére? :-)"
ezt fentebb egy kérdésre válaszolva írtam (kb annyit tesz, hogy a biztonság, amin folyton lovagolunk, 1db szempont a nagyon sok fontos közül)

> 30000 kódon átfutó Pistike

Miért feltételezed, hogy Pistikék nézik át? Vannak automatizált hibakeresők, nagynevű whitehat hackerek (példák nélkül írom; gondolom nem szükséges mert a hupon is jelentek meg erről cikkek). A módszeres tesztelés pedig nem a cégek sajátja, bárki megvalósíthatja a unit teszt, integrációs teszt, validációs teszt stb. lépéseket. Egyébként a Microsoft is támaszkodik erősen a felhasználók visszajelzésére, tudtommal. És egymillió majom akkor is lehet jobb tesztelő, mint 30 majom, módszertannal.

> ezt fentebb egy kérdésre válaszolva írtam

Persze, ez világos volt; csak vicceltem Trey-jel, nem ellened irányult.

;-(

Talán meg kellene tanulni thread-be válaszolni és nem a cikkre, ha nem arról beszélsz. Ha a cikkre válaszolsz, akkor úgy érzem, hogy arra reagálsz. Beszéd közben is arra fordulunk, akihez beszélünk. Kérlek, hogy jelezd, hogy kihez vagy mihez szólsz hozzá, a félreértések elkerülése végett.

--
trey @ gépház

Helytelen idekeverni a(z MS) programozókat. Ők azt teszik és úgy, ahogyan a a management utasítja őket. A managementet pedig tényleg kizárólag a profit érdekli. Minden - biztonság, szabványosság, stabilitás, felhasználóbarátság, stb -, de minden ennek van alárendelve.

És ebbe szvsz egyetlen programozó sem szól(hat) bele az MS-nél.

Jabocs, nem tudtam, hogy a programozók a marketingesek utasítására rakják bele a biztonsági hibákat az IE-be...

Én amúgy nem értem, mit csodálkozol, hogy egy profitorientált cégnél minden a profitnak van alárendelve. És ha el kell hallgatni vagy kenni a hibákat, akkor elkenik. Ez az őszinteség és becsületesség (vagy hívjam zsiványbecsületnek?) amit emlegettek, emberek között működik, de cégek között hol láttok ilyet?

;-(

Jabocs, nem tudtam, hogy a programozók a marketingesek utasítására rakják bele a biztonsági hibákat az IE-be...

Talán félreérthetően fogalmaztam. Azt akartam írni, hogy a programozók a marketingesek utasítására hagyják benne a biztonsági hibákat az IE-ben.

Én amúgy nem értem, mit csodálkozol, hogy egy profitorientált cégnél minden a profitnak van alárendelve.

Én nem csodálkoztam. Pusztán szerettem volna felhívni a figyelmet arra, amit anr írt arról, hogy miért jobb minőségűek a szabad szoftverek egy profitorientált vállalat termékeinél. Például a jelenlegi projektemben explicite ki lett mondva, hogy nem szabad 95%-nál magasabb fokú minőséget hozni. Ugyanis az az utolsó 5% minőség elviszi a projekt erőforrásainak felét. És ezzel tökéletesen egyet kell értenem. Ez az az érdekkülönbség, ami miatt sokkal jobb minőségűek a szabad szoftverek...

Szerintem.

Ugyanis az az utolsó 5% minőség elviszi a projekt erőforrásainak felét.
Ezt tanúsíthatom. A maradék 5%-ot mindkét filozófiánál max. hobbiszinten, a fejlesztők szabadidejének rovására lehet implementálni. Más kérdés, hogy a szabad szoftverek fejlesztése dedikáltan hobbiszintű, szabadidős elfoglaltságot jelent az én meglátásom szerint.
Hála Istennek sok ember hobbija a szoftverfejlesztés :)

( lgb | 2006. 04. 21., p – 09:28 )

Jo hat ez oke, csak aztan jonnek az okos fiuk, es osszehasonlitjak Windows-t/IE-t miegymast mas XXX software-ekkel (XXX=vmi open source cuccos neve behelyettesitendo) bugok szamaval stb, aztan persze kijon hogy Microsoft a legjobb hibak szama, javitasi sebesseg stb tekinteteben ...