( Hunger | 2006. 12. 30., szo – 10:02 )

Figy en hasznalok kereskedelmi os-eket is, semmivel nem nagyobb teher a linux, sot soxor kissebb a sajat kernelfadat fenntartani, mint a masok altal takolt binaris patchekkel elhalmozott rendszeren (rosszabb esetben uj os verzio 2 hiba javit 3 hiba keletkezik (pl. IOS) szarozni.

Nem tudom IOS-al kapcsolatban milyen problémád volt, de azért azt nehéz elhinni, hogy (időben és darabszámban) azonos mennyiségű hiba jött elő vele kapcsolatban, mint mondjuk Linuxal... Már csak azért is, mert IOS egy eléggé speciális feladatra szánt rendszer és a kódjának nagysága sem közelíti meg a Linuxét.

Nem hinnem, hogy a bonyolultabb rendszer karbantartasa egyszerubbe valik parancsszora, a fejlodes meg szukseges, az luxus lenne.

A Linux bonyolultabb rendszer, mint az IOS. A 2.6 bonyolultabb, mint a 2.4.

A security igeny legyen 3party vagy saját kernelfa javitas, ha annyi rendszert tartasz karban akkor megeri..

Kérdezd meg a PaXTeamet vagy spendert (vagy bárkit, aki third-party patchet készít Linuxhoz), hogy mennyi idejét viszi el az, hogy a 2.6 újabb verzióit próbálja követni, a saját kódját portolja az új verziókra. Nem egyszerű feladat. Céges környezetben pedig szinte lehetetlen. Nem véletlenül van szarban a Google sem a saját, összetákolt kerneleivel. Irgalmatlan erőforrásokat emészt fel egy saját kernelfa fenntartása.

A beirasommal azt akartam jelezni, hogy ugyan annak nem mond ellent amit irsz, de a 2.8 idejen 2.6 -ot ajanlasz majd csak szerverre...

A 2.4 idején volt 2.5, amelybe mentek a fejlesztések és a 2.4-be pedig csak a javítások, mégis látható, hogy így is ~ 2.4.30 körül lett olyan állapotú, amelyre az ember bátran meri azt mondani, hogy kiforrott. 2.6-nál nincs fejlesztői ág, lapátolják be az új kódokat akkora mennyiségben, hogy azt rendesen átnézni lehetetlenség. Sszoktam mutogatni ezt, ami már meglehetősen rég óta így van. Ha egy patchet így beemel Linus a saját fájába, akkor naívság lenne azt képzelni, hogy a kódot alaposan átnézi. És ez még csak nem is valami bonyolult security bug, amelyet csak hosszas kód tanulmányozás közben lehet felfedezni. Szóval ha lesz is 2.8, akkor is rengeteg időnek kell eltellnie, hogy a 2.6 letisztuljon, de azt hiszem ezt írtam előtte is. Az pedig könnyedén kikövetkeztethető, hogy jóval több időnek kell eltellnie, mint 2.4-nél.

Szoval az alternativa hol van?

Nem mondtam, hogy van alternatíva, csak kicsivel jobb és kicsivel kevesebb szívás. Ez nekem Linux esetén egyelőre a 2.4-et jelenti, ha komoly feladatra szánt szerverről van szó.