Keresés

Új hozzászólás Aktív témák

  • Gregorius

    őstag

    Szűnjön meg az a helyzet, hogy egy három vagy négy éve futó Windows – többek között az előbb említett – terhelés miatt egyre lassabban működik, s így a probléma megoldásaként alkalmazott teljes újratelepítés rengeteg időt és energiát vesz el
    Nem mondom, hogy nincs igazuk sokmindenben és lehetségesnek tartom, hogy a Windows 7 sok felvetésre választ hoz, de ez a mondat számomra nevetségessé tette a jelentést. Mondom ezt úgy, hogy 5 éve ugyanaz a windóz van a gépemen és ez alatt az idő alatt már jópárszor teljes egészében kicseréltem alatta a hardvert (az egyetlen eszköz, ami a legelső szetapból még megmaradt az az RTL8139-es matuzsálem hálókártyám, minden más már változott). És sokmindennek elmondanám, csak lassúnak nem.

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz t72killer #8 üzenetére

    van egy tippem, ha ugyanaz a win, akkor valszleg a wincsit sem cserélted 5éve
    Csak háromszor. A PowerQuest DriveImage csodákra képes. De ha nagyon megerőltetem magam, még 3rd party alkalmazás sem kell hozzá és ntbackuppal elintézem. Csak az nem fél óráig tart, hanem jóval tovább.
    Épp tegnap végeztem el a műveletet az egyik gépen a cégnél, partíciók átméretezésével egybekötve. A Windows észre sem vette, hogy hdd-t cseréltem alatta.

    - A frissítések és a hozzájuk tartozó uninstall infók 1 giga körül jártak (kiirtottam, mert elfogyott a hely).
    Az uninstall infók kigyilkolhatók a rendszerből vagy úgy kell a köteget telepíteni, hogy ne is jöjjenek létre.

    - A temp könyvtárban mindig felgyűlik a szemét, nem üríti ki. Időnként kézzel kell kiürítenem könytárakat mert elfogy a hely.
    Újraindításra automatizálható.

    - A közös dll-raktározásról le kéne szokni... minden program csak a saját könytárába rakhassa a cuccait. A régi programok számára is tudná emulálni, hogy azt higyjék a winbe pakolnak.
    Ezzel akkor van probléma, ha két program komolyabban kommunikál egymással, persze ettől még lehetnek a saját könyvtárában a fájljai. De pl. a MSVC++ runtime libraryból nem hiszem, hogy hatvan példányt szeretnél a gépen.

    - A programok egymástól független "dobozban legyenek", minden konfig, minden registry növelő adattárolás, minden fájl.... ha uninstallálom a programot akkor maradéltalanul legyen letakarítva.
    Ez egyrészt és elsősorban a program gyártójától függ (és ebben a tekintetben tényleg szégyenletes), másrészt van, amikor technikailag kivitelezhetetlen. Uninstallkor lehet, hogy bizonyos felhasználó profiljai nem állnak rendelkezésre (akár biztonsági akár technikai okokból), azokból nem lehet törölni a beállításokat, illetve központi profil esetén nem lehet megállapítani, hogy kell-e egyáltalán, mert a program egy másik gépen továbbra is megmarad. A Windows meg önerőből nem fogja neked megkülönböztetni, hogy mi a beállítás, amit törölni kell, és mi a programmal előállított dokumentum, amit nem.

    Ja és az a bibi, hogy nem nő olyan gyorsan a merevlemezek sebessége, mint ahogy a programok mérete nő. Azért indul olyan lassan és azért tűnik lomhának.
    Azért indul olyan lassan, mert a Windows egy csomó kompatibilitási ellenőrzést meg beállítást végez mielőtt egyetlen utasítást végrehajtana a programból. Pl. a jó öreg SimCity futtatásakor másként viselkedik a memory manager egy SC allokációs bug miatt, ami DOS-ban nem értekelt senkit. Meg lehet nézni a Singularity-t, hogy hány ciklus kell neki egy program elindításához. Az összes mai OS-t lekörözi. Na abban nincs semmiféle appcompat fícsör.

    (utólagos sp telepítés gondolom szintén felesleges uninstall infó raktározást jelentene)
    Van /nobackup kapcsoló, szélsőséges esetben pedig inplace upgrade-del telepíted az integrált telepítőlemezről és a beállításaid is megmaradtak.

    - Mi a bánatért szenved az ikonok, startmenü elemeienek összevadszásával.. az a pár mega lehetne a memóriában folyamatosan...
    Az a pár mega folyamatosan a memóriában van, feltéve hogy van annyi memória, hogy a system cache-be belefér.

    (azaz ne pár kb-on akarjon spórolni a közös dll tárolással meg lemezről vadásszással, mikor a driver cache gigabájtos méretű)
    Érdekes. Nekem legjobb esetben is 100MB alatt van. A Nero telepítési információjának egyetlen fájlja eléri ezt a méretet. Bár rossz példa, mert a Nero ritka bloatware lett az elmúlt években.

    - Külön virtuális gép a fejlesztőeszközöknek.
    A béta fejlesztőcuccokat ilyenbe szoktam rakni, de a fejlesztőeszközöknek tipikusan rengeteg memória kell, hogy rendes tempóban működjenek. Úgyhogy vagy nagyon sok ramot pakolsz a gépbe és ennek elég tetemes részét a virtuális géphez rendeled, vagy a hostban fejlesztesz.

    a (#14) azbest mondókám nagyrészét úgy meg lehetne csinálni, hogy teljes mértékben kompatibilis lenne a jelenlegi rendszerrel.
    Csak a plusz egy réteg indirekció miatt még lassabb. Vistában már van valami hasonló, de az sem teljes.

    Az SSD-nek az iras art, update-ek meg olyan gyakran nem jonnek ki, hogy az kulonosebben megviselje oket
    Van elég event log meg teljesítménynapló a rendszerben update nélkül is, ami kellemesen terheli az SSD-t írással.

    Hogy a win sokat eszik, belassul meghízik, már megszokott. Sőt, tegye mindenki a szívére a kezét, hiányozna is ha nem kellene újrapakolgatni. :DDD
    Hiányzik a francnak! :P

    - a registry felügyelete: miért kell még most is third party software-eket használni erre?
    Nehogy a RealNetworksnek megint nagy legyen a pofája. :P

    (hogy kukacoskodjak, még +1: a cserélhető flashdrive-ok miért disk serial number alapján kerülnek újra és újra felismerésre
    Tudtommal nem disk hanem volume serial number alapján. És nem csak a flash drive-ok, hanem nagyjából minden hard drive esetén legyen az USB, IEEE, eSATA vagy akármi.

    Akkor talán könnyebben érteném, ha külön-külön új betűjelet kapnának, ehelyett azonos típusok esetén is végig kell menni a New Hardware Found... eljáráson (mennyire terheli ez a registry-t?)
    Nem vészes, ugyanazokat a bejegyzéseket kapja meg, mint bármelyik partíciód. És még az eszközkezelővel is törölhetők, szóval ha utadban van, még registry-t sem kell buherálni.

  • Gregorius

    őstag

    válasz Cathfaern #45 üzenetére

    És a registry bejegyzéssel visszakerültünk a kályhához. Az ilyesmik hajlamosak nem karbantartódni. Lehet nézni példának az Installer referencia számlálását közös fájlokra, nem működik valami jól.
    A használható megoldás a teljes installer infrastruktúra újragondolása lenne (ld. még a Singularity deklaratív megközelítését), az viszont praktikus és kompatibilitási okokból nem kivitelezhető. Legalábbis belátható időn belül.

  • Gregorius

    őstag

    válasz zso73 #47 üzenetére

    Ha az alkalmazott algoritmusok a 64 bites adatszélességre vannak optimalizálva (feltéve hogy egyáltalán optimalizálhatók), akkor gyorsabb. Ellenkező esetben egy sima 64 bitre fordítás csupán annyit ér el, hogy duplaannyi a terhelés a processzor cache-en.

  • Gregorius

    őstag

    válasz t72killer #94 üzenetére

    #44: fura, h ennyi fáradtságot beleölsz a régi rendszer átmentésébe, ennyi idő alatt simán felhúzol 1 friss rendszert Kíváncsi vok még, hogy mire használtad a gépet? volt-e közben 5-6 vírusirtó+tűzfal-újratelepítés/váltás, hibás driver leszedés, ilyesmi?
    Pont azért "kínlódom" vele ennyit, mert rengeteg szoftverem van rajta, sokkal hamarabb végzek mindennel, mintha nulláról húznám fel a rendszert, még ha csak simán dvd->tovább->tovább->késszel rakok fel mindent, akkor is. A programok feltelepítése, a beállítások és minden egyéb átvitele jobb esetben csak napokig tartana, és közben nem ártana az állásomat is megtartani. Másrészt ha már egyszer megoldottam az adott hibát, akkor a javítás is sokkal gyorsabban megy legközelebb.
    Válaszolván kérdésedre: igen, volt többféle tűzfalam, vírusirtóm. Egy esetben még alkalmanként kernel szinten össze is akadtak - eltartott egy ideig, mire kinyomoztam, hogy mitől nem indulnak el olyan banális alkalmazások, mint a jegyzettömb :)

Új hozzászólás Aktív témák