Aranyos

https://www.origo.hu/techbazis/20190522-windows-10-may-2019-update-1903…

"a telepítése után lefoglal körülbelül 7 GB extra helyet a frissítőszolgáltatásnak. Ebben az a ráció, hogy így biztosan sikerül majd letölteni és telepíteni a jövőbeli frissítéseket a számítógépekre"

Hozzászólások

mit gondolsz kinek vetted a géped? tán saját adatot akarsz rajta tartani? ugyan már, vegyél plusz tárhelyet..

--
nincs aláírásom

Vagy simán lecseréli az ember az 5 éves gépében a 120-as SSD-t egy 240-esre, ahogy én is tettem (gagyi tablet tulajok 32 GByte beforrasztott háttértárral sajna hátrányban). Előbb avul el az I3-as procim a CPU bugok foltozása miatt, minthogy magának a Win10-nek kevés lenne. Mindez kijött 6k-ból, mert 10k-ért vettem a Crucialt és 4k-ért passzoltam el az Intelt. De még a 120-ason is megfértem volna, de kényelmesebb volt így. Insiderben vagyok amióta lehet és még csak egyszer kellett teljesen újrahúzni egy elkefélt Insider preview miatt.

Ezt te sose fogod megérteni. A part széléről belepofázni a pancsoló gyerekek dolgába nem ildomos. Szóval, kedves linuxfanboyok, miért fáj nektek ha a Windows több helyet kér magának? Jaaaa, hogy ti is ezt használjátok?! Az más... Tudom, tudom, Windows összeesküvés van, éljenek az exe-k!

-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Semmi linsux fanboyság. A válaszom a kolléga "storage is free" felfogásának szólt. És mint lentebb olvashatod, itt a probléma azon van elsősorban, hogy megint a mikrószaft döntötte el a felhasználói helyett, hogy kell-e ez nekik; elveszik a felhasználótól a kontrollt, úgyhogy jól mondta a szálnyitó: "mit gondolsz kinek vetted a géped" és ennek semmi köze nincs ahhoz, hogy a Linux ökoszisztéma mekkora bloated bugware hoster lett (ld. shitsteamd, gtk3, etc.). Hogy megfordítsam a fanboyvádat: az nem mentesíti az ms-t semmi alól, hogy a Linux is fos; ez ilyen szemellenzős windózfanboi mantra, nem érv.

Egy 4k-s JPEG háttérkép 0.5 MB-tól 2-3 MB-ig foglal helyet kb., de számoljunk 1 MB-tal, hogy könnyű legyen. Ugye nem akarod azt mondani, hogy többtízezer 4k-s háttérképet adnak a win10-hez? Ikonok pláne. Egy PNG-ben tárolt ikonkészletet kB-okban mérnek, még akkor is, ha mondjuk 64x64-es. Az SVG-ben tárolt ikonokat dettó. Az azt jelenti, hogy szabályszerűen több tízmillió kéne belőle, hogy kitöltsön többtíz GB-ot.

Hogy mi teszi ki szerintem?
Egyfelől az ms féle keretrendszerek, library-k, (.NET, DirectX, whatever) is több gigát nyomnak (konvulens megoldások, sokszoros absztrakció és döglött kód miatti bloat), de ráadásul a kiscsillió library redundánsan is van a lemezen. (Backup, korábbi verziók, stb.) Másfelől pedig mindenféle átmeneti tárolók, amiket a felhasználók sosem ürítenek, tele letöltött telepítőkomponensekkel, leírófájlokkal és a jóég tudja miféle szeméttel. Harmadfelől ott van a registry, amit "megfelelő" használat mellett szintén GB-os nagyságrendűre hízhat és ez is redundánsan van tárolva. (Rollbackhoz, stb.) Negyedfelől a third party programok, amik mind hozzák magukkal a saját függőségeiket, így aztán ugyanaz a third-party library/framework tízszer lesz feltelepítve. És ha már telepítés, ötödfelől itt vannak a különféle telepítők, amik szintén minden fost beleszarnak a rendszerbe, az uninstal meg vagy eltakarít mindent, vagy leginkább nem.

Hogy mi teszi ki szerintem? Röviden: redundánsan tárolt bloated kód és adatszemét.

+1

És mivel ez (a régi DLL / lib) is kellhet valahova, meg az is kellhet akár, így senki nem mer hozzányúlni az MS oldalról, hogy rendet csináljon. Továbbá a sok tárhely használat pörgeti a hardver ipart. Ahol Windows-on kell dolgozni, mert a vállalati alkalmazások csak azon futnak, ott nem kérdés, hogy ha túl sokat foglal a Win10, akkor átállnak-e linuxra vagy vesznek nagyobb SSD-t...

Sakk-matt,
KaTT :)

> Továbbá a sok tárhely használat pörgeti a hardver ipart. Ahol Windows-on kell dolgozni, mert a vállalati alkalmazások csak azon futnak, ott nem kérdés, hogy ha túl sokat foglal a Win10, akkor átállnak-e linuxra vagy vesznek nagyobb SSD-t...

Így van, csak ezt már le se mertem írni, mert akkor megint konteós/hajbazerista lettem volna. :)

"Egy 4k-s JPEG háttérkép 0.5 MB-tól 2-3 MB-ig foglal helyet kb., de számoljunk 1 MB-tal, hogy könnyű legyen. Ugye nem akarod azt mondani, hogy többtízezer 4k-s háttérképet adnak a win10-hez?"

Ikonokat, videókat, animációkat. Ugyanez igaz a programokra is. Legjobb aktuális példa a Starcraft Remastered. A '98-as kiadás egy fél CD-nyi cucc, 640x480. A Remastered ugyanaz a gameplay, de 4k felbontásra feljavítva, nem férne el egy DVD-n.

Nyomhatod a bloatware faszságot, de szerintem ülj le és gondolkodj egy kicsit a dolgon, hogy mennyit változtak 20 év alatt a felhasználói szokások és igények.

--
https://iotguru.live

Izé, ez most komoly? Az megvan, hogy egy operációs rendszerről beszélünk és nem egy játékról? Most komolyan meg akarod magyarázni, hogy azt a több tíz gigányi tárhelyet az ms mind 4k videókkal meg képekkel töltötte fel? Ez több mint nevetséges.

Hogy megfordítsam amit mondtál: nyomathatod a 4k faszságot, de inkább gondolkodj el azon, hogy egy operációs rendszernél, ahol azt a pár háttérképet leszámítva mindent rajzol a rendszer, ott mennyire számít, hogy a felbontás megnövekedett... (Pl. még az ikonok is lehetnek vektorgrafikusak, akkor pedig a felbontás zéró ugyanúgy relevanciával bír, mint az ablakok esetén.)

"Izé, ez most komoly? Az megvan, hogy egy operációs rendszerről beszélünk és nem egy játékról?"

Nézd, egy operációs rendszer manapság tele van grafikával, animációval, videóval és multimédiával. Egy nyomorult VPN kliens is már felmásol 200 MBájt körüli adatot, aminek a nagy része multimédia.

"ahol azt a pár háttérképet leszámítva mindent rajzol a rendszer"

Bocsánat, de lófaszt van így. Te mennyit fejlesztettél az utóbbi időben?

--
https://iotguru.live

> Nézd, egy operációs rendszer manapság tele van grafikával, animációval, videóval és multimédiával. Egy nyomorult VPN kliens is már felmásol 200 MBájt körüli adatot, aminek a nagy része multimédia.

