A kompatibilitás egyúttal visszafogja a fejlődést, időnként muszáj változtatni egy-egy hibás tervezésen, még akkor is ha ez fáj másoknak. A Windows talán legnagyobb hibája, hogy a végletekig ragaszkodnak a visszafelé kompatibilitáshoz. Sok lehetőségük nincs hiszen a régi abadonware, de még használt programok senki sem fogja újrafordítani vagy neadjisten portolni az új API-kra.
Semmi bajom a fejlodessel, es a pozitiv peldakent hozott AmigaOS/MorphOS parosnak is eppen eleg baja van a regi, az API-t ossze-vissza hasznalo alkalmazasok tamogatasaval, meg azokkal az egykori featurekkel, amiket ma mar inkabb bugkent tartunk nyilvan (bar az is megerne egy miset, hogy miert). De nyilvan a fenti ket rendszer a kompatibilitas extrem peldaja.
Az egesz problema tulajdonkeppen annyi, hogy a kernel fejlesztok a fejlesztes "gyorsitasa" (szerintem meg inkabb a sajat kenyelmuk) erdekeben feladtak a stabil kernel agat, hogy elkeruljek a nagy verziovaltasnal jelentkezo hosszas szopasokat. Ezzel persze csak annyit ertek el, hogy nem csak a fejltesztok/betateszterek szopnak, es nem csak verziovaltaskor, hanem MINDENKI szop, es folyamatosan. Ez a fo problema. Pedig a migracio eleve azert volt szopas, mert semmifele kompatibility layer nem letezik a kernelverziok kozott.
Senki nem szolna egy budos szot se, ha atvarialnak pl. a driver API-t pl. a 2.6 -> 2.8 -> 2.10 stb kozott, mikozben a 2.6 mondjuk meg tudna a 2.4-et, a 2.8 a 2.6-et es igy tovabb visszafele. Userspace dolgai detto. A kompatibilitas teljes ignoralasa es a vegnelkuli visszafele support kozott van egy arany kozeput. Meg kene talalni, mert ugy lehetne igazan jo OS-t irni... IMHO.
(Egyebkent jo kis flame-et generaltam ide, ez mar tetszik, hehe. :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-