Azonban ez az állításon nem változtat, nagyobb a rendelkezésre állása, mivel kevesebb fix/frissítés jön hozzá.
Ez így van, és van, ahol pozitív dolog. Sima usernek én is, ha disztibet kell választani, egy CentOS-t teszek fel, pont ugyanebből a megfontolásból: kevesebb változás, point releasen belül leginkább secu bug fixek (ill. néha sima bug fixek, de szinte soha új feature). Magamnak viszont valami rövid támogatású, de frissebb disztró (openSUSE). Mindkét oldal mellett van pro- és kontra.
Ha én kifizettem ezt a funkciót, hogy újratelepítés nélkül tudok frissíteni win7-ről win10-re, akkor miért nem használhatom?
Anélkül, hogy ismerném a környezetet: te azt a funkciót fizetted ki, hogy az OS és az új OS-en is támogatott MS termékek (*) nem fognak megborulni egy frissítéstől, minden más best effort jellegű. Az MS nem tud (és nem is fog) garanciát adni neked arra, hogy az új rendszeren akármilyen (akár legacy) alkalmazásod menni fog ill. ugyanazzal a sebességgel fog menni. Nem is tehet ilyet, ha pl. az új rendszerre a HW gyártója nem készít drivert és valamelyik általános driverre kell lecserélni az eszköz meghajtóját.
(*): itt azért meg kell jegyezni, hogy a Vista előtt tele volt dokumentálatlan kivételekkel az egész Windows, pl. a SimCity simán csinálhatott use-after-free-t (https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-an…), mert anélkül a W95 nem lett volna kompatibilis. Vista környékén aztán ezeket szépen külön szedték és modularizálták, ha felteszed az Application Compatibility Toolkitet, meg tudod nézni, hogy hány ezer alkalmazáshoz vannak a változatos fixek bekapcsolva.
Azonban lehetne priorizálni és olyan dolgokban is előrelépni, amely a "szürke hétköznapokat" könnyíti meg, nem pedig látványos showműsorokban mutatható be. Ilyen a teljesítmény, rendelkezésre állás, kompatibilitás javítása, stb.
A teljesítményre és a rendelkezésre állásra kell a visszajelzés (telemetria), különben vaktában lövöldöznek, hogy az átlagos gépen (amiről ugye megint lövésük sem lehet) éppen mi lassú. A kompatibilitásnál meg egyik út sem jó: ha minden alkalmazásra egyesével csinálsz dokumentálatlan kompatibilitási fixeket, akkor tényleg bloat lesz a kód. Ha viszont modulárisan kiszervezed, akkor hatalmas adatbázis lesz csak az, hogy melyik alkalmazásra milyen fixek tartozzanak. És van egy pont, aminél nem is éri meg: XP idejében rengeteg alkalmazás (a "nagyok" is) feltételezte, hogy ő rendszergazda szintű user nevében fog futni és mindenhez hozzáfér. Aztán a Vista óta ez nincs így, rengeteg alkalmazás tört el ha nem UAC-kal indítottad, de azóta a legtöbb cég megtanult értelmesen fejleszteni (persze kivételek sajnos mindig vannak :( pl. jusched.exe). Ha ott tartják a visszafelé kompatibilitást és mondjuk opt-IN jelleggel korlátozzák a usereket, a mai napig emelt privilégiumokkal futna mondjuk egy-egy böngésző, mert mi van, ha frissíteni akarja magát.
És nem azt mondom, hogy minden döntésükkel egyet kell érteni, még azt sem, hogy én személy szerint mindennel egyet értek. De vannak dolgok, ahol meg kell törni a kompatibilitást, mert a másik oldalon többet nyersz.
Ne legyünk már naívak. 20 év után tudták csak meg, hogy a power userek szeretnék átmeretezni a cmd ablakát?
Egyébként ezekben igazad van, sok legacy UI interfész katasztrófa a Windowsban, de legalább tényleg elindult egy változás (még ha én személy szerint a gépház láttán legszívesebben a billentyűzetet a monitorba vágnám is :) )
Vagy nem tudják régi hardvereken tesztelni a kiadásaik teljesítményét, nincs régi nyomtatójuk?
Nem ismerem az MS belső QA rendszerét, meglennék lepve, ha nem lennének "régi" hardverek (a hivatalos kompatibilitási lista legalja), de ezen szinten marha nehéz automatizáltan tesztelni. Oké, legyen egy régi géped, amin teszteled a Win-t. Melyiket teszteled rajta? Friss telepítés egy naprakészre integrált telepítőről, frissített telepítés egy Win10 RTM installról (RTM - Anniversary - ...), frissített telepítés egy Win7-ről és/vagy Win8-ról és/vagy Win8.1-ről. Ha meg azt mondod, hogy mindet, akkor a gép ideje nagy részében az OS-ek telepítésével lesz elfoglalva, vagy máris 5 régi gép kell. És ezzel egy konfigurációt teszteltél.
sok olyan probléma van, ahol tisztán jobb tervezéssel lehet javítani a rendszeren, anélkül, hogy egy másik paramétert lerontanánk (tehát nincs sebesség-memóriahasználat tradeoff).
A tisztán jobb tervezéssel oké, csak az többnyire user API-t is érint. Pl. a fenti példában a gyorsított ablakkezelésről. Visszaportolni a 20+ éves legacy rendszerbe, hogy ne a CPU raszterizáljon jól ismert szoftveres implementációkkal a kompatibilitás megtartásával egy egész veszélyes vállalkozás. Viszont odáig eljutottak, hogy a kompozitálást a GPU csinálja még a legacy appoknál is (ugye egy WPF-nél alapból kapod a HW gyorsítást, mert azt már úgy tervezték). Emlékszel még XP-nél is, milyen jól fehérre lehetett festeni a képernyőt, ha volt egy ablakod, ami épp nem válaszolt és egy másik, ami igen? (és itt már az utolsó felvetésedre a "legmagasabb prioritás a felhasználóknak abban az időpontban") És mivel megléptek egy már szükséges lépést (kompozitálás HW-vel), onnantól kezdve az "eye candy" már nem nagy mutatvány (mert meg van a memóriában az összes ablak képe, szépen külön elrendezve stb.). A ctrl+tab-os "nagy preview"-s ablakváltó... meh, kit érdekel. Az Alt-tab-os ablakváltónál az, hogy látod az ablak képét viszont már növelheti a user produktivitását (mert nem kell mondjuk 6 ablakon végigkattintgatnia, ha mindegyiknek hasonló a címsora), ugyanígy a tálcás előnézet. És mivel az architektúrális váltás (épelméjű kompozitálás) megvolt, mert már szükség volt rá, ezek már gyakorlatilag minimális erőforrással (mind fejlesztési idő, mert annak nagy része a WDDM-re ment el, mind futási teljesítmény, mert csak egy már meglévő képet kell kirajzoltatni vele a képernyőre) megvalósíthatóak voltak. És én pl. már érzem a produktivitásomon, ha egy olyan rendszer elé ülök le, ahol ezek nincsenek meg.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)