Jó, fel fogok rakni valahova egy windóz 10-est és statisztikát csinálok a fájltípusokról, majd meglátjuk, hogy mennyi benne a "multimédia".

> Bocsánat, de lófaszt van így. Te mennyit fejlesztettél az utóbbi időben?

Mást se csinálok, lévén ebből élek.

"Jó, fel fogok rakni valahova egy windóz 10-est és statisztikát csinálok a fájltípusokról, majd meglátjuk, hogy mennyi benne a "multimédia"."

Az kicsit strapás lesz, mert a dll fájlokban is van multimédia, tehát ha csak fájltípusokat katalogizálsz, abból értelmes dolog nem fog kijönni.

"Mást se csinálok, lévén ebből élek."

És az frontend vagy backend?

--
https://iotguru.live

> Az kicsit strapás lesz, mert a dll fájlokban is van multimédia, tehát ha csak fájltípusokat katalogizálsz, abból értelmes dolog nem fog kijönni.

Hát persze, persze, hogyne, a derék mikiszoft dll fájlokban tárolja a 4k videókat és háttérképeket, ez nemhogy logikus, de evidens... (Jézusom...)
Ikonok esetleg előfordulhatnak egyes DLL-ekben, de az elenyésző részét teszi ki a teljes méretnek. Nyilván, ahogy ikont, úgy akármi mást is be lehet ágyazni resource-nak a dll-be, csak semmi értelme. Ha van is háttérkép egy dll-ben, akkor az sem full, hanem csak tile.

Na, felbootoltam az egyik céges minigépet, amin egy majdnem szűz win10 van (csak a mi programunk volt telepítve) és kilistáztam az összes fájlt a C meghajtón (több meghajtó nem volt):

dir /s /a:-D > ALLFILES.TXT

Ebből kiszedtem az user könyvtárát, mert az nem publikus, meg nem is releváns, lévén nem része a rendszernek, de amúgy nem volt benne semmi, csak az említett programunk és konfigjainak/komponenseinek pár MB-ja, meg kb. 100 MB-nyi DAT fájl (gondolom az user-specifikus registry) és egyéb érdektelen szemét.

A fájl referencia gyanánt elérhető itt: http://oscomp.hu/depot/ALLFILES.TXT

Erre még ráeresztettem egy shell parancsot, mert nekem csak a fájlok és a méretek kellettek:

grep '../../....' ALLFILES.TXT | sed 's/..\/..\/.... ..:.. .M//g' | awk '{$1=$1};1' > winfiles

Utána összedobtam egy szutyok PHP scriptet, ami csoportokba rendezte az összesített méreteket. Biztos nem tökéletes, mert amint látszik, le kellett kezelni pár kivételt, hogy olyan is van, hogy bin.*, vagy olyan, hogy dll_*, valószínűleg nem vettem fel mindet, de a maradék max. pár kB-ot tehet ki; nem szignifikánsak.

A PHP elérhető itt: http://oscomp.hu/depot/groups.php.txt

Lefuttatás után a kapott winstats.txt tartalmából egyértelműen látszik, hogy a windóz jórésze bizony DLL, EXE és az upgrade mindenféle archívuma/image-e (CAB, ESD, WIM), valamint átmeneti tárolók és a registry DAT fájljai. A cca 18 GB-nyi adatból videó volt kb. 80 MB és kép volt kb. ~110 MB (59 MB PNG, 37 MB JPG, 12.5 MB GIF); egyszóval a multimédia kb. 1%-át teszi ki az egésznek.
Külön felhívnám a figyelmet arra, hogy a linkelt ALLFILES.TXT-ből az is látszik, hogy mennyire redundánsan van tárolva egy raklap minden a rendszeren; pl. a notepad.exe vagy tízszer is létezik. Nyilván 10 Notepad sem foglal sok helyet, de itt a tendencia a lényeg, hogy ugyanaz a kód többször létezik a rendszerben.

> És az frontend vagy backend?

Is-is. Ha kell UNIX daemont írok, ha kell grafikus alkalmazást, ha kell shellscriptet, vagy épp webes fost.

"Hát persze, persze, hogyne, a derék mikiszoft dll fájlokban tárolja a 4k videókat és háttérképeket, ez nemhogy logikus, de evidens... (Jézusom...)"

Pedig de, képes rá, miért kellene különálló fájlokban tárolni? Például egy Java alkalmazás minden multimédiája belekerül a sokszor egyetlen JAR fájlba, az Android Studio összes képe az egyetlen ikonja és mégis 1 GB körül van a mérete.

Persze, rogyásig tele van képekkel, videókkal, egyéb multimédia fájlokkal, de a szösszeneted azt mondta volna róla, hogy összesen van benne egy 128x128 pixeles kép, ami 9,8 kBájt méretű...

"A cca 18 GB-nyi adatból videó volt kb. 80 MB és kép volt kb. ~110 MB"

Ja, nyilván. Egy kicsit komplexebb ez a dolog ennél.

"Is-is. Ha kell UNIX daemont írok, ha kell grafikus alkalmazást, ha kell shellscriptet, vagy épp webes fost."

Szóval backend és abból is leginkább nem Windows... oké. Mindent értek.

--
https://iotguru.live

> Pedig de, képes rá, miért kellene különálló fájlokban tárolni?

Nem ezt mondtam, hanem azt, hogy nem a DLL-ekben tárolja, mert ott semmi értelme, beszórni a kód mellé erőforrásnak több megányi szart. Csak lassulna tőle a DLL betöltése, ami sok DLL esetén összeadódik és egy reumás csiga sebességére fogja kárhoztatni a windózt; system library-kről beszélünk, nem baj? Abba minek dugnának 4k-s háttérképeket, meg videókat? A CAB-okban talán előfordulhatnának, de abból is összesen van 750 MB-nyi és valószínűleg abban is további binárisok vannak, nem multimédia...

> Például egy Java alkalmazás minden multimédiája belekerül a sokszor egyetlen JAR fájlba, az Android Studio összes képe az egyetlen ikonja és mégis 1 GB körül van a mérete.

De ember, az teljesen más, könyörgöm! Az előbb a Starcraftot, most meg ezt hasonlítod a windowshoz, kb. almát a hidrogénplazmával komolyan; operációs rendszer komponensekről, system libraryk-ről volt szó, nem egy Javás alkalmazás szemetéről... Arról nem is beszélve, hogy mind a Starcraft, mind a Java app adat-archívumokban tárolja a cuccait - lévén az arra lett kitalálva - és nem egy system libraryben - lévén az nem arra lett kitalálva.

> Persze, rogyásig tele van képekkel, videókkal, egyéb multimédia fájlokkal, de a szösszeneted azt mondta volna róla, hogy összesen van benne egy 128x128 pixeles kép, ami 9,8 kBájt méretű...

Mutass rá a windows DLL-jei között legalább egy konkrét elemre, amiben 4k háttérképek és/vagy videók vannak. Ha legalább egy példát tudsz mutatni, akkor már érdemes lenne időt szánni egy script megírására, ami végignézi a DLL-eket, hogy milyen erőforrások vannak benne. Viszont addig ez az állítás az abszolút nonszensz kategória.

> Ja, nyilván. Egy kicsit komplexebb ez a dolog ennél.

Kifejtenéd, hogy miben? Mert azt eddig nem sikerült, csak kapaszkodsz ebbe a nem igazolt marhaságba, hogy de igen, többtíz gigányi multimédiás anyag van a win10 dll-jeiben, miközben egy szűz win10 nincs is több tíz giga...

> Szóval backend és abból is leginkább nem Windows... oké. Mindent értek.

Semmit sem értesz, de ezek után már nem is lep meg. Szépen eljutottunk a személyeskedésig. Hol mondtam én, hogy windows nem? A grafikus alkalmazás szerinted mit takar? A cég szerinted Linuxra kéri a grafikus alkalmazásait? Egy munkaidőterminál, vagy parkolóautomata felülete, vagy éppen a beágyazott eszközeinkhez fejlesztett LAN-scanner hol backend? Fingod nincs róla, hogy miket fejlesztek, csak fölényeskedsz és személyeskedsz. Mondanám, hogy elfogytak az érvek, de azok eddig sem voltak; én kimértem, hogy mi van egy szűz winfostízben, konkrét számadatokat adtam, te viszont nem mondtál eddig semmit, viszont a számokat meg lesöpörted abszurd összehasonlításokkal (videojáték/jávás app vs. system libraryk), nem igazolt állításokkal (a mikiszoft a DLL-ekben többtíz gigányi képet meg videót tart) és azzal próbálod meg ezeket a marhaságokat igazolni, hogy az érveim és adataim helyett engem támadsz, ráadásul hamis vádakkal (csak bekend és nemvindóz).

Mi lenne ha az adataimat adatokkal próbálnád cáfolni és nem bullshittel?

Érvek még mindig nincsenek, csak üres fölényeskedés... Jó, akkor ássunk mélyebbre!

Írtam még egy PHP-t, ami az előbbi listából összeszedi az összes DLL-t és a méretüket, az ismétlődőeket csillaggal jelölve.
A PHP: http://oscomp.hu/depot/biggest_dll.php.txt
Az eredmény: http://oscomp.hu/depot/dll_sizes.txt

A nyertes egy bizonyos microsoft.photos.dll 53.3 MB mérettel, ő a legelhízottabb DLL a rendszerben. Keressünk rá az első fájlban, hogy helyileg hol van: C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2018.18091.17210.0_x86__8wekyb3d8bbwe

Nyissuk ki ResourceTunerrel:
http://oscomp.hu/depot/restuner_microsoft_photos_1.png
http://oscomp.hu/depot/restuner_microsoft_photos_2.png

Csak pár kurzorikon, együttesen sem töltenék ki egy Amiga 500 memóriáját. (Egész pontosan valami 440 kB.) Mitől ilyen bődületesen nagy akkor ez a DLL? Eresszük rá Idát!

http://oscomp.hu/depot/ida_microsoft_photos_dll_with_debug.png

OUCH! Szóval, akármi is ez a DLL, a mikiszoft a debug infókat elfelejtette strippelni belőle, azért ilyen kurwa kövér! Hát ez fail! És ez még hagyján, mert ez csak egy DLL volt, de nézd meg, hogy az ezután következő DLL-ek is hasonló méreteket mutatnak (xboxapp.dll? Kétszer is? Ezmiez?) és azok is biztosan nem a sok csokitól híztak ekkorára... És aztán még arra is szeretném felhívni a figyelmet, hogy csillaggal vannak jelölve az ismétlődések: pl. a diagpackage.dll pontosan ötvenszer van meg a rendszerben, vagy az mpengine.dll, az csak nyolcszor, de az mindjárt kb. 10 MB-ot nyom fejenként és ugyanez a helyzet a mscorlib.ni.dll-lel ami 4x van fennt és darabja 20 MB. És nem kell a duma, hogy de ez még mindig csak 200 MB, mert ez még mindig csak 3 példa volt, tendenciákról beszélünk; a sok kicsi sokra megy, összeadódik és a tendencia a végén többtíz GB-ig eszkalálódik...illetve, saját bevallásod alapján akár többszázig is. És nem a nemlétező 4k-s háttérképek miatt.

Én a magam részéről igazoltnak látom, amit eredetileg mondtam, miszerint a windows10 a redundánsan tárolt kód és adatszemét miatt ilyen kurwa nagy és nem mindenféle 4k szarságok miatt. Azt mondjuk még én sem feltételeztem, hogy a szemétnek egy nem is jelentéktelen részét - a strippelés hiánya miatt - a debug infók teszik ki, dehát mit kell ezen meglepődni, végülis a mikrofosról beszélünk...

Úgyhogy, megválaszolván a feltett kérdésedet: Igen, egyszerűen azért nagy, mert bloatware és nem, DLL-ben nem tárolnak háttérképeket/videókat (mert nem arról volt szó, hogy ikonok vagy thumbnail-ek ne lehetnének resource-ök) és igen, ez tényleg balfaszság lenne ilyen méretű resource-öket tömegével bekúrni a DLL-ekbe (két szó: load time) és igen a windows fejlesztői tényleg balfaszok, de nem azért, mert 4k-s háttérképeket tárolnának a DLL-ekben, hanem mert strippeletlen libraryk tömkelegét tárolják a userek PC-in, ráadásul - a jelek szerint - extrém redundánsan, sok példányban. És igen, szerintem igazam van a kérdésben, legalábbis eddig érdemben semmit nem tudtál cáfolni az összeszedett adatokból, mert a butthurt személyeskedés az minden csak nem cáfolat. És nem, ez nagyon nem lesz jó így, ha a win10 ilyen, de ilyen.

De mutass nekem egyetlen dll-t a windowsban, amiben 4k-s háttérképek/videók vannak. Vagy legalább egy hivatalos állítást erről. Ne csak a levegőbe beszélj.

Nem a felszínt karcolgatta, hanem bebizonyította, hogy miért 50MB egy szaros DLL (50 MB-nyi lefordított kód mondjuk C-ben vagy C++-ban többszázezer vagy inkább millió sor lenne).
Egyébként MS részvényed van, vagy miért kell védeni ezt a fost? Tényleg egy bloat szar. MS-nél mostanában középszerű fejlesztések folynak a marketingesek és managerek bizarr halmazának irányítása alatt. Próbálnak beletenni egy csómó fost, amiből szerintük a konkurrencia pénzt csinált, ezért nekik is kell, közben meg tesznek a régi felhasználói magra, akik még esetleg munkára (vagy akár játékra) is szeretnék használni a gépüket, és nem hozza lázba a Paint .Net-re átírasa.
Kedvencem volt az az előadás (amit itt a HUP-on linkelt valaki), ahol a fő-fő UI designer megmagyarázta, hogy pl. miért néz ki a Win8 úgy ahogy, a fő érv az volt, hogy az Apple is egy csomó pénzt keresett az UI váltással (ja, telefonon, b+, nem desktopon).
Munkahelyi Win10-em már vagy 2x kapott "feature upgradet", kb. semmit nem érzékeltem belőle.

"Nem a felszínt karcolgatta, hanem bebizonyította, hogy miért 50MB egy szaros DLL (50 MB-nyi lefordított kód mondjuk C-ben vagy C++-ban többszázezer vagy inkább millió sor lenne)."

Ja, akkor 5 GB DLL-ben mennyi sor van? Másrészt a debug információk kurva hasznosak és ezt szerintem te is értenéd, ha valaha is fejlesztettél olyan szoftvert, amit nem az általad felügyelt környezetben futtatnak. Anélkül lófaszt se fogsz tudni arról, hogy hiba esetén mi történt.

"Egyébként MS részvényed van, vagy miért kell védeni ezt a fost?"

Nem, nincs. Alapvetően szarok rá, pár havonta veszem elő, ha olyan feladat jön szembe, aminél nem éri meg Linux alatt szopni...

"Tényleg egy bloat szar."

Oké, értem, de ne csinálunk úgy, mintha egy Windows 10 ugyanazt a színvonalat hozná, mint egy Windows '95, csak közben bloatware lett, durván sok feature és statikus tartalom belekerült, ami nem látszik elsőre.

"Munkahelyi Win10-em már vagy 2x kapott "feature upgradet", kb. semmit nem érzékeltem belőle."

Értem, ez mindent megmagyaráz, oké, bloatware.

--
https://iotguru.live

"Ja, akkor 5 GB DLL-ben mennyi sor van? Másrészt a debug információk kurva hasznosak és ezt szerintem te is értenéd, ha valaha is fejlesztettél olyan szoftvert, amit nem az általad felügyelt környezetben futtatnak. Anélkül lófaszt se fogsz tudni arról, hogy hiba esetén mi történt."

Erre csak annyit tudok mondani, hogy akkor hagyják benne az összesben. De hogy egyikben ott felejtik, a másikban nem, ez így semmit nem ér, csak rávilágít a QA hiányára.

Lehet, hogy balfaszok. Lehet, hogy abban van debug információ, ami fontosabb komponens. Lehet, hogy történelmi okai vannak. De annak mindig tudok örülni, amikor olyanok balfaszoznak, akik amúgy közelében nem voltak még komplex programfejlesztésnek.

--
https://iotguru.live

Attól, hogy lássam, hogy valami szar, nem kell, hogy én csináljam.
Egyébként voltam már olyan fejlesztés közelében, ahol a legfontosabb dolog az volt, hogy tegyünk bele hétről-hétre újabb és újabb featuret (mert a sprintnek haladni kell), aztán az, hogy az egyész egy nagy bughalmaz, annak javítására már sajnos nem volt user-story.

De egyébként mennyi idő kell ahhoz, hogy egy find -name "*.dll" -exec strip {} \; parancsot (vagy valami hasonlót, elvégre ott a szuper powershell), végigfuttassanak release előtt?

És ezt honnan tudod, hogy mi minek a közelében voltunk, honnan tudod, hogy miféle komplexebb programfejlesztésben vettünk részt, vagy sem? Honnan tudod? Mire alapozod? Egyáltalán mi számít nálad komplexebb szoftverfejlesztésnek? Te miféle komplexebb szoftverfejlesztésben vettél részt?

Én meg annak tudok örülni, amikor olyan ember pancseroz le csuklóból másokat, aki a vitában a handabandán kívül semmit nem tudott felmutatni.

> Ja, akkor 5 GB DLL-ben mennyi sor van?

És mennyi 4k-s háttérkép...

> Másrészt a debug információk kurva hasznosak és ezt szerintem te is értenéd, ha valaha is fejlesztettél olyan szoftvert, amit nem az általad felügyelt környezetben futtatnak. Anélkül lófaszt se fogsz tudni arról, hogy hiba esetén mi történt.

A debug symbolok ottléte még édeskevés ahhoz, hogy infókat szerezz, hogy épp mi miatt futott vakvágányra a kódod az éles környezetben; arra a naplózást szokás használni (crash esetén esetleg annyi hasznuk van a debug infóknak, hogy a crashlogban az is benne lesz, hogy melyik fájl, melyik soránál történt a baj, de ez még mindig kurwa kevés, pláne mivel a naplófájlban lévő üzenetekből is lehet látni, hogy hol volt a crash). A debug symbolok a tényleges hibakereséshez valók, amikor valaki fogja a debuggert és step-by-step végigmegy a folyamaton és nézi, hogy mi baszódik el menetközben. Viszont ezt az átlagjúzer is tudni fogja? Nem. Az ms utasításai nélkül semmire nem fog vele menni, hogy ott vannak a debug infók, csak épp foglalják a helyet. Ha pedig úgyis szükség lesz a supportra, akkor ennyi erővel már célszerűbb opcionálissá tenni és nem lendületből telebaszni vele az összes szerencsétlen júzer gépét, hanem ha valaki épp segíteni akar az ms-nek hibát keresni, akkor odaadni a debug symbolokat és követni a support utasításait. Ezt a UNIX-okon is így csinálják, hogy a debug symbolokat külön lehet leszedni a gépre. Pl. itt vannak az Apache 2 debug symboljai debilány alá, de nem basszák bele őket a release-be... Release-ből ki szokták strippelni a debug symbolokat és nem véletlenül: a load time itt is bejátszik és itt is összeadódik fájlonként.

Az pedig nem járható út, hogy az ms-nek mindenki gépére szabad bejárása van és azért vannak debug symbolokkal forgatva a cuccok, hogy akármikor RT hibát kereshessenek benne. Hogy is van az, ha valami a Linuxokban, vagy a BSD-kben szar, akkor jön a duma, hogy nem akarunk béta teszterek lenni? Ez mi, ha nem béta teszterségre való felhasználás, csak szteroidokon, irdatlanul pofátlan módon, a beleegyezésed nélkül?

Ja, ilyenkor jön mindig az, hogy nincs idő. Arra volt, hogy egy napig válaszolgass. Arra is volt, hogy ezt az üres, fölényeskedős-rejtélyeskedős "választ" megírd. A fentebbi posztodra is volt időd. Bocs, de ez így nagyon hiteltelen és szar duma. Mi lenne, ha felmutatnál végre bármit, *AKÁRMIT*, ahelyett, hogy csak a szádat tépnéd és axiómaként állítanád be az állításaidat, elvárván, hogy azt mindenki akceptálja, csak úgy? Mutass végre egy szájbatekert DLL-t, amiben 4k-s videók/képek vannak! Egyetlen egyet!

pontosan ötvenszer van meg a rendszerben

Azért azt is nézd meg, hogy ez hol van. Pl. a WinSxS-ben előszeretettel ott van egy-egy fájl több helyen, de azok valójában hard linkek (és jó MS szokás szerint van külön utility alparancs a ténylegesen a WinSxS által ténylegesen elfoglalt terület számolására, mert alapvető fájlrendszer-műveletekre adni eszközt túl mainstream :) https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/d…)

Egyébként egyetértek, hogy tud feleslegesen hízni egy Win, meg hogy usertől függően nem szerencsés, hogy erről nem a user dönt, de ezek a döntések járhatnak olyan következményekkel, amiket nem biztos, hogy a user ismer (lásd pl. legutóbb az egyik LibreOffice topikban, hogy mekkora szar az LO, mert kéri az előző telepítőt... nem erősítette meg a kérdező, de minden valószínűség szerint valamelyik CCCleaner vagy hasonló "csodaszer" "kitakarította" a "felesleges" Windows Installer cache-t...)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Azért azt is nézd meg, hogy ez hol van. Pl. a WinSxS-ben előszeretettel ott van egy-egy fájl több helyen, de azok valójában hard linkek (és jó MS szokás szerint van külön utility alparancs a ténylegesen a WinSxS által ténylegesen elfoglalt terület számolására, mert alapvető fájlrendszer-műveletekre adni eszközt túl mainstream :)

Megnéztem, mielőtt véleményt mondtam. Egy része van csak ezeknek a WinSxS-ben, pl. a szétszedett strippeletlen microsoft.photos.dll a Program Files-ben volt. Azonfelül én értem, hogy azok hardlinkek, de pont azért, mert a méretüket valami elbaszott módon summázza és - ahogy írtad - külön cuccal lehet megnézni a valós méretét, így a normál felhasználást tekintve édesmindegy, hogy hardlink-e vagy sem, mert a windows maga is levonja a példányok összesített méretét a szabad helyből a különféle kalkulációk alatt és ennek megfelelően hiába szerepel egy dll tartalma valójában csak egyszer azon a lemezen, ugyanúgy nem lesz helyed azon a lemezen. Szoptam már be ezzel, pedig az még csak nem is win10 volt, hanem win7.

> Egyébként egyetértek, hogy tud feleslegesen hízni egy Win, meg hogy usertől függően nem szerencsés, hogy erről nem a user dönt, de ezek a döntések járhatnak olyan következményekkel, amiket nem biztos, hogy a user ismer (lásd pl. legutóbb az egyik LibreOffice topikban, hogy mekkora szar az LO, mert kéri az előző telepítőt... nem erősítette meg a kérdező, de minden valószínűség szerint valamelyik CCCleaner vagy hasonló "csodaszer" "kitakarította" a "felesleges" Windows Installer cache-t...)

Erre nem tudok érdemben válaszolni, mert a topicot nem olvastam. Azt viszont tényleg nem értem, ha a LOo már telepítve volt, akkor miért számít neki, hogy az install cache takarítva lett? Viszont mindentől függetlenül én nem tudom elfogadni azt válasznak, hogy azért dönt a rendszer a felhasználó helyett, mert a felhasználó úgy is hülye. És ha nem? Oké, legyen lekorlátozott üzemmód, de legyen olyan is, ahol a kontroll a tulaj kezében van és nem tagadja meg a rendszer a parancsokat, hogy bocsi kedves sysadmin, de neked ehhez nincs jogod; mi mondjuk meg, hogy mit tehetsz a gépeden és mit nem. Ez az ami a fő baj.

Erre nem tudok érdemben válaszolni, mert a topicot nem olvastam

Nagyon érdemi és szakmai dolog nem is lett belőle, jött egy fröcsögős a kurvaanyjátazLO-nak hozzászólás, aztán néhányan rávilágítottuk, hogy miért nem :) https://hup.hu/cikkek/20190508/libreoffice_6_1_6

Azt viszont tényleg nem értem, ha a LOo már telepítve volt, akkor miért számít neki, hogy az install cache takarítva lett?

Mert szüksége van az eredeti telepítőkészletekre, hogy tranzakcióban tudja végrehajtani a módosításokat (a topicban spec. update volt, ami leginkább egyező UpgradeCode-ú telepített csomagok eltávolítása, majd az új csomag telepítése, de ehhez kell neki mindkét telepítő [egy NSIS mondjuk ezt úgy oldja meg, hogy létrehoz egy uninstallert, ami teljesen a telepítőtől teljesen független scriptet indít, ad absurdum triviális olyan NSIS telepítő készítése, ami szépen felteszi az alkalmazást, aztán uninstall-kor legyalulja a C:\Windows-t...)

a kontroll a tulaj kezében van és nem tagadja meg a rendszer a parancsokat, hogy bocsi kedves sysadmin, de neked ehhez nincs jogod; mi mondjuk meg, hogy mit tehetsz a gépeden és mit nem. Ez az ami a fő baj.

Van ilyen (mondjuk relatíve kevés dolog van, amit elutasít a rendszer), ott meg még mindig játszik, hogy csinálsz magadnak egy SYSTEM-ként futó command promptot pl. PsExec-kel.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ja, így már értem, hogy update volt és az installer kérte a másik csomagot. Én úgy értettem amit mondtál, hogy maga az LOo kérte a telepítőt, nem a programot frissítő telepítő.

> Van ilyen (mondjuk relatíve kevés dolog van, amit elutasít a rendszer), ott meg még mindig játszik, hogy csinálsz magadnak egy SYSTEM-ként futó command promptot pl. PsExec-kel.

De az is korlátozva van, a SYSTEM user sem tehet meg mindent.

Hát, amikbe én futottam bele:
- Nem törölhet le "védett" fájlokat. (Nem, nem hidden, vagy system, vagy épp futtatott exe, hanem egyszerűen a windows közölte, hogy ezt nem és kész, indoklás nincs.)
- Ha fut a SmartScreen és a saját, frissen forgatott programod nincs aláírva, akkor nem fogod futtatni. Nem rákérdez, hogy "nincs aláírva, biztos, hogy futtatod", hanem megtagadja.
- Nem lőhet ki "védett" processzeket. (Megint csak ne kérdezd, hogy mit jelent az, hogy védett; közölte, hogy nincs jogosultságom és punktum...egyébként egy malware volt az. De se a grafikus taskkezelő nem csinálta, sem a taskkill /im xyz.exe)
- Egyes registry kulcsokat sem engedett átírni.
- Nem engedett feltelepíteni aláíratlan cuccot.
- Egyes könyvtárakba még benézni sem engedett.

Aztán lehet, hogy ezeket külön kell bekapcsolni, hogy a rendszergazda csinálhassa, de én nem találtam ilyen beállításokat, meg a másik, hogy az lenne az alap, hogy a SYSTEM bármit megtehessen...

- Nem törölhet le "védett" fájlokat.

Nem sima Rendszergazda jogkörrel (akár a well-known SID-es Rendszergazda fiók, akár a Rendszergazdák csoport tagjai) próbáltál olyan dolgot törölni, amihez az ACL szerint csak a System-nek van joga?

- Ha fut a SmartScreen és a saját, frissen forgatott programod nincs aláírva, akkor nem fogod futtatni. Nem rákérdez, hogy "nincs aláírva, biztos, hogy futtatod", hanem megtagadja.

És Rendszergazdaként ki tudod kapcsolni a SmartScreen-t.

- Nem lőhet ki "védett" processzeket.

Újfent arra tippelek, hogy System processz és sima Rendszergazdaként próbálod (egyébként pl. antivírus szutykok szoktak előszeretettel system-ként védett processzt indítani, SYSTEM cmd-ből viszi őket a taskkill)

- Egyes registry kulcsokat sem engedett átírni.

ACL-ek?

- Nem engedett feltelepíteni aláíratlan cuccot.

Ez jogos, kell neki egy újraindítás és boot időben engedélyezni kell az aláíratlan cuccokat (csak 64-bites rendszerre, és ezt én se tudom mással magyarázni, minthogy fájt az MS-nek, hogy nem fizettek elegen az aláírásért)

- Egyes könyvtárakba még benézni sem engedett.

Ez megint lehet sima ACL (vannak könyvtárak, amiken egyedül a SYSTEM-nek van hozzáférése, többnyire a Windows mappán belül), de ha nagyon szőrszálat akarunk hasogatni akár az NTFS driver is (csomó fájlrendszer infót speciális fájlokban/könyvtárakban tárol, de azokat még a Linux-os NTFS driverek is elrejtik [pl. ntfs-3g: show_sys_files opciója])

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Nem sima Rendszergazda jogkörrel (akár a well-known SID-es Rendszergazda fiók, akár a Rendszergazdák csoport tagjai) próbáltál olyan dolgot törölni, amihez az ACL szerint csak a System-nek van joga?

Nem.

> És Rendszergazdaként ki tudod kapcsolni a SmartScreen-t.

Ez igaz, de akkor mi értelme van? Mármint nem a SmartScreen-nek, vagy a figyelmeztetésnek, hanem annak, hogy a rendszergazdát fixen letiltja, ha egyszer a rendszergazda kikapcsolhatja? Dobjon fel egy figyelmeztető dialógust, hogy nincs aláírva, akarod-e vagy sem.

> Újfent arra tippelek, hogy System processz és sima Rendszergazdaként próbálod (egyébként pl. antivírus szutykok szoktak előszeretettel system-ként védett processzt indítani, SYSTEM cmd-ből viszi őket a taskkill)

Nem, mint mondtam, a taskkill /im xyz.exe sem működött, rendszeradminisztrátori parancssorból. És ez sajnos nem antivírus volt, hanem sima.

> ACL-ek?

Már nem emlékszem. A (default) kulcsot nem engedte átírni valahol.

> Ez jogos, kell neki egy újraindítás és boot időben engedélyezni kell az aláíratlan cuccokat (csak 64-bites rendszerre, és ezt én se tudom mással magyarázni, minthogy fájt az MS-nek, hogy nem fizettek elegen az aláírásért)

Könnyen lehet.

> Ez megint lehet sima ACL (vannak könyvtárak, amiken egyedül a SYSTEM-nek van hozzáférése, többnyire a Windows mappán belül), de ha nagyon szőrszálat akarunk hasogatni akár az NTFS driver is (csomó fájlrendszer infót speciális fájlokban/könyvtárakban tárol, de azokat még a Linux-os NTFS driverek is elrejtik [pl. ntfs-3g: show_sys_files opciója])

Nem hiszem, mert Linuxból, vagy másik windowsból be tudtam nézni a könyvtárba, tehát nem FS-related volt a blokkolás.

Sztem ez azt igazolja, hogy nem biztos, hogy az a legnagyobb baj, hogy a windows eldönt mindenfélét a user helyett. Ez ui. nem elvi, hanem gyakorlati probléma: sztem elvileg lehet olyan rendszert csinálni, ahol a peer maga dönt és mindig helyesen, azaz mindig úgy, ahogyan az alatta levő layerben dönteni kellene. A windows nem ilyen, de sztem nem ez a legnagyobb problémája, hanem az, hogy a felépítése nem konzekvensen egymásra épülő layereken alapul. Ezt egyébként már a DOS-tól kezdve cipeli magával.

Egy nyomorult VPN kliens is már felmásol 200 MBájt körüli adatot, aminek a nagy része multimédia.

Egy nyomorult VPN kliens? Egy nyomorult touchpad driver b+! .WMV fájlokban animálódik a help a touchpad driverhez, amiben mutatják, hogyan kell kattintani a kibaszott bal egérgombbal (a jobbhoz külön, másik .WMV fájl van természetesen). Így lesz a fél MB-os driverből 200+ MB. "Természetesen" a help, meg ezek a fos animációk nem külön package-ben vannak, hogy eldönthesse a rendszergazda, hogy kéri-e ezeket szarságokat...

Hát ennyi háttértárra csak a windóznak van szüksége egy frissítéshez, többieknél maximum installnál kell ennyi...csak itt jön képbe, hogy windows alatt ezek a fél éves "frissítések" valójában hidden reinstallok.
De a probléma itt elsősorban inkább azon van, hogy kérdés nélkül elveszi a tárat; hogy a júzer helyett dönt. Már megint.

"Hát ennyi háttértárra csak a windóznak van szüksége egy frissítéshez, többieknél maximum installnál kell ennyi..."

Hát, azért én már szorultam meg hellyel dist-upgrade során Linux esetén is és egy ilyen Windows update valóban inkább egy dist-upgrade.

"De a probléma itt elsősorban inkább azon van, hogy kérdés nélkül elveszi a tárat; hogy a júzer helyett dönt. Már megint."

40-50 GB jelenleg egy Windows 10, nem? És ott marad a régi is, ami szintén 40-50 GB, ha visszaállnál az előző állapotra, már lazán 100 GB helyet foglal és még nincs egy programod se telepítve. Ha hibernálnál, akkor az is egy memória méretű fájl, tolhatná annak a helyére is a letöltött frissítéseket, amit eldobna, ha mégis hibernálni kellene, de amúgy csak kisebb SSD esetén szopás a helyszűke. Nekem 128 GB SSD van, a Windows 10 el se férne rajta, az az 1 TB méretű HDD-n van.

--
https://iotguru.live

"40-50 GB jelenleg egy Windows 10, nem? És ott marad a régi is, ami szintén 40-50 GB, ha visszaállnál az előző állapotra, már lazán 100 GB helyet foglal és még nincs egy programod se telepítve."

Ezt honnan veszi kend? Belakott C meghajtóm (tehát office, programokkal, anyámtyúkjával) foglal 40 GB-ot. Ebből 21 GB a Windows 10.

"Nekem 128 GB SSD van, a Windows 10 el se férne rajta"

Nettó faszság. Legalább ne terjesztenéd a fals információkat...
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

"Ezt honnan veszi kend?"

Van a gépemen Windows 10 Home, megnéztem mekkora. Egyébként egy 2015-ös gép, azóta hízik rajta a Windows, a Clean-up ekkora rendet tud tenni, meg időnként letörli az előző verziókat.

"Belakott C meghajtóm (tehát office, programokkal, anyámtyúkjával) foglal 40 GB-ot. Ebből 21 GB a Windows 10."

Örülök neki. Én ilyen karcsúval csak telepítés után találkoztam.

"Nettó faszság. Legalább ne terjesztenéd a fals információkat..."

Ahja, fals, most, hogy letöröltem hétvégén 45 GB telepítési maradékot, most már van hely a 125 GB partícióján, pont hétvégén nyünyögött:
/dev/sda3 125G 61G 65G 49% /mnt/windows

Nem használom semmire, akkor kapom elő, ha szkennelni kell, mert a szkenner nem megy Linux alatt. Biztos, hogy lehetne még rajta karcsúsítani, de én átlagfelhasználóként használom, illetve nem használom, amit önerőből tud, azt tudja.

--
https://iotguru.live

Úgy, hogy nem telepítjük újra minden héten nulláról. Én kb. a Win10 megjelenésekor raktam fel, azóta nem volt reinstall, és csak hízik.
A C:-m most kb. 90GB, Office, Visio, Project, Gimp, néhány plusz apróság van rajta, semmi komoly. Ha összeszámolnám (és mondjuk újratelepíteném), az egész kb 40-50GB-ot tenne ki. De az évek során annyi szemetet összeszedtek a feltelepített szoftverek (és nem takarítanak maguk után), hogy felhízott az egész 90GB-ra.
A felgyűlt szemetet meg nem takarítja le semmi, mert a Lemezkarbantartó is csak egy részét szedi le, a 3rd party appok szemetei mind maradnak.

Lemaradt: ebben nincs adat, a C:-n nem tartok semmi ilyesmit.

Sikerült levadásznom, hogy kb. mikor volt az eredeti install, ezek szerint 2015.02.24 (tehát 4 éves) az eredeti install date, még 8.1-el, ami utána folyamatosan upgradelve lett:
ProductName ReleaseID CurrentBuild Install Date
----------- --------- ------------ ------------
Windows 8.1 Pro 9600 2015.02.24. 11:01:30
Windows 10 Pro 10240 2015.08.10. 17:43:28
Windows 10 Pro 1511 10586 2015.11.16. 20:28:58
Windows 10 Pro 1511 10586 2016.01.11. 10:26:43
Windows 10 Pro 1607 14393 2016.08.22. 13:29:44
Windows 10 Pro 1703 15063 2017.04.12. 13:07:22
Windows 10 Pro 1709 16299 2017.10.18. 18:12:52
Windows 10 Pro 1709 16299 2017.12.11. 22:46:06
Windows 10 Pro 1803 17134 2018.05.20. 14:50:22
A 1809 valamiért nincs a listában, az decemberben ment fel.

szerk.:
A "belakott" rendszer nálam ezt jelenti, akkor éri el ezt a titulust, ha már évekig "együtt éltünk". Ha frissen telepítek és felpakolok minden szükségest, az nálam még nem a "belakott" kategória, csak a "feltelepített, munkára előkészített".

A fenti a céges noti, az otthoni még ennél is régebbi telepítés, azon az eredeti OS még Win7 (volt).

> Hát, azért én már szorultam meg hellyel dist-upgrade során Linux esetén is és egy ilyen Windows update valóban inkább egy dist-upgrade.

Nyilván egy Linux is tele bírja szórni verzióugráskor a gépet, főleg ha sok cucc van telepítve, mert akkor azokat is mind frissíti, de Linuxa és környezete válogatja. Ráadásul okos függőségkezeléssel meg lehet oldani a frissítést kevés tárhely mellett is, mert nem muszáj egyszerre az összes csomagnak a cache-ben lennie.

> 40-50 GB jelenleg egy Windows 10, nem? És ott marad a régi is, ami szintén 40-50 GB, ha
> visszaállnál az előző állapotra,már lazán 100 GB helyet foglal és még nincs egy programod
> se telepítve. Ha hibernálnál, akkor az is egy memória méretű fájl, tolhatná annak a helyére
> is a letöltött frissítéseket, amit eldobna, ha mégis hibernálni kellene, de amúgy csak kisebb
> SSD esetén szopás a helyszűke. Nekem 128 GB SSD van, a Windows 10 el se férne rajta, az az
> 1 TB méretű HDD-n van.

Jézusom... Azt tudtam, hogy bloat a windóz, de, hogy ennyire...?

Te valamit nagyon elkúrtál (bocs a szóért, de ide ez passzol)! Nekem is 128 GB-os ssd feszül a gépben, win10 van rajta, plusz minden alkalmazásom és még vbox is három lemezképpel. Így csak 40 GB szabad rajta. Hogy neked mitől van tele? Kevesebb állatos pornót és kaki-pisi szekszet kéne fogyasztani vagy nem tudom.

Számolgattam itthon én is, 240-es SSD-n (223 GB használható), igy alakulnak a helyek:
Szabad: 50 GB
Windows mappa: 20 GB
Program files (+x64): 35 GB
Dokumentumok: 30 GB: ebből 5 GB letöltés és 10 GB asztalon
A fennmaradó helyen egyéb mappák vannak, 2 GB lapozófájl, 6 GB hiberfil , driverek, meg szemét. Szemét nélkül (letöltések, asztali vackok) simán beleférne a 128-ba is. Az előző céges gépben csak 128-as SSD volt, és elfértem rajta (kb 30 giga install médiával együtt).

Ps: 2018 januári install
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Süt belőled az ész, meg az ostoba rosszindulat. A "vegyél még három gépet" egyértelmű szarkazmus volt, rajtad kívül mindenki értette; ami pedig a tárhelyet illeti, csak ötször írtam le eddig, hogy nem is a 7 GB a fő probléma, hanem az, hogy már megint a rendszer döntött a felhasználó helyett, de látom olvasni sem tudsz, csak cédula nélkül beszólogatni, ha valaki olyat mond, ami fáj a valagadnak. Reparon a patikában.

Szerintem meg a te hülyeséged az, ami sugároz és veszélyes. (látod én is le tudlak marházni!) Az ominózus hozzászólásod után akadt még pár értetlen hülye, aki nem volt vevő a "szarkazmusodra". Egyébként százszor leírták, hogy van ilyen, rendszerkomponens és nem 0 bites. Ergo a méretének megfelelő tárhelyet lefoglal! De meglepő! Nem fáj a valagamnak, csak az az erőltett kákán/kakán is csomót keresés amit folytatsz, ingerelt. És? Csak te nyomhatod a full kretént és akkor az jófejség? Más nem? Bah!

Nem azt mondtam, hogy vevők voltak rá, hanem azt, hogy értették. Nagy különbség. Ne zavarjon, hogy a "nem 0 bites rendszerkomponensekről" egy fentebbi szálban kivesésztük, hogy redundánsan szétszórt kód és adatszemét és még az is kiderült, hogy az ms a debug infókat is ad-hoc módon strippeli. (Tényleg nem tudsz olvasni? Vagy csak nem akarsz?) Ha ez szerinted csomókeresés a kákán, meg full kreténbe nyomás, akkor csak a kezemet tudom széttárni. Emlékeztetnélek rá, hogy te szóltál énhozzám és mindjárt személyeskedéssel nyitottál ld. "hiszti a semmin". No comment.

Ja értem. Szóval érvek itt sincsenek, csak a butthurt fölényeskedő rejtélyeskedés, hogy rámhagyjátok, de ti tudjátok az nagy igazságot, csak épp el nem mondjátok. Tisztára mint a dedóban, "bibibí, éntudomám, denemmondomeeeeel..." Szánalom. Lehet cáfolni a két poszt számadatait. Addig viszont áll az állítás, hogy a redundánsan tárolt kód és adatszemét miatt bloated a windows 10.


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ReserveManager]
"ShippedWithReserves"=dword:00000000

Hmm... Komolynak méretnek tűnik. Bár, ah mondjuk lejön egy 1GB csomag és ez mondjuk elterül egy 4-5GB területen, alig marad belőle.
Rusnyán meghíztak a kedves szoftvereink. :-(

egyik félreeső gépemen eddig úgy úsztam meg a win10 frissítéseket és az intall időket hogy nem volt neki elég hely a C-n, és így harmónáiban voltunk

Van aki szerint ez semmi.

Toluk kerdeznem, hogy mikor virtualisan futtatja az ember a win-t, mert muszaj szarakodnia vele egyes projektek miatt, akkor miert jo nekem, hogy az eddig sem kicsi image-em meg 7 GB-al no, mikor semmi szuksegem ra? Most is elvesz vagy 30Gb-ot a 120GB-os SSD-mbol. Es nem nem akarok amiatt uj SSD-t venni, mert a virtwin-nek az osszes tarhely sem eleg a vilagon.

Tudom, ha nem tetszik, akkor tuti fillerbaszo linuxfanboy vagyok. Ez mindent megmagyarazna. :D

120 gigás ssd-n virtualizálsz mindenféle wines projekteknek w10-et. Gondolom munka, nem hobbi. Minden elismerésem, de tényleg.

"mert a virtwin-nek az osszes tarhely sem eleg a vilagon."

30 helyett most 37-et fog foglalni, legalábbis, ha nem tiltod le registry-ben. Ez tényleg a világ összes tárhelye. (nekem valahol 25 giga körül van a teszt w10 vm-em)

Biztos az én logikámmal van baj, de ha ilyen problémáim volnának én biztos rászánnék kemény 5-10 ezer forintot, hogy megduplázzam a tárhelyemet.

És tényleg azon pörögnek sokan 2019-ben, hogy kb 500 ft-nyi ssd tárhellyel többet kér magának egy oprendszer a stabilabb frissitésért, persze ezt is kikapcsolhatóan.

"Hát ennyi háttértárra csak a windóznak van szüksége egy frissítéshez" - (7 GB?)

Ha csak ennyivel beéri és ezen még frissíteni is tud.., - akkor semmi gond, - még élenken él bennem a 32 GB-s tablett-PC, ahol a Win10-frissítés azért dobta el az agyát egymás utánban, mert 16 GB szabad helyet kért az eljáráshoz, és nekem mindent lenyakva csak 15,2 GB-t sikerül felszabadítani. (A vége full új install lett.)

Nem volt 64K-d.
Ez első 1K-kb ~40% tudtad használni, a többi kellett a rendszernek.
$D000-tól szintén vannak regiszterek, amiket nem érdemes kapcsolgatni.
Aztán kell videoram is. Minimum 1K. Aztán kell karaktertábla is.... Ha grafikus megjelenítést akartál, akkor ennél is több kellett.
Régi ROM resetnél beszemetel valahol az $FE00 terület környékén, tehát oda sem tett semmit az ember.

De volt.

Nem az volt kérdés, hogy a rendszer miatt (amit egyébként 100%-ig ki lehet iktatni, mert mind a BASIC, mind a KERNAL ROM lekapcsolható) mennyit tudsz használni, hanem az, hogy mennyi RAM van benne, ami pedig pontosan 64k. (De mint mondtam, a rendszer lekapcsolható, lehet mind a 64k-t használni.)
256 byte zeropage, 256 verem, 512 további az első 1k-ban, aztán 1k a karakteres képernyőnek, 38k a BASIC-nak, utána a BASIC ROM 8k-ja helyére RAM-ot lehetett lapozni, utána jött az upper RAM 4k-ja, majd az általad említett $D000-tól kezdődő terület, ahol 4k I/O, 4k RAM, vagy 4k char ROM volt, tehát olyan nincs is, hogy a $D000-tól kezdődő regisztereket "nem érdemes kapcsolgatni", de azért "kell karaktertábla is", mert ugyanazon a területen vannak és egyszerre nem tudod használni őket; de éppen ezért lehetett lapozni ezeket a területeket: ha épp nem kellett a chipek I/O területe, vagy a char ROM, akkor átváltottál a RAM-ra, ha meg kellett, akkor vissza, de ettől még nyugodtan lehetett használni a $D000-tól becímezhető RAM-ot is. És végül a KERNAL ROM 8k-ja helyére szintén lehetett RAM-ot lapozni. Ezeket ha összeadod, akkor az pontosan 64k. Mínusz a CPU portja miatti két byte $00-$01-nél és a három vektor $FFFA-tól.

De ha nagyon gányer akarok lenni akkor még hozzáteszem, hogy viszont plusz 512 byte, illetve pontosabban 1024 nibble, mert ha $D000-ra belapoztam az I/O területet, akkor a Color RAM-ot is felhasználhattam 4-bites RAM-nak és ezt nyugodtan megtehettem, ha pl. hires módban voltam, mert akkor a Color RAM inaktív, de akár akkor is, ha multicolor módban semelyik pixelt nem állítottam 3-ra.

A C64-ben a ROM helyére lapozott RAM-ba nem csak adat, de másik kód is kerülhet, akár olyan is, ami a hardware részeit kezeli, csak épp hatékonyabban, mint a ROM-ba égetett eredeti. Az - egyébként teljesen out-of-context - analógiádat követve, igen: a PC-re sem kell w10, mert PC-re is lehet rakni értelmesebb rendszert, ami nem pocsékolja ennyire az erőforrásokat. (Direkt nem mondok semmilyen példát, mert a w10-nél kb. bármi más értelmesebb. Még egy másik windows is.) Amúgy ne is zavarjon, hogy két teljesen eltérő, egymáshoz semmi közzel nem bíró dolgot sikerült párhuzamba állítanod. És az se zavarjon, hogy a C64 fizikai memóriamennyisége volt a kérdés, nem az, hogy hogyan használták.

Busszal.

Félretéve a viccet, nem értem, hogy miért kéne rasztermegszakításokkal baszakodni a lapozáshoz.

Írtam egy példát (nem a legszebb megoldásokkal, pl. a lapozót nyugodtan lehetett volna inline is, de most már mindegy):

                *=        $0801
                ; BASIC "0 SYS2061"
                .byte        $0b, $08, $00, $00, $9e, $32, $30, $36, $31, $00, $00, $00

                ; ($d418).b := $0f
                lda        #$0f
                sta        $d418

                ; ($d405).b := $00
                lda        #$00
                sta        $d405

                ; ($d406).b := $f0
                lda        #$f0
                sta        $d406

                ; ($d404).b := $21
                lda        #$21
                sta        $d404

                ; p.i = 1
                sei

                ; useram()
                jsr        useram

                ; ($0400).l := $00000000
                lda        #$00
                sta        $0400
                sta        $0401
                sta        $0402
                sta        $0403

                ; (RAM:$d400).l := $00000000
                sta        $d400
                sta        $d401
                sta        $d402
                sta        $d403

-               ; repeat (IO:$d400).l := (RAM:$d400).l++ until false
                ldx        $d400
                jsr        useio
                stx        $d400
                stx        $0400
                jsr        useram
                inc        $d400
                bne        -
                ldx        $d401
                jsr        useio
                stx        $d401
                stx        $0401
                jsr        useram
                inc        $d401
                bne        -
                ldx        $d402
                jsr        useio
                stx        $d402
                stx        $0402
                jsr        useram
                inc        $d402
                bne        -
                ldx        $d403
                jsr        useio
                stx        $d403
                stx        $0403
                jsr        useram
                inc        $d403
                bne        -
                beq        -

useram          ; ($01).b := $30
                lda        #$30
                sta        $01
                rts

useio           ; ($01).b := $37
                lda        #$37
                sta        $01
                rts

tass64-gyel lehet assemblálni (eredeti forrás itt), ha nincs 64tass, vagy nem akarsz szarakodni vele, akkor a bináris itt: http://oscomp.hu/depot/sidfreq_same_address.prg.

Amint látod, egy mezei ciklus van itt, ami a $d400-$d403 címeket (SID voice 1 frequency és pulse width) inkrementálja, mégpedig úgy, hogy nem használ rá más címet, hanem ugyanazt a címet írja és olvassa, az I/O és a RAM terület között váltogatva. Az aktuális állást $0400-től $0403-ig ki is jelzi. A SID rendületlenül zajong, a számláló rendületlenül pörög, a CPU pedig rendületlenül váltogat a két terület között. Ugyanezt akár bitmap módban is el lehetne játszani, csak épp így egyszerűbb volt gyorsan egy példát összedobni. Hol van itt szükség a rasztermegszakításokkal való baszakodásra?

Ja, hogy úgy értetted, hogy ha I/O related kódot akarok oda rakni, akkor kell rasztermegszakításból kapcsolgatni. Értem. Ez nem jutott eszembe, mert eszembe se jutott, hogy I/O műveleteket végző kódot tegyek az I/O címtér alá. De mindenesetre, ha csak adatot, vagy non-I/O related kódot akarsz odarakni, ahhoz nem kell rasztermegszakításokkal bajlódni.

Feltettem a frissítést, szépen fel is ment. Jól is megy.

Aztán a Gépház/Rendszer/Tárterület/Ideiglenes fájlok szépen mutatta hogy az előző Windows telepítés 17,4G-t foglal. Mondtam hogy szedje le.

Azóta több helyem van mint a frissítés előtt! :-)

Ezt speciel a Linux már rég tudja.

-m reserved-blocks-percentage

Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.

Yay, a Kendi Kráss Szóda Szaga Vid Frencc, meg a Kászül Szídzs Igztrém Kettő A Huszonharmadikon mellé még ez is betársul. \o/
...
Csak sajna nem júzerenként foglalja el ezt a hétmérföldes gigákokat, pedig úgy lenne duplajó. ;(