SSD híján HDD gyorsítása ramdiskkel

Microsoft Windows

Egy klasszikus HDD-vel felszerelt munkagépen dolgozom rengeteg apró fájlból álló projekten, az elérési sebesség érezhetően lassítja a munkát.

Arra gondoltam, hogy egy olyan ramdisk megodlás, ami valahogy garantálja az adatok tartósságát segíthetne. Próbáltam keresni ilyet Windows 10-re, olyat találtam, ami induláskor és leálláskor szinkronizál, viszont ez nem tűnik biztonságosnak, olyan kellene, ami folyamatosan teszi. (raid mirror ramdiskkel? :))

Azt hiszem megoldható a probléma manuálisan úgy, hogy induláskor feltöltöm a ramdisket, majd ráindítok egy folyamatosan futó backup alkalmazást, de gondoltam megkérdezlek titeket, hátha tudtok valami all in one megoldásról, esetleg van jobb tippetek a probléma orvoslására.

( _ventura_ v | 2018. 07. 05., cs – 09:25 )

Nem ismerem a projektet, nem ismerem a büdzsét de mikor egy 64G-s SSD bruttó 8-9e nem kezdenék el ilyen megoldásokkal szórakozni. Főleg ha a projekt fájlok elvesztése jóval többe kerülne.

Mert ugye a RAMDISK az minden csak nem biztonságos.

Fedora 27, Thinkpad x220

+1, óvatosan de csak meg kell pedzeni, keress egy max nettó 9990 Ft-s példányt és nyújtsd be, hogy ezzel sokat lehet gyorsítani a gépen és kellllll a munkához.

PS: inkább legyen ez a b.) terv, a.) tervnek nyújtsd be pl ennek a nettó árát (kb 12300):
https://www.pcx.hu/kingston-240gb-sa400s37-240g-ssd-meghajto-864826
ezen komoly trükközés nélkül kényelmesen elférnél és biztosan könnyebb lenne egy az egyben átmásolni a rendszert egy ilyenre.

úgyis most bővítettek a kérésemre, nem lehetek pofátlan újoncként

Újoncként is a napi fizetésed több, mint amiről itt beszélünk! Amúgy ha egy cég nem képes bármikor elkölteni egy termelő ember alapvető munkaeszközére az egy havi bérköltsége 10%-át, akkor ott igen komoly gondok vannak. (gyk: abból a 10%-nyi pénzből egy vadiúj sarkiboltos pc-t lehet venni).

Vigyázni az olcsó SSD-kkel, teszteltem párat és 70 MB/s volt az írás maximum sebessége és 120 MB az olvasásé 4-500 helyett, illetve 4K I/O 80k helyett ami kb annyi mint egy merevlemezé - és ez olyan 25 ezer FT-os SSD volt. Részemről azt javaslom hogy egyetértek, kell SSD, de minimum 60 de inkább 80 ezer IO / sec (ez a paraméter kritikus különben lassú szar lesz) és SATA3-as 600 / 600 MB rás / olvasással, wear leveling-el.

Kíváncsiságból futtattam alapértelmezett módon (bonnie++ -d /hol), azaz csak a tesztfájlok útvonalát megadva, amikor a rendszer ram dupláját használja.
Hát ennek az eredménye legfeljebb csak azt mutatja, hogy nem alkalmas erősebb rendszereken mérésre, mert csak +++ -ot tesz némelyik eredmény helyére. Viszont közben némely esetben cpu limites, mert nem használja ki a többszálúságot.
Amúgy sem a háttértárat teszteli, hanem a rajta lévő fájlrendszert. Szó nincs benne iops-ról. Ha nagyon vacak értéket adott nálad, akkor lehet, hogy rosszul lett létrehozva a fájlrendszer és több blokkot ír amiatt egyszerre.

Engem pont az adott fájl rendszer érdekel az adott hardveren az adott cpu limittel. A programok sem többszálúak ha nincs leprogramozva. Ugyanazon hardveren tesztelve különböző SSD-ket nagy a különbség a sekvenciális és random elérések között (is).

Te most egyetlen SSD-re lefuttattad és ebből komoly következtetéseket vontál le? :)

Olcsó SSD-d van? Ez a gond? :) Ha igen akkor valszeg még nem próbáltál normál sebességűt ami nem HDD közeli eredményt hoz. Gondolom ezért megy itt a vita.

Á, köszi én elégedett vagyok az olcsó ssd-immel. Jól használhatóak még a régebbiek is. Még a fapados 60-as Corsair Nova2 is megfelelően megy. De a 256-os samu 470 oem változat is kitart már 6 éve. Az egyik géppel jött 180-as intel 520 és a fiatalabb 250-es msata samsung 850 evo is hibátlan.

Amúgy a samuk elég elterjedtek és jó teljesítményűek. Esetleg, ha a firmware bugos evo 840-be botlottál, azon a fw update talán segít valamennyit. Mert a lassú ssd-ről nekem a régebbi kínai, noname ssd-k jutnak eszembe, például kingdian vagy hasonlók. De állítólag már azokból is sokkal jobb teljesítményűek vannak, mint pár éve.

Csak azért kérdeztünk rá, hogy pontosan mivel, hogyan volt ilyen rossz tapasztalatod, hogy lássuk valóban van-e problémás ssd a piacon, amit érdemes kerülni, vagy csupán rossz metodikával, rosszul értelmezett méréssel van dolgunk. Minden esetre, hogy az ssd lassúságával és az io gyárihoz képest töredékével kezdted, aztán meg már fájlrendszerről meg procilimitről beszélsz, miután mondtam hogy ez történik, így látom már, hogy felesleges folytatnom ezt a szálat, mivel nincs hozzáadott érték a kapott válaszokban.

Nem értem milyen metodikára gondolsz, valami nagyon zavarhat :) Teszteltem diszkeket, nem fogom előásni az infót mert nem ér meg annyit. A teszt mindenképpen szintetikus, ezt tudjuk. Viszont sok mindent elmond ha a diszkeket egymással hasonlítod össze. Nincs itt semmiféle félreértelmezés vagy rosszul összedugott gép vagy nem is tudom még mire gondoltatok :)

Teszttől fóggetlenül, Windows-t és Linux-ot telepítve az ilyen olcsó cuccokra amivel tapasztalatom volt, nagyon lassú rendszert eredményezett. Kb mint egy SATA2 HDD, hiába új és gyors a hardver többi része. A drágább cuccnál meg penge gyors volt a boot és a reboot utáni betöltés és használat is.

Nem győzködök senkit. Elmondtam hogy érdemes odafigyelni az olcsó cuccokra mert nem igazán jók ár érték arányban a tapasztalatom szerint. Ha más máshogy tapasztalja, akkor vegyétek :)

Nem gyozkodest kertunk, csak infokat arrol hogy merted vagy milyen eszkozokon.

Engem azert erdekelt volna, mert hacsak nem a silany mar joforman nem is kaphato 32-64G ssh korszakbeli olcso ssd-rol velekedsz lassuan akkor nagyon nem ez volt a tapasztalatom (a manapsag kaphato) olcso ssdkel, ahogy hdd-nel se jott ki nalam 4000 random iops kozel se.
De mindegy, latom egyszerubb ha hagyjuk a temat.

Milyen Samu volt ez pontosan? Nem kötekedésből kérdezem, hanem tényleg érdekel engem is.

A 32-120 GB-os SSD-k mindig is lassabbak voltak, igaz a 120 gigás már csak kicsivel, általában írásban szoktak egy 20-30%-kal gyengébbek lenni, de ezt csak benchmarkok alatt lehet kimutatni, meg nagyobb fájlok másolásánál, átlag felhasználásnál nem érzed őket lassabbnak (boot, programok betöltési ideje).

Linux alatt az a legnagyobb baj, hogy nincs normális meghajtóbenchmark. A dd még cache-elés nélkül is össze-vissza mér, a bonnie++ teljesen hülyeségeket mér és az iozone sem ér fabatkát sem. Egy reménység van, a windowsos Crystal Disk Mark-nak az MIT licences open source MS DskSpd az alapja, ami viszont van linuxra, de a felparaméterezése annak sem jól dokumentált, nekem nem sikerült vele olyan konzisztens eredményeket mérni, mint a windowsos változattal. Pedig a CDM-et sem tartom a legjobb benchmarknak, az ATTO és a HD Tune szerintem jobb Windows alatt, életszerűbb értékeket mérnek. Mégis a CDM-et használják mindenhol, benchmarklistákon, tesztoldalakon, SSD-s fórumtopikokban.

Nekem van pár SSD-m, van olcsóbb, drágább, 60 GB-ostól a 1050 GB-osig, igaz egyik sem kínai noname, vegyesen SATA2, SATA3, MLC, 3D TLC, egyiket sem találtam lassúnak, a legolcsóbbak (régi Samsung PM800, új Adata SU650) is mennek mint a villám, akkor is, ha csak USB3-on keresztül vannak hajtva, egyelőre olcsó átalakítóval, ami csak BOT USB módot tud, UASP-t nem. A stock 64 bites Win10 Prof ez utóbbiakról is 5-6 mp-en belül bootol úgy, hogy a fast boot ki van kapcsolva. Még a SATA2-est sem érezni lassabbnak, mikor OS és progik futnak róla, csak nagy fájlok másolásánál jön ki, hogy nem ~500 MB/sec-el másol rá másik SSD-ről/cache-ből, hanem csak ilyen 280 MB/sec körülivel.

No keyboard detected... Press F1 to run the SETUP

Ez berögzött téveszme. Miért ne lehetne mérni? Mérje le hogy milyen gyors a random és a seq írás és olvasás cache nélkül ugyanazon hardver és szoftver környezetben és kész. Bőven jó viszonyításnak.

Persze hogy egy mérés csak pár szempontból vizsgál a végtelen halmazban. És?

Mérni lehet, de nem valós eredményeket kapunk. Ennyi. Nem berögzöttség, nincs még rendes benchmark Linuxra. Aki mégis az elérhető legjobbat keresi Linux alatt, annak csak a dd-t tudom ajánlani cache-elés nélkül meg ezt az MS-féle SptDsk-et. A többi végképp nem ér semmit. Egy dolgot nem próbáltam még ki, ami várat magára, a Phornix Test Suite-nak van néhány vonatkozó benchmarkja, de az sem tűnik valami komolynak. Ebben zárkózhatna kicsit a linuxos kínálat a windowsoshoz.

No keyboard detected... Press F1 to run the SETUP

Nem valós eredményen azt értem, hogy közelébe nincs annak az értéknek, amit fájlokkal való műveletek alapján mérnénk, meg a windows alatt mért értékektől is gyanúsan elmarad, pedig a Linux lemez-I/O-teljesítménye nagyobb, mint a Windowsé. Sőt, még a gyártói értékeknek sincs közelében sem. A bonnie meg aztán tényleg olyan eredményeket mér, aminek köze nincs a valósághoz, az access time-okat SSD-n meg sokszor nem is tudja mérni (olyan alacsony neki), inkább kicsillagozza. Siralmasak. De ha akarod, nyithatunk itt a HUP-on egy általános linuxos SSD-s topikot, megegyezünk a benchmarkparaméterekben, mérési módszerekben, és mindenki mér syncelt dd-vel, bonnie++-szal, MS SpdDsk-kel, esetleg Windows alatt Crystal Disk Mark, AS SSD Benchmark, ATTO Benchmarkkal, mindegyikből a legújabb verzió. A benchmarkokat általában min. kétszer kell lemérni, egyszer 0-fill eredményekkel, mert néhány SSD vezérlője tömörít és csak 0-fillel lehet a gyári sebességértékeket megkapni. Esetleg lehetne még csatolni smartctl -a kimenetet is. Hasznos lenne SSD-körképnek is, melyik mit tud, mennyit megy, hány nap után mennyi üzemórán és írásmennyiségen áll.

No keyboard detected... Press F1 to run the SETUP

> Mérni lehet, de nem valós eredményeket kapunk.

Huha. Fogok egy 6GiB-os fajlt es atmasolom A-bol B konyvtarba. Es megnezem mennyi ideig tartott.
Nagy tudomany na.


5868957023 byte (5.5GiB)

real 0m20,278s
user 0m0,021s
sys 0m7,504s

Nalad egy ilyen mutatvany mennyi? Azonos particion, tehat merevlemezen belul.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem biztos, hogy van partíció. Másrészt ez semmiről sem mond semmit. Ha van 16 GiB RAM-od, nagyon gyors lesz, mert disk cache-be megy az adat, aztán majd kiíródik valamikor, legkésőbb egy sync, umount, vagy a gép leállításának hatására. Mondjuk olvasási tesztnek azért még jó lehet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Nem biztos, hogy van partíció.

Lehet hogy felreerthetoen fogalmaztam. Masolas ket konyvtar kozott.

> nagyon gyors lesz, mert disk cache-be megy az adat, aztán majd kiíródik valamikor, legkésőbb egy sync, umount,

Akar meg igazad is lehet:)

Egyebkent ilyen sync-kel:
time -p sh -c 'cp b*v ..; sync'
real 12,38
user 0,01
sys 4,46

Ha tobbszor lefuttatom, akkor olyan 12+4 korul van. De legeloszor 20+5 volt.

Viszont pendriveokat rendszeresen szoktam nagy fajlok ramasolasaval tesztelni.
A legtobb irtozatosan belassul valamennyi adat masolasa utan (talan 1GB).
A normalisabbak birjak a tempot.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A legtobb irtozatosan belassul valamennyi adat masolasa utan

Épp azért, amit írtam. Az elején disk cache-be - tehát RAM-ba - megy az adat. Amikor a kernel nem foglal már több cache-t, akkor már csak olyan gyorsan tudja azt írni, amilyen gyorsan a másik végén ürül. Tehát valójában épp ez a lassú rész a valódi sebesség.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

tudom nem pendrive, hanem sd kartya.
Ket darab 8GB-os sd kartya, egyik kingston, masik adata. Mindketto 8GB-os.
Mindketto azt irja magarol, hogy class 4-es.

dd-vel toltam ra backupot.
Az egyiknel (7,8 GB, 7,3 GiB) másolva, 752 s, 10,4 MB/s
A masiknal (7,8 GB, 7,3 GiB) másolva, 1424,34 s, 5,5 MB/s

Innentol hozhat barki barmilyen benchmarkot, nem tud meggyozni, hogy az 1424s-est vegyem.

A tippet koszi.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Gondolod, ha ilyen egyszerű lenne, akkor mindenki benchmarkokkal erőlködne? Cache-elés, fájlrendszer mind beleszól, meg ezzel a fájlmásolósdival nem tudsz tisztán olvasást, tisztán írást mérni, 4K-s teljesítményt, kötegelt feldolgozást (queue depth), késleltetést (hozzáférési időt). Hidd el, nem mi bonyolítjuk, hanem valójából ilyen bonyolult.

Egyébként ez a mappaátmásolás is egy teszt, lehet alkalmazni egy tesztként a sok közül, de el kell fogadni a korlátait. Eleve a reprodukálhatósága is nehéz, mert amit a te mappáddal mértél a te SSD-den, azt az időeredményt nem tudod összevetni Gipsz Jakab meghajtóján átmásolt mappával, még akkor sem, ha a mappa mérete is azonos, mert nem fogod tudni mi volt az ő mappájában (mekkora fájlok, hány darab, tömöríthetők-e), milyen fájlrendszert használt, cache ki volt-e kapcsolva, stb..

No keyboard detected... Press F1 to run the SETUP

Na jó, csak egy gyenge vicc volt. Próbáltam a fio-t is, egy kalap fekáliát nem ér, valahogy nem nevettem. De ha írod milyen paraméterezéssel próbáljam, kipróbálom újra.

Nagy linux meg opensource fan vagyok, meg elég MS/Windows-ellenes, de azt tisztán kell látni, hogy vannak területek, aminél a Linux le van még maradva, és ez a disk benchmarkolás még egy ilyen terület. Pedig szó sincs róla, hogy Linux alá nem lehetne írni ilyeneket, csak valahogy a fejlesztők nem motiváltak, hogy ilyesmit fejlesszenek. Pedig igény lenne rá.

No keyboard detected... Press F1 to run the SETUP

Nem tudom mi a problémád velem, mostanában egyre sűrűbben szólogatsz be és személyeskedsz olyan témákban, amikhez láthatóan semmi szakmait nem tudsz a saját részedről hozzátenni, de legalább trollnak sem vagy poén. Ezzel a stílussal menj el az Indexre vagy a gyakorikerdesek.hu-ra.

No keyboard detected... Press F1 to run the SETUP

mert nulla tudasod van, de kozben osztod a nem letezo eszed.

1, miert irsz litaniakat ha NULLA a mondanivalod?
2, miert szolsz hozza olyan temakhoz amikhez porszemnyi kozod sincs?

mar a masik topicban es itt is jol bemutattad, hogy nem vagy szakember, de azert beszelsz hulyesegeket. ha a fiot nem tudod felprogramozni, akkor szerinted a hiba benned van, vagy a szoftverben?

De az baj, hogy te meg semmi normálisat nem tudsz írni, és úgy személyeskedsz. A beszólogatás helyett nyugodtan kezdhetted volna a fio felparaméterezését írni. De olyan konkrét paraméterezésekre gondoltam, ami kikapcsolt cache-re sem csak ilyen 150 MB/sec vagy 6800 MB/sec (vagy ezzel ekvivalens IOPS) értékeket mér egy 400-550 MB/sec szekvenciális/random átvitelt tudó, SATA3 porton üzemelő SATA3 SSD-nél, meg a mért latency-re sem *-okat kapok értékelhető eredmény helyett, és alkalmas arra, hogy több SSD eredményét össze tudjuk hasonlítani. De nem csak fio-ra, bármilyen használható megoldásra nyitott vagyok, ráadásul a téma is komolyan érdekel. Ha olyan nagy szaktekintély vagy, ne kímélj, hadd tanuljunk a mestertől. Azt értem, hogy felsőbbrendű vagy, mert a nagy random Z-t tisztelhetjük személyedben, csak az alapját nem értem az önértékelésedned annak fényében, amiket eddig irkáltál.

No keyboard detected... Press F1 to run the SETUP

Na, ez így már más, kezdünk haladni valamerre személyeskedés helyett.

Lefuttattam, de elég nehezen értelmezhető eredményeket kaptam. Az SSD szekvenciálisban tud 1,5× ennyit (gyártói adat, Windows 7-10-en mért CDM és ATTO eredemények), a latency-re meg túl jó értékeket mért. A random eredményeket nem is tudom értelmezni.

Cserébe viszont magával rántott 300 MB-nyi Phyton-os függőséget úgy, hogy az alap Python már fent volt.

No keyboard detected... Press F1 to run the SETUP

Igaz, valóban, az első 4 sorban ott van, hogy 4096 bájtos méret, csak azt nem olvastam figyelmesen, utána meg a seq-read felirat megtévesztett. 4K-s értékekre ezek valóban reális mérések, kb. ennyit tud a meghajtó hivatalosan is. Viszont a latency még a percentile-okat figyelembe véve is irreálisan túl jó.

Gondolom valami másik .fio-profilfájlt letöltve és betöltve tudnék értelmesen latencyt meg szekvenciális mérést is kapni, de ez is baromi bonyás és nehézkes, ennyiszer ennyi profillal futtatni, meg kiír egy csomó percentile szemetet egy normális átlag helyett. Így az egész nem valami áttkekinthető, még ha van is valami rejtett kapcsoló, amivel egyszerűsíti a kimenetet. De mondom, erről lassan jobb lenne egy önálló topikot nyitni, linuxos SSD benchmark címen.

Valami olyan egyszerű megoldás kéne, mint Windows alatt a Crystal Disk Mark vagy az ATTO Benchmark, ez utóbbi még jobb is. Viszont a Crystal Disk Marknak az alapja a MS SpdStr, az van Linuxra is, de nem tudom úgy felparaméterezni, hogy összevethetők legyenek a mérések a windowsos változattal. Pedig annak még a felparaméterezése is relatíve könnyebb, mint a fio-nál.

No keyboard detected... Press F1 to run the SETUP

baromi bonyás és nehézkes

ezert mondtam hogy kar is barmivel foglalkoznod hiszen nem ertesz es nem is akarsz erteni hozza, jo neked a wines atto benchmark, sot, neked tokeletes :DDDDDDDD

nem gondolod a kis egybites agyaddal hogy aki storagot mer azt pont a latency/iops erdekli nem a "470MB/s"? hogy az, hogy mekkora a queue depth hogy befolyasolja a teljesitmenyt?

kerlek nyugtass meg hogy valami olyan kozegben dolgozol ahol a szamitogep csak munkaeszkoz es nem fizet neked azert senki hogy szakerts :((

Ez van, nem lehet mindenki akkora szakember, mint kend. A wines ATTO benchmark meg nem jó, mert a ’szomnak sem kell Windows a gépre, mindenféle NTFS-ses szutyokra, Wine alatti gányolás sem különb alternatíva. Linux alá kéne olyan natív megoldás, hogy mindenféle profilozás nélkül elindítom, megmondom neki mekkora adathalmazzal teszteljen legfeljebb, erre kikapcsolt szoftveres cache mellett egyre növekvő blokkméretekben szépen végigmérné az írási, olvasási átlagokat, tőlem nem muszáj MB-ban, lehet IOPS-ban meg latencyvel, és ezt megismételné többféle queue depthben. Csak áttekinthető legyen, max. 4 grafikonban, de lehet ilyen szöveges grafikon is karakterekből kirakva. Nem szanszkrit számsor, nth percentile, vagyis tőlem az is elfér valami kiegészítő információk között, csak a lényeg látszódjon rendesen, ne a 99. oldalon kelljen bogarászni a 9 ezer adat között. Ha már CPU terhelést is tud rögzíteni a teszt alatt, meg az eredményeket html-ben meg png-ben is kiköpné reportban, akkor az meg már nettó királyság lenne, akkor már tényleg verné a windowsos benchmarkokat. Még ahhoz sem ragaszkodok, hogy GUI-s legyen. Nem kizárt a fio tudna ilyet, de részletes .fio profilt kéne hozzá hegeszteni (mínusz a grafikonok), de pl úgy kezdte, hogy meglévő 200 MB-nyi alap Phython-függőség mellé, ami már lent volt a gépen, lerántott még 300 MB-nyi egyéb Python-cuccot. Csak egy konzolos benchmark kedvéért, és akkor még az ember válogasson hozzá profilokat, meg kísérletezzen egy kazal kapcsolóval, futtassa le milliószor, hogy épp mikor lesz jó, meg mikor méri azt, amit várna tőle az ember, hogy a meghajtókat össze lehessen hasonlítani, ha más nem, átlag felhasználáshoz. De jelen pillanatban mindenféle más alternatíva megjelenéséig az is elég lenne, hogy ha az MS DiskSpd linuxos változatához meg lehetne találni azokat a kapcsolókat, amik legalább egy windowsos Crystal Disk Mark 6.x kimenetének a szintjét meg lehetne kapni (pedig elég elnagyolt méréseket csinál), elég karakteres alapon azt is, ez nem is lenne lehetetlen, mert a CDM-nek is az MS DiskSpd az alapja, annak a grafikus frontendje. De ha hajlandó valaki értelmes módon ezt a témát kitárgyalni, nyitni kéne neki egy külön topikot, mérnék még párat, és megbeszélnénk, hogy milyen kapcsolókkal lehet rajta finomítani.

No keyboard detected... Press F1 to run the SETUP

"nem muszáj MB-ban, lehet IOPS-ban" - döntsd el melyikre lősz, merthogy a két paraméter marhára nem ugyanaz... Még akkor sem, ha az elsőt MB/s-nak akartad írni :-P

Egyébként meg a mért csillió+1 adatból olyan _információkat_ rakhatsz össze/vizualizálhatsz, amilyeneket akarsz, vagy épp tudsz, ha tudod, miből, mit és hogyan lehet generálni.
Egy adatgyűjtő perifériából kaptam mondjuk napi 3000*1440 értéket - puffoghatnék, hogy de miért nem azt a 23 grafikont csinálja meg,a mi nekem kell... Előfeldolgozás után betolva egy DB-be (mert kellettek historikus idősoros adatok is), egy-két jól irányzott select, kimenet ment xls-be, és ott olyan színes-szagos grafikonokat alkotott belőle a zilletékesmanager, amilyeneket szeretett volna... (Ez sem mostanság volt... Az egyik korai DBI-s Perl-ös mókolásom volt)

Igen, MB/s-t akartam írni, csak lehagytam a /s-t, gondoltam érthető anélkül is. Elsősorban a MB/s-et preferálnám, de jó IOPS-ban is, a kettő között kézzel is át lehet váltani a blokkméret alapján: IOPS * KB_per_IO / 1024.

Az ilyen db, meg SQL select mókák ide nem lesznek jók, mert nem céges, hanem átlag felhasználóknak való megoldásról beszélünk itt végig. Azok nem fognak neked adatbázis-szerverezni, meg selectezni. Ők azt várják, hogy van egy progi, azt tárolóból felteszik, elindítják, mér, konyhakészen kiadja jól láthatóan a főbb adatokat, amit aztán mások eredményével és a gyártói értékekkel könnyen össze lehet vetni, fórumokra és benchmarkoldalakra posztolni. Nem fognak SQL szervert, meg Perl DBI-t, meg egyebeket telepítgetni, meg nem fogják kivárni, mire 2 GB-nyi függőség feltelepül hozzá egyetlen bechmark kedvéért (annak ellenére, hogy valamilyen SQL-megoldás, Perl, Phyton fent szokott lenni a full mainstream disztrókon, mert valami máshoz tuti kellenek függőségnek). A 23 grafikon is sok, az már ezen a szinten áttekinthetetlen mennyiség megint, csak arra jó, hogy átlag felhasználó elvesszen az adattengerben.

Azért írtam példának a főbb windowsos benchmarkokat. Azok sem tökéletesek, mert mindegyikből hiányzik valami, egyik latencyt nem mér, a másik CPU terhelést nem mér, a harmadik az adatok konzisztenciáját nem jeleníti meg vagy a különböző blokkméretekből túl keveset tesztel, mindegyik másban jó, ezek összegyúrva lennének a legjobbak. De pl. valahol az egész SSD-s iparág el van tévedve, hogy mindenki a szekvenciális sebességet nézi, meg reklámozza, közben meg átlagosabb felhasználásnál sokkal fontosabb a kisebb blokkméretes random eredmények meg a latency, mert a betöltési időket ez utóbbiak szabják meg leginkább, nem az, hogy a nagy fájloknál 500 vagy 2800 MB/sec-ket tud átnyomni, az csak akkor számít, ha nagy fájlokat másolnak, videót vágnak, nagyobb virtuális lemezképekkel dolgoznak, de átlag felhasználásra ezek nem nagyon jellemzőek.

No keyboard detected... Press F1 to run the SETUP

Igen, itt tudom nem Home Jóska Pista szint megy, de vannak emberek, mint én, akik még ott vannak csak megrekedve, nem a „komoly” feladatoknál, és pechre belőlük adódik ki a globális felhasználók 99%-a. Valóban indokolatlan az ő szintjükre leereszkedni, az bőven elég, ha a komolyaknak van megfelelő eszköz storagehangoláshoz.

No keyboard detected... Press F1 to run the SETUP

Pont itt hibádzik különben a linuxos felfogás, és ezért népszerűbb a windowsos platform. Utóbbi akármilyen okádék OS, arra fogja az 1 bites user, letölt egy pár megás benchmarkot, telepíti, mér, 1 perc alatt megkapja a főbb adatokat szemléletesen, szép színes ikonokkal, színes súgóval, tokkal-vonóval. Semmi fetrengés, terminálozás, paraméterezés, profilozás, függőségek, stb..

Most nem hőbörögni akarok, csak azért írom le, hogy világos legyen, hogy ez Linux alatt is abszolúte megoldható lenne, még lefejleszteni sem lenne drága, csakis az akarati tényező hiányzik. Értem, hogy felsőbbrendű vagy, és ebből jogosultnak véled magad eldönteni helyettük, hogy a felhasználók tömegeinek mire van szüksége, és mire nincs, de tévedsz. Meg legrosszabb esetben feltesszük, hogy igazad van, mert valójában semmi szüksége nincs senkinek ilyenre, akkor is ott tartunk, hogy fejlesztenek annyi fingó appot, meg értelmetlen szutykot, hogy még egy felesleges szoftver nem osztana-szorozna, akinek valóban nem lenne rá szüksége, nem használná, nem kötelező.

No keyboard detected... Press F1 to run the SETUP

megint litaniat irsz a semmirol. ki beszel itt linux vs windowsrol? en azt mondtam, hogy az olyan tanulni nem akaro, lusta emberekkel, akik egy googlet keptelenek elengedni (te) ugy altalaban nem kell foglalkozni a vilagban. azon kivul, hogy rohogunk rajtuk. nekem teljesen 8, hogy windowst hasznal, vagy linuxot.

en windowst hasznalok a jatszos desktop gepemen, nem foscsi linuxot, a munkaeszkozom pedig macos (<3), szoval szerencsere mentes vagyok az ilyen openszoszhuszarok szarjaitol ;-)

Ha ilyen tudású teszt/mérőszoftvert Windows alatt használnál, az ott is ennyi információval örvendeztetne meg. Ugyanis itt a mérőeszköz az, ami nem arra való, amire alapból használni szeretnéd. Lehet arra is hasnzálni, ha csinálsz vele egy rakat mérést, és az adathalmazt a saját szájízed szerint súlyozva a végén kiböksz 2-9 számot, hogy "nesze b+", itt van az eyecandy, zabáljad. A normálisan működő r=1 usereknek szánt mérőmotyók valahogy így működnek.
Te fogtál egy bika erős BMW motort, és panaszkodsz, hogy nem hozza a Rolls-Royce érzést. Pedig ez utóbbiban is ilyen dohog, csak épp a körítést még azért mellé kell raknod. A marhabőr táskával és az esernyővel együtt.

de, lehetNE mindenki akkora szakember, mint en, csak nem akar senki, mert egy man helyett olcsobb az interneten kisregenyt irni (jesszusmariauristen megnezted mar megint mennyit irtal a semmirol? zeller is szokott litaniakat irni, de o legalabb _valamirol_ ir...)

oszinten mennyi ido lett volna megnezted a fio doksijat, es felparameterezni amit akarsz?

egy google szinten elvezetett volna teged ide: https://github.com/khailey/fio_scripts, ami ugyan messze nem tokeletes, de jo kiindulas...

csak mennyivel egyszerubb picsogni, mint barmennyi dolgozni, ugye?

A mérni tudni kell onnan indul, hogy tudni kell jól megfogalmazni a kérdést, majd a kérdéshez megtervezni a mérést (kiválasztani az eszközt, a mérési módszert, meg a mérés eredményének a kiértékelésére vonatkozó módszer(eke)t). Utána már csak helyesen, reprodukálható módon el kell végezni a mérést, és ki kell értékelni a kapott adatokat.
Te "valamit" mértél, kaptál "valamilyen" nyers adathalmazt, amit nem tudsz hova tenni (jó pastebin, de nem erre gondoltamn). Látszik, hogy sem a mérőeszközt, sem az adott mérés célját nem igazán érted, hogy hogy és miért meg mit mér, ezért nem (sem) megy az adatok kiértékelése, és írsz olyat, hogy "egy csomó percentile szemetet egy normális átlag helyett".

Tisztában vagyok vele, hogy a percentile pontosabb képet ad, mert a nagy átlag torzíthat, nem véletlen használják GPU-k tesztelésénél is. De az áttekinthetőség kedvéért, átlag felhasználásra lemérve ezeket a meghajtókat bőven elég lenne a nagy átlag. Mint írtam, a percentile is elfér, de a lényeg legyen elé kiemelve normálisan, és ne az áttekinthetőség rovására menjen, minden legyen rendesn vagy táblázatosan, vagy grafikonban összeszedve.

Az előző hozzászólásban leírtam, 512 bájt elkezdve a kettő hatványaival osztható blokkméretekben (1K, 2K, ..., 1024 K), a megadott blokkmérethatárig, kikapcsolt szoftveres cache mellett mérjen írási, olvasási átlagokat. Akár egyre növekvő queque depthben, mindegy, hogy MB/sec + latency, vagy IOPS + latency formájában. A lényeg, hogy átlag felhasználásnál össze lehessen vetni a meghajtókat egymással és az előre megadott gyári adatokkal, hogy azokat hozza-e. Az is világos, hogy valahol minden benchmark szintetikus, ezért nem 100%-osan közelíti a valós felhasználást, valamennyire mindenképp torzítani fog.

No keyboard detected... Press F1 to run the SETUP

"átlag felhasználásra lemérve ezeket a meghajtókat bőven elég lenne a nagy átlag" - a mérésre használt eszköz nem erre szolgál. Ennyike. Egyébként meg #define átlag_felhasználás (mérés tervezése: mit szeretnénk meghatározni ugye...), utána szerintem kapsz javaslatot erre a célra alkalmas eszközre/módszertanra is.

Ha megvan, hogy milyen forgatókönyvket szeretnél végigtesztelni, akkor azt kell megnézni, hogy az eszközöd alkalmas-e erre, és ha igen, akkor már csak a mérés végigdarálása marad, az eszköz, illetve a mérési környezet automatizálhatóságát felkasználva.

De az baj, hogy te meg semmi normálisat nem tudsz írni, és úgy személyeskedsz. A beszólogatás helyett nyugodtan kezdhetted volna a fio felparaméterezését írni. De olyan konkrét paraméterezésekre gondoltam, ami kikapcsolt cache-re sem csak ilyen 150 MB/sec vagy 6800 MB/sec (vagy ezzel ekvivalens IOPS) értékeket mér egy 400-550 MB/sec szekvenciális/random átvitelt tudó, SATA3 porton üzemelő SATA3 SSD-nél, meg a mért latency-re sem *-okat kapok értékelhető eredmény helyett, és alkalmas arra, hogy több SSD eredményét össze tudjuk hasonlítani. De nem csak fio-ra, bármilyen használható megoldásra nyitott vagyok, ráadásul a téma is komolyan érdekel. Ha olyan nagy szaktekintély vagy, ne kímélj, hadd tanuljunk a mestertől. Azt értem, hogy felsőbbrendű vagy, mert a nagy random Z-t tisztelhetjük személyedben, csak az alapját nem értem az önértékelésedned annak fényében, amiket eddig irkáltál.

No keyboard detected... Press F1 to run the SETUP

mert a szemely a problema - ha folyamatosan ugy ontja magabol a felszakmai dolgokat hogy kozben nulla koze van hozza, akkor az nem szakmai problema. az, hogy valaki elnez valamit egy fio outputban, az siman megbocsathato, de az, hogy a fiot siman szemetnek nevezi mert nem vett 5 perc faradtsagot, hogy beirja a googleba hogy "fio tutorial", az szemelyi problema.

Ja, egyszer volt egy projektmenedzserünk aki nyíltan vállalta, hogy az ő tisztánlátását nem homályosítják el holmi tények meg szakmai ismeretek. :)
De ezen ne húzd fel magad, nem tudsz rajta változtatni. A fórum nem moderált, a hülyeséget nem lehet töröltetni, move on.

--
Gábriel Ákos

Csak ismételni tudom magam, ne húzd fel magad ezen (sem).
Próbálj meg módszert találni arra, hogy javuljanak az emberek körülötted. Hozz be új dolgokat, hadd fejlődjenek ők is.
Lecserélődni valószínűleg úgysem fognak, hacsak te nem lépsz le valahová.
Ha meg lelépsz akkor tudni fogod mi az első szempont a munkahely választásnál :)

--
Gábriel Ákos

( TCH | 2018. 07. 05., cs – 11:10 )

> Próbáltam keresni ilyet Windows 10-re, olyat találtam, ami induláskor és leálláskor szinkronizál, viszont ez nem tűnik biztonságosnak, olyan kellene, ami folyamatosan teszi.

Ha a RAM disk folyamatosan szinkronizál a lemezre, akkor az írás ugyanolyan lassú lesz, mintha közvetlenül a HDD-n csinálnál mindent, nem?

Sz*rk: Esetleg célszerűbb volna RSynccel manuálisan szinkronizálni, amikor úgy gondolod, hogy kell. Egy windózos RSync leírás itt.

A build az rengeteg írással is jár, hiszen a generált objecteket is ki kell írnia valahova. Persze lehetne csinálni egy második RAM disket, ami nem szinkronizál és olyan Makefile-t generálni, ami az objecteket a másik RAM diskre teszi, de ez már tényleg felesleges túlbonyolítás. Én még mindig a manuális szinkronizálást választanám. Bár leginkább - ha ennyire spúr a főnökség - vennék saját zsebre egy olcsó SSD-t és beraknám a gépbe.

Aztán mikor eljön onnan megunva a fillérb*szást, lehet igazolni h. az övé az eszköz amit a céges gépbe saját pénzen vett, meg megsemmisíteni a rajta tárolt szenzitív adatokat stb. stb. stb. Saját pénzen venni a munkavállalónak munkaeszközt... aztán ha már jó sokan csinálják, ez lesz a norma és nem a kivétel. Fizetni ne fizessen még azért is, mert irodába jár dolgozni, és használja az áramot / vizet / WC papírt?
--

Egy szóval nem mondtam, hogy a munkaadónak vegye meg az eszközt. Saját magának vegye meg és használja. Igazolásnak ott van a számla, adatmegsemmisítésre meg a dd. Szerinted mégis mit kéne csinálnia, ha az nem opció, hogy a cég vesz egy SSD-t? Szopnia a RAM diskkel, meg a szinkronizálással?

Sehol nem írtam, hogy sajnálják a pénzt egy 10e forintos munkaeszközre. Annyira sajnálják a pénzt, hogy pont most kértem, és kaptam memóriát. És amit írtam az az, hogy emiatt pont nem akarnék pofátlan lenni, és túlzásba esni, mert tudnék. Jézusom... Azért basszus, ami ezen a fórumon megy néha, az több mint nevetséges.

Lehet csak szimplán túlgondolod. Kérdezd meg, hogy lehet-e. Legfeljebb nemet mondanak. Szóval lehet te vagy a hibás és nem a munkahelyed. :D

Amúgy volt ilyen nálunk is a régi helyen. Általában a beszerzések nagyon lassan és bizonytalan kimenettel történtek. Viszont egyszer volt felmérés, hogy mindenki írja fel a listára, mire lenne szüksége. Na most az egyik projekt emberei mind felírták, hogy a 2x 19 colos hd monitorok helyett jó lenne valamivel nagyobb fullhd, legalább az egyik helyett, mivel a modern fejlesztőeszközök felülete elfoglaja már a képernyő kétharmadát a kicsiken és alig látni a kódból valamit, ami nehezíti a munkát. Páran a másik projektesek közül is csatlakoztunk ehhez.

Eltelt pár hét, majd megjöttek a monitorok. A projekt csapatomból többen panaszkodtak, hogy ők nem kaptak, bezzeg a másik projektesek igen. Amikor ezt hallotta a főnök, akkor egy érdekes beszélgetés zajlott le:
- hát, mi nem kaptunk monitorokat
- felíratkoztatok a listára?
- nem
- hát, így nem meglepő, hogy nem kaptatok
- azt gondoltuk, hogy úgysem lesz a beszerzésből semmi
- ij

Szóval, légy bátor, a helyi terminátor. Aki nem szól, annak annya sem látja a fától az erdőt :D

+1

kb. mindenki leírta, h. ne RAMDISZK-el baszkódjon, hanem vetessen 10 ezerért egy SSD-t (ha commercial ramdiszk sw-t kezd el használni, azért is ki kell majd ennyit fizetni hacsak nem lopja warezből, szóval pénzbe fog kerülni így is-úgy is). De ha akar tovább kombinálni, tegye nyugodtan. Az ember pár év-évtized után megtanulja elengedni azokat az embereket, akik tanácsot kértek, tanácsot kaptak, aztán csak azért sem fogadják meg a tanácsot. Ennyike.
--

Nézd, az, hogy vegyek SSD-t az nem tanács. Nem értem miért feltételezed, hogy egy ennyire alap dolog nem jutott az eszembe még a topic megnyitása előtt. Miért tettem volna fel a kérdést egy ennyire triviális válasz érdekében?

Szóval ne gyere azzal, hogy tanácsot kaptam, és nem fogadom el. Kaptam jókat azoktól, akik szoftvert javasoltak, a veszélyekre figyelmeztettek, vagy épp a fájlrendszer gyorsítótárakról írtak. Ezeket el is fogadtam.

Az én hibám, hogy nem jól fogalmaztam, nem voltam elég szájbarágós a fórum színvonalához mérten (tisztelet a kivételnek). Jobban ki kellett volna hangsúlyoznom, hogy a felvetett megoldás és hasonló workroundok érdekelnek.

Pedig igenis jó tanács, hogy vegyél SSD-t. Egy Kingston A400 120 gigás csak 9 ezer forint újonnan, bruttó kiskeráron, 3 év garival. Nem egy nagy szám meghajtó, de átlag felhasználásra elég, szinte pendrive árában van. Magánembernek sem érvágás, ha haladni akar a munkával, meg cégként is lehúzhatja a rolót, aki ezt a tételt nem tudja rendesen kitermelni (ráadásul cég tudná nagy tételben nettó nagykeráron is venni, meg pályázattal is leszorítani az árakat).

A RAM cache-el az a baj, hogy a RAM drága. Drágább sokkal annál, mintha SSD-t vennél.

Ezen a kettőn kívül más mód nincs. A HDD-k lassúak. Főleg NTFS-sel. FŐleg Windows alatt. Csodát nem lehet velük tenni, mindenképp csigalassúak lesznek. Akkor is ha 10000rpm-es csodák. Eljárt a technológia fölött az idő.

No keyboard detected... Press F1 to run the SETUP

Ezt mindig ugy irjatok, mintha minden cegnel vegtelen mennyisegu elvegzesre varo munka lenne, aminek az elvegzese mindig pluszbevetelt general a cegnek.

Csak egy foldhozragadt pelda: egy portas idejebe pont beleferne. Pl. ahol en megfordulok, es neha bennejszakazok, es ilyen 2-3 tajt eljovok, a portasok altalaban alszanak a kanapen. Szoval nyugodtan telepithetne ramdisket is.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Meg azt is tegyük hozzá, hogy a portások többsége csak egy bódéban vagy szobában mereszti a valagát, és lófaxt sem dolgozik. Sérvet legalábbis biztosan nem kapnak a kemény melózásban. Nézik a kistévén a meccset meg a szappanoperákat, esetleg telón faszbukoznak, meg ha beesik valaki, eligazítják, érteniük sem kell semmihez. A mérnök meg ezzel szemben tanul egy csomó évet, nagyobb pénzmaggal fektet be az életébe, meg munkahelyen is le kell tennie valamit az asztalra, úgyhogy teljesen indokolt is, hogy többet keres. Persze a portásságnak is meglehet az árnyoldala, főleg ha ilyen éjszakás műszakozás is van, de azért ne sajnáljuk már meg őket.

No keyboard detected... Press F1 to run the SETUP

Én egy nagy multinál dolgozom. És az a policy, hogy 4 évente kapsz új gépet. Négy évente le kell adni. Mégis mi gátolna meg benne, hogy vegyek egy SSD-t magamnak a céges gépbe? Amikor meg leadom, akkor belerakom a szuper hdd-t és kész. Magamnak veszem, én használom, az én időmön spórol Nem tudom, hogy honnan vetted azt, hogy ahol hardware policy létezik az egy rossz hely, mert nem fizetnek rendesen....

Farewell To The CretinsNem tudom, hogy honnan vetted azt, hogy ahol hardware policy létezik az egy rossz hely, mert nem fizetnek rendesen....

Én is láttam ilyen céget belülről. Fizetett az rendesen, ugyanakkor a havi bérköltségem 6-7%-át sem óhajtotta a cég default elkölteni arra, hogy hatékonyan tudjak dolgozni (nyilván ebben a pozícióban nem volt nehéz jóváhagyást kapni egy ssd-re, de a tény, hogy nem azzal jött a gép defaultból). Személy szerint ezt egy orbitális nagy fasságnak tartom. Jellemző, hogy a cég azért fejlődőképes volt: mire odajutottunk a felvételemet követően, hogy na akkor mobil, addigra az a policy, hogy van három elavult modell, abból választhatsz, lecserélődött arra a policy-ra, hogy vegyél akármilyet magadnak, és $350-ig elszámolhatod a számlát (ebből simán kijött egy Nexus 5x).

Ezt az idejétmúlt hülyeséget kb. 7 éve találta ki vmi idióta marketinges a spúr munkáltatók legnagyobb örömére, h. ne kelljen a melósnak céges pénzen smartphone-t venni, mégis tudja olvasni a céges leveleit bárhol.
Ha a munkáltató azt akarja h. munkaidőn kívül is elérhető legyen az alkalmazott, lesszíves neki biztosítani a munkaeszközt.
--

Háttööö a bring your OWN device-ban az "O" azt jelenti, h. a cég nem ad neked céges iphone-t, hanem a Te saját telefonodba kapsz céges SIM-et, és használod tovább a saját telefonodat munka ügyben (is). Papíron a melós boldog mert a saját szája íze szerinti eszközt használ tovább, nem pedig azt a típust amit a cég előír. Ugyanakkor ha tönkremegy / elavul, veheti a saját zsebéből az újat. Holott munkaügyben (is) használja az élettartama alatt, azaz termelő munkát (is) végez rajta.
--

Maradjunk annyiban, h. lehet így is úgy is értelmezni, pont mint a törvényeket. Az a munkáltató, aki fillérb@szó, úgy fogja értelmezni ahogy neki kedvező. Azaz h. nem kell még egy céges telefont is adni a dolgozónak, ha már úgyis mindenkinek van sajátja. Milyen jófej munkaadó vagyok, használhatod a kedvenc telefonodat a céges dolgaidra is!
--

Érdekes értelmezés.

Ahol eddig ilyesmivel találkoztam, nem ezt jelentette.

A cég adott céges telefont, céges sim kártyával, és bekonfigurálva, hogy ügyesen magától csatlakozzék a céges wifi hálózatra.

És ha a BYOD requestet kitöltöttem, akkor adtak egy usernév jelszó párost, ami ment mondjuk egy hétig, vagy egy hónapig, és azzal a saját magán telefonom is fel tudott csatlakozni egy guest wifire, amiről nem érte el a céges erőforrásokat, cserébe a mobil adatkeret fogyasztása nélkül tudtam appokat frissíteni, szinkronizálni, magán emailt olvasni, stb.

Másik cégnél (számunkra ügyfél), nekünk, külsősöknek, a céges (számukra beszállítói) laptopokat pl. nem engedték be a saját belső hálózatukba, hanem a BYOD regisztráció után a guest wifin át tudtuk elérni az internetet, a levelezést meg mindent.
Azt nem tudom, hogy ott az alkalmazottak kaptak-e telefont, vagy csak sim kártyát, vagy hogyan volt ez.

Ahol meg én találkoztam ilyesmivel, ott azt jelentette, hogy tetszőleges eszközt (Windows, OSX, iOS, Android) beregisztráltál a device management rendszerbe, és onnantól minden céges erőforrást elértél vele. A BYOD ezt jelenti, a többi csak maszatolás.

Kaptam ugyan céges eszközöket is, nagyon örült neki a család. :)

Nagyon sok olyan cég van, ahol nem megy ez még.

Sőt, ennél viccesebb, hogy az elmúlt két héten a saját cégem külföldi irodájában voltam, és a saját belső wifinket is csak erős korlátozásokkal tudtam elérni (telefon nem kapcsolódott rá, a laptop igen, de csak az intranetet látta, és pl. a levelezést sem).
Így végül 4G-s wifi dongle segítségével dolgoztam.

"A build az rengeteg írással is jár, hiszen a generált objecteket is ki kell írnia valahova"

Nem voltam specifikus a feladatot tekintve. Angular projektről van szó. Ahol kritikus a build time, az a fejlesztés közben futó folyamatos build, ami során a memóriába kerül a végtermék, és onnan szolgálja ki a dev szerver. Nincs írás, legjobb tudomásom szerint még temp fájlok sem.

( Elbandi v | 2018. 07. 05., cs – 11:30 )

linux alatt lehet olyat haxolni, hogy mdadm egyik laba egy ramdisk device (dev/ram0) masik rendes hdd. megadhato hogy olvasasra csak a ramos labat hasznalja, igy az gyors lesz. az irast meg igyisugyis megkell csinalnia a hdd-nek.

De amugy jah, vegyel egy olcsobb ssd-t, ha felszorzod a orabered meg az elb.szott idot a haxolasra (ha meg bubanc van akkor az adat helyreallitasra forditott) es mar nem is olyan draga az ssd...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Linux alatt valsz eleve nem kell ezzel küzdeni. A fájlrendszer kezelése és bufferelése sokkal jobban működik ott.
Régebben csináltam tesztet, hogy konzólból indítva egy android projekt buildjét hogyan alakul az idő win és linux alatt. Win alá 2x erősebb hardver kell hasonló sebességhez. Linux alatt az sem sokat számított, hogy ssd vagy hdd volt alatta, hdd esetén csak az első alkalommal volt valamivel lassabb, utána már bufferelt volt és simán ment.

T61, c2d t8300, Ubuntu 16.04 LTS : 4m 03s
desktop i5 760, Win7: 3m 56s
T430, i5-3320m, Win10: 3m 58s
T430, i5-3320m, Ubuntu 16.04 LTS: 2m 32s
T430, i7-3720qm, Win10: 2m 42s
T430, i7-3720qm, Ubuntu 16.04 LTS: 1m 56s

De anno volt más projekt is, ahogy nagyságrendekkel több volt win-en az idő, s ahogy néztük mi eszi a procit, úgy láttuk, hogy a fájlrendszer kezelése vitte el 90%-át a build közben (ms vc fordítóval volt qtwebkit).

> mdadm egyik laba egy ramdisk device (dev/ram0) masik rendes hdd.

Vagy overlayfs. Olvasas vinyorol, iras meg ramba megy.

Vagy tmpfs es systemd service, ami felmasolja a szukseges fajlokat a tmpfs-re bootkor.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( gelei v | 2018. 07. 05., cs – 11:46 )

^ híres utolsó mondatok című műsorunkat látták :D

Tipikus usecase: Kódolok. Pár kilobájt íródik percenként 1-2 alkalommal. Miről beszélünk? Értelmes szinkronizálás maximum pár századmásodperccel később rögzíti a hdd-re a változtatást.

Barkács? Nem tákolmányt használnék, hanem célszoftvert. Adtak fent jópár hasznos tippet a többiek. Még tesztelni nem volt időm, de feltételezem, hogy akad köztük kiforrott, jól tesztelt szoftver.

Olvasásra lassú? SSD lenne az optimum. RAM diskkel az a bajom, hogy ha gyakran szinkronizál, nem sokra mész vele, ha meg csak a gép leállásakor, akkor pedig egy esetleges megdöglés alkalmával nagyon cudarul fogod magad érezni, mert oda egy napi munkád.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem félreérted.

Nyilván a ramdisk önmagában veszélyes, ezért kerestem olyan megoldást, ami szinkronizál HDDre. A ramdiskre írás így iszonyú gyors, az olvasás iszonyú gyors, az adatok tartós tárolása pedig kis késlekedéssel (századmásodpercek, tekintve hogy alig van írási művelet) megoldódik, tehát adat nem nagyon tud elveszni.

Szinkronizálás alatt olyasmit értek, mint mondjuk amit a dropbox csinál. Nem ismerem az ide vonatkozó terminológiát.

( SySERR | 2018. 07. 05., cs – 12:33 )

BTRFS fájlrendszer tömörítéssel (compress=zlib paraméterrel) elég jól növeli a sebességet. Még a kukázott 40 gigás Maxtor diszken is teljesen jó sebességet produkál, mert a tömörítés miatt kevesebb adatot kell olvasnia a diszknek. Cserébe az írási műveletek lassabbak lehetnek.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

( Imo | 2018. 07. 05., cs – 13:14 )

Ramdisk Enterprise. Messze a legjobb ramdrive, sokéve használom kliensen, szerveren.

Tud image file-ba szinkronizálni, olyan gyakran amilyen gyakran szeretnéd. (és még ezer mást is)

( uid_16313 | 2018. 07. 05., cs – 15:18 )

ReadyBoost usb stick-kel nem jatszik?

--
robyboy

( Raynes | 2018. 07. 05., cs – 17:18 )

SuperCache és hasonló szoftverek tudják. Általában bármelyik komolyabb RAM disk proginak van ilyen funkciója.

Vagy feltesztek Linuxot, ott a kernel alapból izomból cache-el mint az állat, ha van elég szabad fizikai memória, nem kell hozzá semmilyen hack meg spéci szoftver. Ráadásul a profibb cache-elést leszámítva is a linuxos fájlrendszerek alapból gyorsabbak is, mint az NTFS, kevésbé töredeznek, főleg apró fájloknál rettenet látványos a különbség, a hajad leteszed tőle, ha előtte csak Windowst használtál. SSD-nél ez nem annyira jön ki, inkább lassabb HDD-knél látványos nagyon. Tudom, írták már előttem, de ezt én is megerősíthetem.

Az SSD-t is mindenképp fontoljátok meg, ma már kötelező minden gépbe, főleg Win10 alá, ami mániákusan tekeri a lemezt. Egyszerűen SSD nélkül felejtős a wintizezés. 9-10 ezerért vannak újonnan használható 120 gigás SATA3 SSD-k 3 év garival, azok között is jelenleg az Adata SU650 az egyik legjobb vétel. Ha cégként veszitek nagy tételben, áfavisszaigénylős/leírós mókában, akkor végképp filléres tétel.

No keyboard detected... Press F1 to run the SETUP

( deje | 2018. 07. 05., cs – 17:22 )

HDD-vel nem lehet egyszerre gyorsan és biztosan. Vagy a biztonságot gyengíted, vagy a sebességből adsz alább. Akármilyen csodaszoftver akármit is állít, nem lehet mindkettőt.

Mellesleg a windóz eleve RAM-ot használ HDD gyorsítására. Az alkalmazások által le nem foglalt fizikai RAM-ot lemez cache-nek fogja használni. Azonban hiába próbálkozol bármivel, pl boot után ugyanúgy lassú lesz első alkalommal felolvasni a fájlokat, mert a HDD a szűk keresztmetszet. Írásnál eleve a cache-be ír, legjobb tudomásom szerint write-back módban üzemel, azaz alkalmazás szempontjából az írás a cache-ben fejeződik be, és a háttérben üríti a lemezre, néhány mp-en belül.

Ramdiszket akkor érdemes használni, ha a fájlok nagyon rövid életűek és el lesznek dobva a francba nagyon hamar, nem kell őket külső hordozóra menteni. Ha kell a sok kicsi fájl, akkor nem sokra mész a ramdiszkkel a normál beépített cache-eléshez képest, illetve ha eleve csak 1x olvasod be a sok kicsi fájlt, akkor is felesleges az egész.

A ramdiszk esetleg még akkor lehet jobb, ha kevés a RAM-od, és az alkalmazások amúgy elvennék a lemez-cache elől. Persze ilyenkor meg előbb-utóbb swappelni fog a win, ami megint csak lelassít mindent.

Vegyél SSD-t, a legolcsóbb, legszarabb cucc is köröket ver HDD-re.

Persze, hogy cache-el a Windows is alapból, csak nem valami jól, ezért is építenek be külön cache-t a ramdiskes szoftverekbe. Ebben még lenne bőven hová fejlődnie a Linuxhoz képest.

Nem véletlen adnak SSD-khez is gyári windowsos szoftvert, ami külön tud „csodacache-elést”. Samsungnál a Samsung Magiciannek a Turbo Cache nevű megoldása, Crucialnál a Storage Executive Toolnak a Momentum Cache nevezetű megoldása.

Persze minden OS cache-el már régóta, a kérdés a hatékonyság. Már DOS alatt is lehetséges volt a smartdrv használatával.

Én inkább ott látom a szoftveres megoldások buktatóját, hogy a külön RAM cache akkor segít, ha van bőven elég fizikai memória, de ha arra volt pénz, akkor egy SSD-re is lenne. Ha valaki nem vesz 120-250 GB-nál nagyobb méretet, akkor az NVMe-s SSD-k sem drágák már, bár olyat is csak annak érdemes venni, aki ki is tudja hajtani, átlag felhasználói szoftverek nem szokták tudni kihasználi, azoknál bottlenck van már SATA2, SATA3 környékétől.

No keyboard detected... Press F1 to run the SETUP

hmmm... ez a "csodacache" dolog kissé hogy is mondjam... hókuszpókusz szagú. Nem tudom, mit csinál például a Samsung Turbo Cache cucca, de én jó szoftvert a koreaiaktól még nem láttam. Ez szerintem ilyen CCleaner dolog lehet, csinál valamit, amiről el tudják hitetni pár emberrel, hogy tényleg használ. Talán még van is olyan use-case, ahol tényleg segít egy picit. Ártani viszont tudnak, ha nem jól vannak megírva.
A Crucial-nak a Momentum Cache-e meg SSD-kre van, de szerintem a csoda samu szoftver is.

Windózon az NTFS lassú és töredezik. Az egyik legjobb fájlrendszer feature-öket nézve, nagyon megbízható és borzasztó rugalmas, csak lassú. Ráadásul a windóznak egyéb bajai is vannak, ha HDD-t kell kezelni, ami nem segít a lassú NTFS-en. Cserébe FAT32 vagy exFAT gyorsabbak (ha nem kell ACL meg egyéb nyalánkságok)
Továbbá érdekes lehet a btrfs driver windózra, egyes tesztek szerint a random kicsi read-write-ok gyorsabbak vele, mint NTFS-el, viszont biztosan nem annyira stabil.
Esetleg ext3, arra is van Win driver, és eléggé gyors is, régebben sokat használtam.

A Samsung Turbo Cache-e is SSD-re van. Csak a saját SSD-jükkel megy. Az, hogy gyorsít-e a lemezműveleteken, az attól függ, hogy mire használod. A nagy fájlokkal történő munkát gyorsítja, de átlag felhasználók nem nagyon használnak ilyeneket. A sok kicsi fájlt érintő lemezműveleteket valószínű nem nagyon. Csak azért említettem, hogy ha ki akar próbálni valaki a Windowsénál fejlettebb cache-elést, de nem akar Linuxot feltenni.

Így van, az NTFS lassú. A legszomorúbb, hogy a MS nem fejleszt modernebb fájlrendszert, hiába a ReFS, az sem gyorsabb semmivel, csak feature-öket adtak hozzá. Linuxos fájlrendszert pedig nem hajlandók rendesen támogatni. Ennek szerintem az az oka, hogy beköszöntött az SSD-korszak, és a gyors SSD-k elfedik az NTFS borzalmas lassúságát, így haladékot kapott.

Ezek a nem hivatalos linuxos fájlrendszerdriverek meg olyanok Windows alatt, hogy mennek, meg az adataidat eléred velük, de a teljesítményük nem valami jó. Én ext4-gyel próbálkoztam, igaz LUKS-oson, de hát nem futott valami hűdejó teljesítménnyel. A FAT32, exFAT meg vicc így már 2018-ban. Maximum pendrive-ra valók, nem rendszermeghajtóra.

No keyboard detected... Press F1 to run the SETUP

A nagy várományos ReFS -ahogy írja a szakmai közösség internetszerte- nem hogy nem gyorsabb mint az NTFS, hanem egyenesen lassabb, ill. néhány workload-nál sokkal lassabb! Ami annak fényében különösen szomorú, h. az NTFS szinte összes okosságát (ACL, quota) pont hogy kiszedték belőle! Win10-ből is mostanában kivették a Refs support-ot (kivéve céges release-k).

http://www.joshodgers.com/2016/07/10/storage-performance-refs-vs-ntfs/
https://arstechnica.com/gadgets/2017/08/microsoft-to-remove-full-refs-s…
--

( lajos22 | 2018. 07. 05., cs – 19:55 )

Dolgozz pendriveról! Rögtön szélsebesnek fogod a hdd-t érezni. :D

--
openSUSE 42.2 x86_64

Pendrive és pendrive között van még csak igazán óriási sebességjülönbség! Ha eddig csak ócskaszar repi-ajándék USB 2.0-s pendrive-okkal vert meg a sors, nézd meg mire képes egy USB 3.0, neadjisten USB 3.1-es pendrive egy megfelelő USB-t beszélni képes gépen! Kb. mint a HDD-->SSD váltás.
--

Azért ezt nem lehet ilyen sarkítva megfogalmazni. Még márkás pendrive-ok között is van különbség, pl. a USB3.0-ás Corsair Flash Voyager és a szintén USB3.0-ás Corsair Flash Voyager GT/GTX, egész más dimenzió a kettő sebességben, árban, pedig egyik sem dzsunka, mindkettő márkás modell, USB3.0-as vezérlővel. Nyilván a promós pendrive-ok átlalában csak USB2.0-ásak, azokból is a legalja.

Ha valakinek gyors pendrive kell, akkor érdemes inkább SSD-t venni helyette, még a belső SSD-ket is lehet egy filléres USB-SATA átalakítóval külső meghajtóként használni USB3.0-án, 3.1-en, köröket fog verni a létező leggyorsabb pendrive-ra, és árban is olcsóbbra kijön, mint egy drágább fajta fajta pendrive. Cserébe nem csak gyorsabb lesz, de jóval több írást is bír ki, és tárterületben is nagyobb.

No keyboard detected... Press F1 to run the SETUP

Az USB átviteli tempója (480 Mbps vagy több) egy dolog, ez elég lenne a legtöbb esetben.
A kérdés inkább az hogy a pendrive flash tempója milyen (olvasásra, írásra). Ebben vannak nagyon gyengék és normálisabbak.
Egy kis segítség a választáshoz: http://usb.userbenchmark.com/

Az USB 2.0 (kb 18 éves szabvány) busznak az elméleti maximuma az a 480 megabit. Azaz laborban, ideális körülmények között láttak már olyat, aki hallott már olyanról h. ment annyival. Okosok szerint a valóságban kb. a felét lehet belőle kipréselni, ami 240 mbit -> 30 megabájt/mp. Na ezért nem nagyon lehet ennél gyorsabban másolni usb2-s eszközre, még ha maga az eszköz bírná is, a csatoló lekorlátozza.
--

Erről beszélek. Ha 30 megabyte/másodpercet tudna az USB2-es pendrive, örülhetnénk. Valójában elég sok mindössze ötödét-tizedét tudja annak, amit az USB2 interfésze lehetővé tenne, mivel a mögöttes flash kezelése lassú.
Nekem is van egy ilyen 32 GB-osom sajnos. Nézd meg a specifikációját: https://www.kingston.com/datasheets/DTIG2_us.pdf
Általában nem az USB2 interfész tempója a valódi korlát, hanem a pendrive-ban levő flash írás-olvasás képessége.

Sajnos az USB3 interfésszel rendelkező pendrive-ok közül szintén van sok, amiben a flash nem hozza azt a tempót, ami indokolná az USB2-nél gyorsabb interfészt.

Ezen felül az sem elhanyagolható szempont, hogy bizony az usb kezelés CPU-t terhel elég rendesen, ami természetesen az USB átviteli sebesség függvényében arányosan növekszik.

USB3-as csatolón 100 MB/s közeli írás/olvasás már bizony eléggé lefogja az egész gépet...

--
robyboy

( fluxwave02 v | 2018. 07. 05., cs – 22:21 )

Én ajánlom a PrimoCache-et -- https://www.romexsoftware.com/en-us/primo-cache/purchase.html

Ez elsősorban SDD cache-ként való használatára jó, de több szinten cachel, RAM-ot is használ. Emlékeim szerint van benne olyan lehetőség, hogy induláskor betölti a korábbi cache-t. Szóval szerintem neked jó lenne. És tényleg jó egyébként, én szeretem.

A baj vele, hogy 30 USD, több gépre már jobban megéri. Szerintem én annak idején, mikor megszűnt beta lenni olcsóbban vettem meg.

( locsemege v | 2018. 07. 07., szo – 10:51 )

Szerintem a Windows is használ disk cache-t, ami meg RAM.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezzel viszont számomra megkérdőjeleződik a RAM-disk használatának értelme. Amúgy én is így gondoltam, meglepne, ha egy korszerű oprendszer nem próbálná a burst-ös nagy sebességigényt elkenni jóval kisebb átlagsebességre közbenső buffereléssel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Windows-on kb. a profil-t lehet átrakni, de az elég is, ha valaki ezt szeretné. Talán csak az az egy hátránya van, hogy nő a rendszer sérülékenysége hardverhiba esetén. Minél több HW, annál több hibalehetőség. De ennek gyakorlatilag nincs jelentősége, ha van mentés.

--
robyboy

Persze, hogy van. Néhány napja sírtam el itt a bánatomat, hogy a notebook-omban meghalt az olcsó SSD. Az újra felhúztam egy Fedora 28-at, aztán mentésből visszatettem a /home-ot, a /etc-hez puskáztam backup-ból ezt-azt, s minden úgy ment tovább, hogy lényegében semmi sem változott.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vagy a rendszered száll el, vagy az adataid, vagy mindkettő.

1 lemez = x% hibalehetőség
2 lemez = 2-szer x% hibalehetőség.

A hasonlatod ebben az aspektusban nem állja meg a helyét.

Ha egy Enterprise storage-om van, több, mint száz lemezzel, akkor minden héten fogok kb. diszket cserélni, ahogy szép sorban tönkremennek - persze ott nincs adatvesztés.

--
robyboy

Rég volt már az a valszám vizsga, ugye? :P

1 lemez mondjuk 0.2 % hibalehetőség.

600 lemez akkor 120 % hibalehetőség? :DD

Ugyan nem vagyok benne biztos, de érzésből szerintem P=1-(1-x)n,
ahol x egy eszköz meghibásodásának valószínűsége, n az eszközök száma. Persze igaz, hogy kevés eszközre és kis meghibásodási arányra közelítően n*x lesz az eredmény - kicsit kevesebb -, tehát épp, amit mondtál.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze, lehet RAID, meg minden, meg értem én a gyakorlatias megközelítést, hogy ha valamiből sok van, nagyobb az esély, hogy valamelyik megdöglik, de egy pillanatra csináljunk úgy, mint valamiféle műszaki végzettségű emberek egy hellyel-közzel szakmai portálon. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha elolvasod a szálindító hozzászólásomat, szembesülhetsz azzal, hogy egy szakmai fórumon szakmai hozzászólást olvashatsz.
Személy szerint hetente-kéthetente cserélek HDD-ket Storage-okban, adatvesztés nélkül. De mindig meghibásodik valamelyik, mert statisztikailag pont kijön az, amit kiszámoltál tudományosan.

Otthon 2 diszkkel nagyobb eséllyel fognak elszállni az adataid, mint 1-el, hacsak nem tükrözöd, de nem ez volt az eredeti gondolat, hanem, hogy a rendszer legyen 1 db SSD-n, az adatok meg 1 db HDD-n.

Nem tudom, hogy mi nem tetszik.

--
robyboy

A trendet tekintve igazad van, ezt írtam is. A számszerűsítéssel volt bajom. Kétszer annyi disk nem kétszer akkora meghibásodási valószínűséget jelent szerintem. Érzékelhető szemléletből is az ellentmondás: 100 % fölé nem mehet a meghibásodási ráta, mert már a 100 % is azt jelenti, hogy hiába cserélsz mindent újra, el sem tudod indítani, mert kapásból garantáltan legalább egy lemez rossz.

Azt is írtam, hogy alacsony eszközszám és kis meghibásodási valószínűség esetén viszont jó közelítés, hogy n-szer annyi lemez n-szeresére növeli a meghibásodás valószínűségét. Ez amolyan munkaponti linearizálás. Szűk tartományban jó közelítés, de általánosságban nem igaz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Meg úgy nagyjából bármit - ha ért hozzá az ember... Nekem a korábbi gépen a C: az OS és a legfontosabb (leggyakrabban használt) alkalmazásoké volt, a D: meg a profilokat (aka "/home") illetve a ritkábban használt lomokat tartalmazta, még XP-t használva. Az első (OS) diszk szólóban ment (ntbackup tette a dolgát rendszeresen), a másik meg két diszkre tükrözött dinamikus köteten csücsült (igen, XP és tükrözött dinamikus kötet - csak néhány megfelelő bájtot kellett itt-ott átírni...), úgyhogy onnan csak a kifejezetten fontos adatok kerültek külső diszkre kimásolásra. A Win7/10 is hasonlóan lett összerakva, köszönik, jól elvannak...

Ja, és ez az olvasási teljesítményre is elég jótékonyan hat - mivel döntően olvasásra használom a diszkeket, nem írásra, így a gyengébb írási teljesítmény nem releváns a számomra.

Logikailag lehet megkérdőjeleződik, de a gyakorlatban hidd el, hogy lehet értelme. A Windows alap cache-elése nagyon ergya, nem sokat ér sajnos. Nem tudom mi lehet az oka, ennyire mélyen nem ismerem, szerintem csak spórolós a cache-elése, nem mer sok memóriát használni hozzá, mert ahogy írod, valószínű valami átlagsebességes közbülső bufferértékkel dolgozik. A RAM disk szoftver meg annyit használ, amennyit mondasz neki.

Annyiból igazad van, hogy egy normálisan megírt OS alatt nem lenne szükség ilyen RAM drive-os csodákra, Linux alatt sincs szükség ilyenre, ott a kernel normálisan cache-el, amíg van bőven szabad RAM. Már pedig nálam pl. a 16 giga DDR3-nak a nagy része mindig szabad, és meg is látszik, mert ilyen dd-s teszteken ilyen 6,8 GB/sec-es értékek jönnek ki, mikor csak SATA3-as SSD van a gépben. Minden cache-ből megy, a kernel csak akkor írogatja ki a fizikai meghajtóra, ha annak nincs épp nagy I/O terhelése, szépen kicsöpögteti, de olyan kíméletesen, hogy a lemezműveleteket jelző LED-et is alig látni felvillanni. Így meg a programok betöltési ideje a legtöbb esetben 0-nak érződik, és a fájlműveletek nagy része is pillanat műve (nem nagyon mozgatok 8 gigánál nagyobb fájlokat). Ezt a szintet a Windows alapból nem tudja hozni, csak spéci szoftverrel.

No keyboard detected... Press F1 to run the SETUP

( mt9 | 2018. 07. 10., k – 20:38 )

A fentiekhez: Egy számomra érdekes technikai problémával fordultam hozzátok, amihez kaptam segítséget is, köszönöm.

Amit nem tudok hova tenni, az a kommentek többsége, ami viszont nem a felvetéssel foglalkozik (ami a körülményektől függetlenül szerintem izgalmas téma), hanem a munkahelyemmel, és az ssd-vel. Oké, tényleg valid tanács, hogy ssd-vel illene bővíteni. De miután ezt leírtam, elmondtam hogy miért nem játszik most, miért jön még többszáz (túlzás) komment a témában? Miért mondtok véleményt a munkahelyemről a körülmények ismerete nélkül? Jó munkahelyem van, király a fizetésemmel, és megannyi jóság van, ami mellett eltörpül az, hogy a géppark kicsit le van maradva. Apró hiányosság, mindenhol van ilyen, max másban nyilvánul meg.

Plusz ha nekem bővítenek, akkor bővíteni illene a másik száz? gépnél is. Máris nem 10e forintról van szó. Ráadásul ki akarná megvenni hosszútávra, munkára a legolcsóbb, legkisebb SSD-t?

Ha a cég fix összeggel vállal projekteket, akkor megveszik az ssd-t, mert a lassúság miatt lassabban haladsz és kevesebbet termelsz. Ha a cég órabérben dolgozik, akkor nem kapsz ssd-t, nem kell sietni. Ha saját projekteken dolgozik, akkor valami nagyon jó más bevételi forrása lehet, hogy nem cél a gyors munkavégzés, mondjuk fióknak készülő eu pályázatokon :D
Simán extrapoláljuk két információmorzsából a jövődet, https://xkcd.com/605/ :D

Nálunk pl. többen úgy csinálták, hogy saját pénzen tettek a laptopjukba SSD-t, aztán amikor le kellett adni a laptopot, akkor kivették, és otthonra még jó volt. (Az ilyesminek én elvileg ellene vagyok, de embere válogatja). A lecserélt új laptopok pedig már eleve SSD-vel jöttek.

Ezt csináld meg egy nagyobb cégnél. Az usb port is csak befele enged, nem hogy ne lenne leplombázva a géped és oldalnyitásra küldi is a jelet hálózaton :) Persze a gép beszerzés is központosított, így jobb esetben már három év után le is cserélik - persze az új - és nagy étvágyú - programok azok kellenek, mert haladjunk a korral, így gyak. a "fejlődéssel" egyre lassulunk. De ha nekik így jó.... ;P

( SkyNET | 2018. 07. 13., p – 22:50 )

Bátorítalak, a ramdisk nem csak a SATA de a PCIe/NVMe SSD-k sebességéhez képest is sokkal gyorsabb, szekvenciális és random R/W-ben is. Pár éve, mikor még programoztam, nálam az Intellij Idea system és log folderei mentek egy ramdiskre, illetve a chrome cache. A cpu lehetővé tette hogy ecc RAM volt a gépekben, és szünetmentesre voltak téve, adatvesztéstől annyira nem tartottam. A ramdisk szoftvercsomagban volt konfiguráló utility, ott be lehetett állítani hogy bootkor automatikusan jöjjön létre a ramdisk, mountolódjon, és meg lehetett neki adni egy imaget amiben mentette és visszatölötte az állapotát. Fontos fájlokat sosem tettem ramdiskre. Szóval a teljes projekteket én nem raknám ramdiskre, de IDE munkakönyvtárak, böngésző cache stb mehet szerintem.

( mt9 | 2018. 07. 24., k – 10:46 )

BTW, időközben leváltottam a Windows-t, ugyanazon a gépen a Linux sokkal gyorsabban dolgozik _valamiért_. Nyilván csoda nincs, a HDD csak HDD (és lesz SSD is, ne aggódjon senki), de fene gondolta volna, hogy ennyivel jobban fog teljesíteni az Ubuntu :)

A Windows frissen formázott diszkkel is lassú HDD-ről. A Win7 kicsit lassú, a Win10 már nagyon lassú, gyakorlatilag használhatatlan HDD-vel. A klasszikus Windowsos szopás egyik része, hogy az exe-kbe vannak az ikonok belebaszva, ergó egy valag fájlba kell beleolvasni a megjelenítéshez. Nagyjából pár ikon/sec sebességgel képes ezt elvégezni egy lassabb diszkről :D

Ezt gondold át picit... Egy darab fájlmegnyitás rendszerhívás kell (ami "drága" művelet!), utána a fájl tartalma teljes egészében elérhető, resource-okkal, tok-vonó. Ha az ikonok külön fájlokba lennének szervezve, akkor n darab fájlmegnyitás+olvasás kéne, ami rendszerhívás idő/erőforrásköltségben jelentősen nagyot dobna, plusz előbb az adott fájlt is meg kéne keresni azokban a könyvtárakban, ahol lehet (könyvtár megnyitása, felolvasása, fájl megtalálása...).

Úgyhogy ha lassú valami, akkor pont nem attól az, hogy a resource-ok bele vannak "csomagolva" a bináris fájlokba (exe, dll).

Van a rendszerben icon cache, tehát max. egyszer kell végignyálazni az épp megjelenítendő exe-ket. Ha frissen formázott diskkel is lassú a vindóz, akkor én ott inkább az NTFS nem megfelelő beállítására gondolnék: bekapcsolt tömörítés egy baromi nagy HDD-n, egy viszonylag lassú CPU mellett, vagy rohadt sok apró fájltól túlzsúfolt MFT, vagy túl kicsire vett clusterméret; ezek elég sokat ronthatnak a teljesítményen: be kell őket lőni.

Az az icon cache nyilván memóriában van, mert minden bootolás után szemmel látható, ahogyan a desktopon a cca. 15-20 ikon megjelenik... Csinálhatok róla videót is, hátha egyedi a jelenség :D

Friss telepítés, friss formázás után is csinálja, meg az n. reboot után is csinálja.
format /fs:ntfs /v:Windows /q /x /y %installdrive%
Na ha ez szar beállításokkal csinálja meg a diszket, akkor kenje a hajára az egészet a MS...

A Linux ebben (is) sokkal jobb. Az az oka, hogy a linuxos fájlrendszerek modernebbek, és sokkal kevésbé töredeznek, meg a kernel cache-elése is normálisabb. Nem csak az Ubuntura igaz, hanem bármelyik Linuxra. Főleg akkor sokkoló a különbség, ha csak lassabb HDD-ről dolgozol, és főleg kis fájlokkal. Néha egész más dimenzió a kettő.

De pl. a Linux abban is jobb, amikor hirtelen bezársz egy programot, akkor azonnal bezárja. Windows alatt tekeri a lemezt hosszabb ideig, mire bezárja. hajbazer nem hittel el, hogy nem a CPU terhelést, meg a memóriafoglalást kell nézni, hanem ezeket, és már csak emiatt is megéri jobban Linuxot használni Windows helyett (nem csak azért, mert ingyenes, nincs licencdíj, nem kell vírusoktól tartani, vírusirtót futtatni állandóan). Egyszerűbben simábban, gördülékenyen fut, különösen áll ez a HDD-s és régebbi/gyenge gépekre (amelyeken az XP-nél is jobban futhat).

No keyboard detected... Press F1 to run the SETUP

Ez igaz, de a hardverek viszont egyre erősödnek, meg a RAM méretek is folyton nőnek. Már jó ideje fejlettebb a hardver, mint hogy azt a szoftverek ki tudnák használni sebességben vagy tudásban.

A kód meg nem azért hízik, mert elfelejtenek programozni, hanem nőnek az igények, egyre több funkciót és biztonsági feature-t kell begyömöszölni a kódba, meg egyre inkább rámennek a platformfüggetlenségre is, ez meg a sovány kód ellen hat.

A Win10 meg nem amiatt lassú, mert hízik a kód, hanem elég szar az I/O kezelése, főleg a lemezkezelés, és mániákusan/feleslegesen sokat is írogat. Ezt könnyen észre is venni SSD-vel, ami számolja az írásokat. Windowsos átlagos felhasználóknál 20-30 GB szokott lenni a napi írásátlag, Linuxon jóval 10 GB alatt, noha a felhasználás ugyanaz. Maga a kernel, meg a progik viszont nem bloatabbak Windowson.

No keyboard detected... Press F1 to run the SETUP

> Ez igaz, de a hardverek viszont egyre erősödnek, meg a RAM méretek is folyton nőnek. Már jó ideje fejlettebb a hardver, mint hogy azt a szoftverek ki tudnák használni sebességben vagy tudásban.

Másnak, meg más a véleménye.

> A kód meg nem azért hízik, mert elfelejtenek programozni, hanem nőnek az igények, egyre több funkciót és biztonsági feature-t kell begyömöszölni a kódba, meg egyre inkább rámennek a platformfüggetlenségre is, ez meg a sovány kód ellen hat.

Ez is az oka. De nagyon is benne van az is, hogy olyan emberek írják, akik túlbonyolítanak dolgokat.

Ezek a klasszikus hardveres törvények, mint a Moore-törvény, meg ez, már rég nem igazak. Átlag felhasználók szempontjából már rég elértük azt a szintet, mikor már a szoftver a szűk keresztmetszet, a hardvert már nem kell 1-2 évenként lecserélni, mert teljesen elavul. 5-10 éves gépek is kiszolgálnak embereket (erősebb C2D, C2Q, korai generációs Core i és ennek megfelelő AMD-k), hacsak valakinek nem spéci a felhasználása (videóvágás, renderelés, virtuális szerverek futtatása, valami nagy projektes kódfejlesztés), meg nem akar a legújabb játékcímekkel játszani, meg 4K-ban videózni, elég sokáig elvan ugyanazzal a géppel, esetleg csak minimálisan kell bővítenie (mondjuk egy modernebb Videó Károly, egy foglalatba belemenő erősebb régi proci, +4-8 GB RAM).

Pont, hogy a szoftverek már a gát, még mindig tartja magát a 32 bit, sok program nem tudja kihasználni a többszálas végrehajtást (vagy ha ki tudja, nem skálázódik jól még több magra/szálra/CPU-ra). Egyre több szoftver már a gyors SSD-ket sem tudja kihajtani (pl. az OS-ek meg átlag felhasználói programok az NVMe-s SSD-ket), ahhoz át kéne írni őket gyökeresen. De ma már van annyi modern hardveres API, proci utasításkészlet, stb. hogy a programok csak a töredékét használják ki.

No keyboard detected... Press F1 to run the SETUP

Sok vonatkozásban egyetértek, de azzal nem, amit az SSD-k kapcsán írtál. Ott szerintem a végelen sebesség az ideális, nincs mit kihasználni, meg nem kihasználni rajta. Mondod neki, hogy kéred a file-odat RAM-ba, aztán amikor visszatér a hívásod, ott az adat. Ha hamar visszatért, hamar ott van, ha lassú az olvasás, akkor később. Szerintem ezen nincs mit kihasználni, a program futna tovább úgyis, ha ez a hívás nulla idő múlva térne vissza úgy, hogy az adat a RAM-ban van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Elméletileg így van. Gyakorlatilag meg átlag progiknál, sima OS-es desktop felhasználásnál már SATA2-től kezdve egyfajta bottleneck hatás lép fel, ha nem nagy fájlokkal dolgozol szekvenciálisan, akkor a SATA3 NAND, Optane, NVMe, RAM drive nem gyorsabb. Először én sem hittem el, amíg RAM drive-val (tmpfs), ki nem próbáltam. NVMe-t meg RAM drive-ot annak éri meg használni, aki nagy fájlokkal dolgozik, ez átlag felhasználóknál ritka. Ezért az esetek többségében megéri egy SATA3 SSD, az azonos áron eleve nagyobb tárhelyet is ad, és a gyakorlatban átlagos felhasználásnál semmivel nem érzed lassabbnak (mivel elég csak annyira gyorsnak lennie, hogy a bottleneck hatás fellépjen), csak nagy fájlokkal végzett műveleteknél meg benchmarkokon gyorsabb. Persze ki lehetne használni átlagosabb programok esetén is, de csak teljesen eltérő fájlkezelési és cache-elési stratégiával, amire az OS-ek sincsenek egyelőre felkészítve. Magyarán a szoftver nem tudja kihajtani a hardveres erőt megint, ahogy az sokmagos i7-i9, Ryzen-Threadripper procikat sem, hacsak nem renderelsz rajta.

Szép mutatója ez történelmileg visszafelé vizsgálva is. Nemrég belefutottam egy videóba, ahol egy amatőr faszi Win98-at próbálgatott gyors HDD-n, lassabb és még gyorsabb SSD-n, és a Win98 szoftverarchitekturálisan olyan régi, olyannyira nem optimálisan használja a lemezt, hogy a gyors HDD-hez képest már a lassabb normál SATA SSD-ből sem tudott érdemben rövidebb bootidőt meg programindítási időket kicsikarni, mikor pedig lehetőség lenne rá. A DOS még ennyire sem tudja a különbségeket kihajtani.

No keyboard detected... Press F1 to run the SETUP

Így már értem, mire gondolsz. Egyfelől igaz, hogy ha már ott az a vihargyors hardware, akkor próbáljunk előre gondolkodni, s ne akkor kérjük az adatot, amikor kell, hanem már korábban, s mire odaérünk, álljon rendelkezésre. Viszont ez inkább épp a lassú HDD esetén segíthetne sokat. Ne gondoljuk, hogy csak azért, mert valami gyors, ha kell, ha nem, azt ki kell használnunk. Minek? Azért, mert van egy elfogadható sebességű internet elérésem, kényszeresen töltsek le adatot akkor is, ha arra semmi szükségem?

Egy volt kollégám így nyúlt egyszer csúnyán mellé. Alulméretezett egy DSP-t. Elolvasta a katalóguslapon, hogy hány száz MFLOPS-szal tud a DSP számolni, kiszámolta, hogy az algoritmusunknak mennyi a számításigénye. Kijött, hogy bőven belefér, hurrá, megrendelte, áramkört tervezett, nyákot, legyártatta, programot írt rá. Aztán jött a meglepetés: nem fért bele a futásidőbe. Miért? Azért, mert igaz ugyan, hogy a lebegőpontos számolómű agyon van pipeline-ozva, eszement gyors, de az a sok száz MFLOPS csak a képessége. Ahhoz, hogy ezt kihasználjuk, etetni is kell adattal, mégpedig igen tempósan. Az algoritmus meg ugye nem kizárólag lebegőpontos műveletekből áll, hanem döntési helyzetekből, feltételes végrehajtásból, ciklusokból, vizsgálatokból, rendezésből, egy rakás hagyományos algoritmikus elemből, ahol viszont az számít, hogy a CPU core hány MIPS-szel tud utasításokat végrehajtani. Az ugyan jó, hogy nem kell sokat várni egy lebegőpontos osztás eredményére, de ezzel nem nagyon vagyunk kisegítve, ha minden szökőévben egyszer kell csak osztanunk. Ugyan sokat kellett számolni, kellett a DSP, de annyira burst-ösen nem állt rendelkezésre az adat, hogy ki lehessen használni teljes egészében a lebegőpontos számolómű képességeit. Így teljesen téves megközelítés ez alapján méretezni az eszközt. Ez csak akkor érdekes, ha egyszerű az algoritmus, de ömlik befelé az adat például valós idejű mintavételezésből A/D konverzió után.

Másfelől kell a sebesség, hogy akkor, amikor lebegőpontosan számol az ember - még ha ez nem is folyamatos igény -, az eredmény azonnal legyen meg, ne kelljen várni rá.

Szóval jó az SSD, mert nem kell rá sokat várni, de ettől még nem az a jó program, amelyik folyamatosan használja az elérhető sávszélességét.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Szóval jó az SSD, mert nem kell rá sokat várni, de ettől még nem az a jó program, amelyik folyamatosan használja az elérhető sávszélességét.

+1. Az erőforrás tényleg azért van, hogy használjuk, de nem mindenképpen és nem mindenáron; feleslegesen nem kell használni.

A leírásodból az jön le, hogy végre érted miről van szó. Viszont mégis rossz tanulságot vonsz le. De, igenis az a jó program, ami ki tudja hajtani a hardvert. A modern SSD-k az idők nagy részében unatkoznak, tudnák gyorsabban tolni az adatot időegység alatt, de a többi hardvernek idő kell, míg még az előzőleg kapott adatokat feldolgozzák, addig meg az SSD várakozik tétlenül. Mondom, az egész eltérő I/O stratégiát igényelne, de ahhoz fejleszteni kéne szoftveresen is.

No keyboard detected... Press F1 to run the SETUP

Ennek szerintem az az oka, hogy a megrendelő toronyórát lánccal kér tegnapra. Ennek az igénynek a kielégítésére fejlődött a software-technológia, az eszközök abba az irányba, hogy viszonylag kevés munkával, modulárisan építkezve hatékonyan, eredmény orientáltan, gyorsan lehessen programozni. Ennek viszont az az ára, hogy a compilált nyelvek is részben az interpreterekhez hasonlóan futásidőben tesznek dolgokat, mert dinamikus, objektum-orientált, multiplatform csoda az egész, s vannak dolgok, amelyek futásidőben derülnek csak ki. Arra már nincs idő, nincs ember, hogy assembly-ben meg C-ben, jelentős részt statikusan memóriára és futásidőre optimalizált kódot írjanak.

Amúgy ezért szeretek mikrokontrollerre assembly-ben programozni, mert annak megvan ez a romantikája. Apropó, az egyik munkám picike kódjában volt egy felesleges utasítás, kiszedtem belőle, ezzel spóroltam 250 ns-ot minden megszakításban. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem csak. Ennek a fő oka inkább az, hogy az ms 95-ben az egész világ torkán letolta a win95-öt, ezzel az addigi számítástechnikai piacot a sokszorosára fújva fel, ami magával vonzotta az irdatlan igényt a szoftverfejlesztőkre (nem programozókra) és ezt onnan elégítette ki a világ, ahonnan tudta, minek következtében felhígult a szakma.
Az amit te is említettél, hogy "viszonylag kevés munkával, modulárisan építkezve hatékonyan, eredmény orientáltan, gyorsan lehessen programozni", ez egyrészt azzal jár, hogy gyakran jóval kevésbé gondolják át az egészet és így a program sokszor hemzseg a rossz koncepciójú megoldásoktól, másfelől meg rábízzák magukat a felhasznált keretrendszerekre, rtl-ekre, amiből ha gagyit választanak, akkor a végeredmény is az lesz.
Én nem is mondtam, hogy mindent írjanak meg ASM-ben, meg C-ben. (ASM-ben a mai CPU-kon már amúgy sincs értelme programozni, a fordító jobban fogja tudni, hogy milyen kódot kell fordítani.) De ez még nem jelenti, hogy olyan nyelveken kell megírni őket, ami szükségszerűen egy resource-hogot fog fordítani.

Ja, PIC-en még van értelme assemblyben dolgozni. Kérdés, hogy meddig lesz még annyival olcsóbb a PIC a modernebb MCU-khoz képest, hogy megérje használni.

PIC-ek is modernek, folyamatosan fejlesztik őket, nem látom az elavulás jeleit. Éppen azt fájlalom, hogy már túl sokat tudnak, így vagy a kód konfigurátor jellegű eszközöket kell használni, vagy nagyon sokat kell olvasni a doksit, ami sok idő, belezsibbad az ember a rengeteg lehetőségbe, s inkább választ egy butább, egyszerűbb kontrollert. Abba az irányba megy a piac, hogy MCU-kat is egyre kevésbé kellemes assembly-ben programozni. Én még kitartok, igyekszem egyszerűbb mikrokontrollert választani. A gond akkor van, ha a feladat megkívánja a bonyolultabbat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amíg az egyszerűbb MCU sokkal olcsóbb is, addig van létjogosultsága. Ha a kétféle MCU árkülönbségéből keletkező gyártási extrakiadás már kevesebb, mint a fejlesztési költsége, akkor jobban megéri a komplexebb. A programozásának élvezeti faktora sajnos nem szerepel a kritikus paraméterek listáján. :P

"manapság gány a szoftverfejlesztés" - pontosítanék: fejlesztési költségre optimalizált. Lehet, hogy erőforrásban meg lehetne spórolni mondjuk 25%-ot (cpu, ram), néhány napos plusz fejlesztéssel. Mennyi most egy CPU-mag? Egy GiB RAM? És egy fejlesztő egy napi munkája? Na amelyik kisebb összeg, azt fogják rákölteni.

Eufemizálhatjuk, de attól még ugyanazt jelenti. A probléma pedig nem mindig ilyen egyszerű, hogy ha olcsóbb alárakni vasat, akkor inkább aláraknak vasat, minthogy kioptimalizálják. Egyfelől azért, mert nem csak az erőforrásigénnyel van baj, hanem a minőséggel is: nagyon bugosak manapság a programok. Másfelől pedig azért, mert amit te leírtál, az az in-house fejlesztés; de mégis mi van, ha a cég nem belső felhasználásra, hanem a piacra szánja a programot? Ja, ott pláne olcsóbb lesz a fejlesztő cégnek alárakatni a vasat, mert nem is neki kell, hanem a felhasználókkal fizetteti ki a megspórolt fejlesztői időt. Mindegyikkel, külön-külön.

Házon belül még csak-csak elmegy az a mentalitás, hogy többet nyertünk az időn, mint amibe a vas került, de amikor a júzerek tömegei kényszerülnek arra, hogy új vasat vegyenek a bloatware miatt, az ilyen "trash for da mass mozgalom" felfogás.

> hanem a felhasználókkal fizetteti ki a megspórolt fejlesztői időt

Mert egyébként a plusz fejlesztési időt nem a felhasználók fizetnék meg? Akar a gyártó X profitot szerezni egy projekttel. Te azt döntheted el, hogy a plusz hardvert fizeted ki, vagy a plusz fejlesztési költséget. Akkor már inkább a hardvert kérném, azzal még lehet kezdeni valamit később is. :)

> nagyon bugosak manapság a programok

Pont a napokban találtam otthon egy régi CD-t a ~15 évvel ezelőtti kedvenc együttesemtől. Kértem kölcsön egy külső CD olvasót, mert nem volt mivel lejátszani, kényelembe helyeztem magam, bontottam egy sört, és elindítottam. Szar volt.

A tanulság? Régen minden jobb volt. Régen is ugyanolyan jó/szar* volt minden, mint most. Régen is egy nagy rakás bugos szar volt minden.

(* Hozzáállás kérdése, ugye.)

> Mert egyébként a plusz fejlesztési időt nem a felhasználók fizetnék meg?

De, de nagyon nem mindegy, hogy valamivel többet fizetnek egy jó programért, vagy vehetnek sokkal több pénzért új vasat, egy szar program alá!

> Akar a gyártó X profitot szerezni egy projekttel. Te azt döntheted el, hogy a plusz hardvert fizeted ki, vagy a plusz fejlesztési költséget. Akkor már inkább a hardvert kérném, azzal még lehet kezdeni valamit később is. :)

Hardware-t akkor is vehetsz, ha a program drágább, de jobb, viszont, ha a program szar, azt megszívtad. Főleg mert a következő iterációja is az lesz akkor és megint vehetsz új vasat, aztán megint és megint és megint...

> Pont a napokban találtam otthon egy régi CD-t a ~15 évvel ezelőtti kedvenc együttesemtől. Kértem kölcsön egy külső CD olvasót, mert nem volt mivel lejátszani, kényelembe helyeztem magam, bontottam egy sört, és elindítottam. Szar volt.

He? Most komolyan egy zenei párhuzammal akarsz bármit igazolni? A zenei ízlés, nomen est omen, ízlés kérdése, ami változhat. 15 éve tetszett, most nem tetszik. Ennyi. Egy program minősége, bugossága, sebessége viszont egyáltalán nem ízlés kérdése.

> Régen is egy nagy rakás bugos szar volt minden.

Régen is voltak bugos, meg lassú programok, de nem ennyi, meg nem ennyire.

Hardware-t akkor is vehetsz, ha a program drágább, de jobb, viszont, ha a program szar, azt megszívtad.

Egy HW-n viszont nem csak egy szoftvert használsz jó esetben...

Innentől legyen: HW_1 a mai bikább HW ára, HW_2 a mai gyengébb HW ára. Logikusan az "extra", amit fizetsz, az HW_1 - HW_2. És akkor legyen P az összes szoftvered ára, amit azon a gépen használsz. És számoljunk mondjuk szoftvereknél 10% áremelkedéssel (muhahahaha, rotflol), amit kifizetnél, ha "kézzel assemblyben kioptimalizálnák" (© tuggyukki). Innentől ha:
* HW_1 - HW_2 > P*0.1, akkor valóban, a te use case-dre jobban megérné, ha az _összes_ gyártó optimalizálna
* HW_1 - HW_2 == P*0.1, akkor neked tökmindegy
* HW_1 - HW_2 < P*0.1, akkor neked jobban megéri a gépre költeni, mint az összes szoftvernél kifizetni az "optimalizáltságot".

P pedig egy gép "alap" élete (3-5 év, amíg a gyártói gari tart és vállalati környezetben menni szokott) elég szép összeget tud kitenni. Ha pl. csak egy Adobe Creative Cloud-ra előfizetsz, mert mondjuk fotós vagy, az három év alatt 1908 USD. Vagyis 200 dollárnyi HW fejlesztés a 10%-os (ami... na... szóval... ja) áremelésbe simán belefér, ez mondjuk az, hogy veszel egy GTX 1050 kártyát, Adobe-ék meg használják az OpenCL-t/CUDA-t.

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

> Egy HW-n viszont nem csak egy szoftvert használsz jó esetben...

Tagadhatatlan, viszont minél több erőforrásigényes software-t használok, annál hamarabb fogy el a vas ereje és akkor GOTO 10.

> Innentől legyen: HW_1 a mai bikább HW ára, HW_2 a mai gyengébb HW ára. Logikusan az "extra", amit fizetsz, az HW_1 - HW_2. És akkor
> legyen P az összes szoftvered ára, amit azon a gépen használsz. És számoljunk mondjuk szoftvereknél 10% áremelkedéssel (muhahahaha,
> rotflol), amit kifizetnél, ha "kézzel assemblyben kioptimalizálnák" (© tuggyukki). Innentől ha:
> * HW_1 - HW_2 > P*0.1, akkor valóban, a te use case-dre jobban megérné, ha az _összes_ gyártó optimalizálna
> * HW_1 - HW_2 == P*0.1, akkor neked tökmindegy
> * HW_1 - HW_2 < P*0.1, akkor neked jobban megéri a gépre költeni, mint az összes szoftvernél kifizetni az "optimalizáltságot".
>
> P pedig egy gép "alap" élete (3-5 év, amíg a gyártói gari tart és vállalati környezetben menni szokott) elég szép összeget tud
> kitenni. Ha pl. csak egy Adobe Creative Cloud-ra előfizetsz, mert mondjuk fotós vagy, az három év alatt 1908 USD. Vagyis 200
> dollárnyi HW fejlesztés a 10%-os (ami... na... szóval... ja) áremelésbe simán belefér, ez mondjuk az, hogy veszel egy GTX 1050
> kártyát, Adobe-ék meg használják az OpenCL-t/CUDA-t.

Induljunk ki ebből a kalkulációból. És kalkuláljuk hozzá, hogy mennyi software-et használnak az emberek.
- A gamerek rengeteget, a játékok miatt, náluk mindenképpen indokolt a vasvásárlás.
- Az átlagemberek szinte semmit; egy böngésző, egy képnézegető, egy zene/filmlejátszó, a fájlkezelő és esetleg egy irodai csomag. Nekik pont jobban megéri, ha drágább a software.
- Akik dolgoznak rajta, azok is szinte csak azokat a specifikus programokat használják, amikre szükségük van, nekik is jobban megérné, ha azok inkább jobban meg lennének csinálva.

Tehát ha abból indulunk ki, amit te vezettél le, akkor is az jön ki, hogy maximum a játékgépeknél van értelme a vaspumpálásnak, amúgy nem.

És mint mondottam, az erőforrásigény csak az egyik fele, a másik a bugok száma és súlyossága. Az erősebb hardware egy bizonyos szintig ellensúlyozza a megnövekedett erőforrásigényt, de a bugokat semmi nem fogja.

- Az átlagemberek szinte semmit; egy böngésző, egy képnézegető, egy zene/filmlejátszó, a fájlkezelő és esetleg egy irodai csomag. Nekik pont jobban megéri, ha drágább a software.

Na, pl. az ő use case-ükön a legtöbbet egy SSD segít, ha még nincs, kb. C2D+4GB RAM mellett az a bottleneck.
Irodai programcsomag, legyen mondjuk egy o365 előfizetés, szintén három évre: 3 * 29.900. 10 százalék különbözettel számolva 9.000, amiből már pont lehet venni egy SSD-t, ami rendszer drive-nak tökéletes erre a felhasználásra és ég-és-föld.

- Akik dolgoznak rajta, azok is szinte csak azokat a specifikus programokat használják, amikre szükségük van, nekik is jobban megérné, ha azok inkább jobban meg lennének csinálva.

Lásd fenn az Adobe-os példa (azzal dolgozni szokás és nem gémerkedni).

Tudnék persze ellenpéldát is mondani (pl. desktop statisztikai programcsomag, aminek a használati utasításában szerepel, hogy Linux alatt 2 TB memória mellett milyen swap legyen milyen beállításokkal [nem vicc... "szépen" skálázódik a 32-bites Windows apptól felfelé] és kb. kell is neki, mert ha kérsz tőle egy SQL-ben triviálisan megfogalmazható join-t és szűrést, akkor ő megcsinálja a joint... de legalábbis nagyon megpróbálja, a memóriában, amíg az OOM killer ki nem nyírja pár nappal később... aztán berántod az adatokat MySQL-be, megcsinálod ezúttal értelmesen a lekérdezést, az eredményeket visszaexportálod a progiba), mindenki tud. De akkor kezdhetnénk a vitát, hogy 10-e az a 10%, vagy pár nagyságrendet lefelé kerekítettem...

És mint mondottam, az erőforrásigény csak az egyik fele, a másik a bugok száma és súlyossága

Súlyos bugnak én azt tartom, ami adatvesztést hoz (+/- secu bugok, de ott "patch oszt jónap", kivéve persze a HW bugjai). Lekopogom, ilyet utoljára az Office 2010-környéki időkben láttam (későbbi verzióban készült, majd 2007-ben megnyitott doksinál a progik és a doksi nyelvi beállításaitól függően elegáns mozdulattal eltűntette a szóközöket... fun times).

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

> Na, pl. az ő use case-ükön a legtöbbet egy SSD segít, ha még nincs, kb. C2D+4GB RAM mellett az a bottleneck.
> Irodai programcsomag, legyen mondjuk egy o365 előfizetés, szintén három évre: 3 * 29.900. 10 százalék különbözettel számolva 9.000,
> amiből már pont lehet venni egy SSD-t, ami rendszer drive-nak tökéletes erre a felhasználásra és ég-és-föld.

Az SSD nem fog segíteni azon, ha a böngészőben a JS hegyek belassítanak mindent, vagy a böngésző megeszik huszonhat terát a RAM-ból... Az SSD azon sem segít, ha az okoseszközben a Java-s bloathegy csak minden ötödik kattintásra reagál, mert olyan lassú...

> Lásd fenn az Adobe-os példa (azzal dolgozni szokás és nem gémerkedni).

Az csak egy program (ráadásul felhő alapú), nem lehet kivetíteni az összes software-re. Egyébként, az nem baj, ha azért van valami speciális HW igénye, mert azt használja, ld. a példádban a OpenCL-t/CUDA-t. Az a baj, amikor azért kell alá generikus elemekből (CPU, RAM) hegyeket tenni, mert basztak rendesen megírni...

> Súlyos bugnak én azt tartom, ami adatvesztést hoz (+/- secu bugok, de ott "patch oszt jónap", kivéve persze a HW bugjai).

Ez nem igaz. Ha egy bug egészen konkrétan meggátol a munkában (pl. összeszarja magát a program), de adatvesztést, vagy biztonsági kockázatot nem jelent, akkor az nem súlyos bug?

Ha egy bug egészen konkrétan meggátol a munkában (pl. összeszarja magát a program),

Ha összefosta magát, akkor jó esetben buktam az éppen nyitott munkám, tehát súlyos bug. Ha viszont bloathegy és pár tíz percenként csinál egy biztonsági mentést a nyitott fájlokról, akkor csak a gyakorisága érdekel... ha havi egyszer előfordul, hogy 10 másodpercet arra várok, hogy újrainduljon a program, az a kit érdekel kategória. Ha óránként ötször összeomlik, akkor lecserélem a progit.

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

> Ha összefosta magát, akkor jó esetben buktam az éppen nyitott munkám, tehát súlyos bug.

Nem muszáj összefosnia magát, csak példa volt, elég, ha valamelyik feldolgozandó fájlt nem tudja kinyitni, mert az importerben van valami bug, ott nincs adatveszteség, vagy sechole, de nem tudod folytatni.

> Ha óránként ötször összeomlik, akkor lecserélem a progit.

Mire? Egy másikra, ami ugyanilyen fos? Arról beszélünk, hogy mi éri meg a szoftverfejlesztőcégeknek, márpedig ha ez a mentalitás éri meg, akkor a másik software is ugyanolyan minőségű lesz...

> Az csak egy program (ráadásul felhő alapú)

Az Adobe CC kb. ugyanaz mint az Office 365: vannak benne felhős szolgáltatások, de alapvetően ugyanaz a vastagkliens, mint a klasszikus verzióban. Szóval az Adobe-os példa mégiscsak jó; ugyanaz a Photoshop van a Creative Cloud előfizetésben, mint amit megvettél régen DVD-n.

> Az SSD nem fog segíteni azon, ha a böngészőben a JS hegyek belassítanak mindent

Hát nem kellett volna operációs rendszert csinálni a böngészőkből. Ez csak kisebb részben optimalizációs kérdés, már koncepció szinten el van baszva.

> Az Adobe CC kb. ugyanaz mint az Office 365: vannak benne felhős szolgáltatások, de alapvetően ugyanaz a vastagkliens, mint a
> klasszikus verzióban. Szóval az Adobe-os példa mégiscsak jó; ugyanaz a Photoshop van a Creative Cloud előfizetésben, mint amit
> megvettél régen DVD-n.

Lehet, de ez akkor is csak egy program. Mi lesz a többivel? A többi szakmával?

> Hát nem kellett volna operációs rendszert csinálni a böngészőkből. Ez csak kisebb részben optimalizációs kérdés, már koncepció szinten el van baszva.

Tény, de ez is csak azt mutatja, hogy egyre szarabbak a szoftverek. Tudsz mutatni még olyan normális böngészőt, amit fejlesztenek és nem egy bloated bughegy?

> de nagyon nem mindegy, hogy valamivel többet fizetnek egy jó programért, vagy vehetnek sokkal több pénzért új vasat, egy szar program alá

Igazad van, tényleg nem mindegy, hogy minden szoftver árába belekalkulálják az extra melót, vagy 1 db hardvervásárlással (CAPEX) kielégítem az összes bloatware szemét rendszerigényét. Arról nem is szólva, hogy a hardvert utána el tudom adni, a szoftver-optimalizáció felárát nem.

> Most komolyan egy zenei párhuzammal akarsz bármit igazolni?

Igen. Mint ahogy a példák általában, ez sem fedi 100%-ban a valóságot, de aki akarta, értette: régen sem volt minden jobb.

> Régen is voltak bugos, meg lassú programok, de nem ennyi, meg nem ennyire.

Dehogynem. Csak akkor jellemzően bugos is maradt, amíg meg nem vetted a helyi PC-boltból másolt lemezeken a patch-et, míg most van értelmes csatorna a frissítések kezelésére.

> Igazad van, tényleg nem mindegy, hogy minden szoftver árába belekalkulálják az extra melót, vagy 1 db hardvervásárlással (CAPEX) kielégítem az összes bloatware szemét rendszerigényét.

Magyarul elismered, hogy szarok a software-ek, de szerinted nem baj, mert legyen olcsóbb, bármi áron?

> Arról nem is szólva, hogy a hardvert utána el tudom adni, a szoftver-optimalizáció felárát nem.

Lehet, de így meg bugos sotware-eket fogsz használni.

> Igen. Mint ahogy a példák általában, ez sem fedi 100%-ban a valóságot, de aki akarta, értette: régen sem volt minden jobb.

Én nem mondtam, hogy régen minden jobb volt, ezt te akarod belemagyarázni abba, amit mondok. Én azt mondtam, hogy felhígult a szakma és sok a bugos software. A példádat meg nem lehet jól érteni, mert az általad vázolt párhuzam erőltetett és nonszensz. Ha valaki másnak meg még most is tetszik, akkor 1:1?

> Dehogynem. Csak akkor jellemzően bugos is maradt, amíg meg nem vetted a helyi PC-boltból másolt lemezeken a patch-et, míg most van értelmes csatorna a frissítések kezelésére.

Jó, ezen a végtelenségig ping-pongozhatunk, hogy de bugosabbak voltak, de nem, de igen, de nem...
A könnyebb frissítésben igazad van, de ez viszont hozzájárul a hanyagsághoz; nem baj, ha bugos, úgyis tudják frissíteni, régen jobban rá voltak kényszerülve a pontosabb munkára.

> Magyarul elismered, hogy szarok a software-ek, de szerinted nem baj, mert legyen olcsóbb, bármi áron?

Hát nem pont ezt mondtam, de ha csak ez maradt meg belőle, nekem mindegy.

> Én nem mondtam, hogy régen minden jobb volt
> felhígult a szakma és sok a bugos software

Tehát régebben nem volt felhígulva a szakma, tehát régebben kevesebb volt a bugos szoftver, tehát régebben jobb volt? :D

> Hát nem pont ezt mondtam, de ha csak ez maradt meg belőle, nekem mindegy.

Hát mit mondtál? Emlékeim szerint szó szerint azt mondtad, hogy olcsóbb egy hardwarevásárlással kielégíteni az összes bloatware szemét igényét. Ebből nekem az jött le, hogy nem baj, hogy bloatware, mert olcsóbb venni alá vasat. Mit akartál mondani?

> Tehát régebben nem volt felhígulva a szakma, tehát régebben kevesebb volt a bugos szoftver, tehát régebben jobb volt? :D

Általánosságban véve? Igen. Minden? Nem. Van ami régen szarabb volt. De a software nagy általánosságban véve azon dolgok közé tartozik, amit régebben tényleg jobban csináltak. Miért akarsz mindenáron ilyen "régenmindenjobbvolt" hívószavakat belemagyarázni abba amit mondok és ezzel engem beállítani a múltban ragadt, szűklátókörű hülyének?

> Ebből nekem az jött le, hogy nem baj, hogy bloatware, mert olcsóbb venni alá vasat. Mit akartál mondani?

Bajnak baj, olcsóbbnak olcsóbb, hol itt az ellentmondás?

> Miért akarsz mindenáron ilyen "régenmindenjobbvolt" hívószavakat belemagyarázni

Mfw akárhányszor elsütöttem a "régen minden jobb volt" stringet ebben a threadben, az vagy át van húzva, vagy smiley van mögötte -- tanulság: nem kell felkapni a vizet minden hülyeségen.

> Bajnak baj, olcsóbbnak olcsóbb, hol itt az ellentmondás?

Ott, hogy ha tényleg akkora baj lenne, akkor nem választanád azt, azzal a felkiáltással, hogy az az olcsóbb. Értsd: a drágább szoftvert nagyobb bajnak tartod, mint a szar szoftvert.
És ugye megint leragadtunk a teljesítménynél, pedig az csak az egyik fele; a bugokat nem tudod extra teljesítménnyel ellensúlyozni.

> Mfw akárhányszor elsütöttem a "régen minden jobb volt" stringet ebben a threadben, az vagy át van húzva, vagy smiley van mögötte -- tanulság: nem kell felkapni a vizet minden hülyeségen.

Nem kaptam fel a vizet, csak nekem az jött le belőle, hogy bagatellizálni próbálod a romló software minőséget azzal, hogy egyfolytában ezzel a "régenmindenjobbvolt" bélyeggel jössz, holott én ezt egyszer sem állítottam.

De itt most nem arról volt szó, hogy hogyan csinálják, hanem arról, hogy hogyan kéne, csinálni, hogy most szánják-e rá az extra időt és kérjék el a lóvét érte, vagy dobják ki félig készen, bugosan és optimalizálatlanul, majd veszünk alá vasat és te erre írtad azt, hogy "Mert egyébként a plusz fejlesztési időt nem a felhasználók fizetnék meg? Akar a gyártó X profitot szerezni egy projekttel. Te azt döntheted el, hogy a plusz hardvert fizeted ki, vagy a plusz fejlesztési költséget. Akkor már inkább a hardvert kérném, azzal még lehet kezdeni valamit később is. :)". Egyszóval te azt mondtad, hogyha neked, mint felhasználónak, lenne választási lehetőséged a drága de jobb szoftver és az olcsóbb és vasigényesebb között, akkor is a szarabbat választanád, mert olcsóbb. Hát ez mi mást jelent, mint azt, hogy nem baj, hogy szarok a szoftverek, mert legalább olcsóak?

Oké, rugaszkodjunk el a "mi lenne ha?" világtól, nézzünk egy konkrét, valós példát.

Én egy cég vagyok, aki megrendel egy szoftverfejlesztési projektet egy másik cégtől. A beszállító megcsinálja a cuccot, eljutunk oda, hogy működik, teszi a dolgát, de még optimalizálni kéne mert a jelen környezetben lassú. (Nem használhatatlanul lassú, nem bugos szar, csak látszik, hogy még lehetne optimalizálni rajta.)

Két opciód van, ahogy fentebb írtam:
1) bővítem az infrastruktúra kapacitását
2) tovább fizetem a cégnek 51439 forintos nettó áron az emberórákat (a példa továbbra is valódi, nem az ujjamból szoptam ki az árat)

Nyilvánvalóan az első opciót fogom választani, mert:
- olcsóbb
- CAPEX költés (~= értékesebb lesz tőle a cégem)
- másra is lehet használni a hardvert

Dobozos szoftver annyiból más, hogy sok ember között oszlik meg az extra költség, viszont nagyobb az extra költség, és a hardver jellemzően több alkalmazást futtat.

tl;dr
Baj? Igen.
Olcsóbb hardvert venni? Igen.
Szeretnék minden egyes alkalmazásnál brutális felárat fizetni azért, hogy mondjuk 10%-kal gyorsabban fusson? Hát nem.

Az okfejtésben az, hogy CAPEX == jó, az szerintem hülyeség. Nem ingatlant veszel, hanem egy nagyon gyorsan romló, drágán üzemeltethető infrastruktúrát. Amiről majd ha megromlott akkor is pénzbe kerül elköltözni az újra. Nem véletlenül virágzik a cloud.

Egyébként a cloud is valamilyen szinten az optimalizálás ellen hat, sokszor egyszerűbb többlet kapacitást venni mint optimalizálni - ehhez persze olyan architektúra kell.
És ugye a cloudnál van értelme elgondolkozni az optimalizáláson mert akkor mondjuk csak x hónapra (azon belül is esetleg csak időszakosan) kell megvenni a plusz kapacitást, kioptimalizálod amit érdemes aztán visszaadod ami nem kell.

--
Gábriel Ákos

Ez céges példa volt, konkrét igény alapján készült szoftverrel, amit te egyedül kell, hogy kifizess. A dobozos szoftver sok minden másban is különbözik, nem csak abban, hogy eloszlik az extra költség. Az emberek igénye pedig már fentebb ki lett vesézve, gyakorlatilag a gamereket leszámítva mindenki jobban járna, ha a szoftverek valamivel többe kerülnének, de jobbak lennének.

> Szeretnék minden egyes alkalmazásnál brutális felárat fizetni azért, hogy mondjuk 10%-kal gyorsabban fusson? Hát nem.

Ad 1. Ezt mire alapozod, hogy brutális felár és 10% sebességnövekedés? Mi van, ha fordítva lesz?
Ad 2. Már megint elsikkad, hogy nem csak a sebesség/erőforrásigény a baj, hanem a bugosság is. Azt hardware-rel nem fogod tudni ellensúlyozni. A hanyag, minél gyorsabban legyen kész, majd pecselünk mentalitás meg ezt fogja eredményezni. Aztán meg mivel a patch fejlesztése is pénzbe kerül, az is sebtibe készül, ergo az se sokat javít a helyzeten, ha nem ront. A kapkodás sose vezet jóra.

> A dobozos szoftver sok minden másban is különbözik, nem csak abban, hogy eloszlik az extra költség.

Igen. Abban is például, hogy a dobozos szoftvert a milliónyi különböző konfigurációs elem, és ugyanennyi különböző felhasználói igény miatt még nehezebb teljesen optimálissá tenni. :)

> Ezt mire alapozod, hogy brutális felár és 10% sebességnövekedés? Mi van, ha fordítva lesz?

Előfordulhat, de kicsi az esélye. A szoftvereket azért jellemzően nem direkt írják lassúra, emiatt általában nem triviális az ilyen léptékű optimalizáció. És ha mondjuk a fenti óradíjat nézed, kijön, hogy 1 ember 1 napi többletmunkája belekerül majdnem félmillába.

> Már megint elsikkad, hogy nem csak a sebesség/erőforrásigény a baj, hanem a bugosság is.

Nem sikkad el, viszont a sebességre optimalizálás és a bugok száma között nincs korreláció, lehet a gyors szoftver is bugos, és az optimalizálatlan bloatware is lehet (többé-kevésbé) hibamentes.

Na mindegy, én befejeztem mert ugyanazokat a köröket futjuk újra és újra, mindenki szavazzon a pénzével! :)

> Igen. Abban is például, hogy a dobozos szoftvert a milliónyi különböző konfigurációs elem, és ugyanennyi különböző felhasználói igény miatt még nehezebb teljesen optimálissá tenni. :)

És? Valamiért csak kapják a fizetésüket a fejlesztők, nem?

> A szoftvereket azért jellemzően nem direkt írják lassúra, emiatt általában nem triviális az ilyen léptékű optimalizáció.

Nem direkt írják lassúra, csak elcseszik. Lentebb az azbest kolléga által felemlegetett framework mánia pl. egy ok. De a szükségszerűen bloatot generáló nyelvek is felelősek.

> És ha mondjuk a fenti óradíjat nézed, kijön, hogy 1 ember 1 napi többletmunkája belekerül majdnem félmillába.

Miközben a fejlesztő egy hónap alatt nem keres annyit? Akkor ott valami nagy gáz lesz. Vagy a számítással, vagy a rendszerrel...

> Nem sikkad el, viszont a sebességre optimalizálás és a bugok száma között nincs korreláció, lehet a gyors szoftver is bugos, és az optimalizálatlan bloatware is lehet (többé-kevésbé) hibamentes.

Triviális korreláció nincsen, mert az egyikből nem következik a másik. Viszont a két probléma oka közös: a kapkodás és a beleszarás okozta fejlesztői hanyagság.

> ugyanazokat a köröket futjuk újra és újra

Nem egészen, mert hol ezt, hol azt mondtad. :P

> mindenki szavazzon a pénzével! :)

Akkor irány a legközelebbi torrentoldal. :P

Az elsődleges cél nem a fejlesztői költség megspórolása, hanem a fejlesztői idő kispórolása a piacra kerülést késleltető szakaszból.

Jó ideje koncepció, hogy menjen ki hw/sw a publicba akár véres torokkal, aztán majd a PR meg a patchek elintézik a többit a bevételből.

Majd ha a pék és a gumis ember is rájön a szisztémában rejlő lehetőségekre...

Szerinted ma egy építész/építőmérnök mondja meg, hogy hány beázás és hány félreszerelt pad után adható még át egy uszoda?

Vagy hogy hány folt per négyzetméter után illenék már az egész útsávot újrahúzni?

Ha egy közönséges társasházi építkezésbe beszállsz, akkor IS javíttatnivalód lesz, ha tervezéstől az átadásig minden percben ott álltál (amely "öröm" keveseknek adatik meg), és örülni fogsz, hogy átveheted, hogy végre javíttathasd.

Pontosan ugyanaz a motiváció mindenhol: mielőbbi output, kassza, aztán majd pepecselünk, ha kiszúrnak valamit. Kicsiben a lét múlik a félmunkára elkért pénzen, nagyban a negyedéves prémium.

Oké, a profitorientáltság a fő ludas, ebben igazad van, de attól még rengeteg a kutyaütő programozó. Mondjuk az is igaz, hogy ezeknek az embereknek az elkúrt képzéséért és a szükségből alkalmazásáért is a profitorientáltság a hibás... De még mindig ott vannak pl. az ingyenes/nyílt forrású cuccok. Azok között is rengeteg a trágya és ott profitról nem nagyon beszélhetünk.

Ahogy Stallman utalt rá a kiáltványban, nem csak pénz lehet a profit, hanem pl. hírnév is.

A free cuccok írói között is tolongás van. Akad, aki ellen tud állni egy túl korai rilíznek, de nem könnyű, főleg úgy nem, hogy a publikum - pláne ha friss szolgáltatás első megoldásairól van szó - kifejezetten buzerálja is a fejlesztőt, hogy bármi, csak legyen már kinn.

(Amikor a CD írása volt a húeztnézdmeg, az inkább többé mint kevésbé stabil backend programot használta vagy féltucat frontend: mindnek volt valami baja, gyakran fatális, de azért csak-csak lehetett örülni annak, hogy nem kell harminchatodszor felparaméterezni a cdrecordot.)

Maradjunk annyiban, hogy ha a tökéletes autóval lett volna szabad elkezdeni a piacot, ma még ökrös szekérrel járnánk.

Hogy pedig "régen" mennyivel voltak en bloc gondosabbak a programok, azt a 2000.01.01. előtti hónapok mutatták.
"Régen" a bugok és tervezési hibák egy szűkebb kör problémái voltak, ma meg özv. Kovácsné is szembesül velük, ő pedig nem ismer kegyelmet.

nem csak gányságról van szó. Hanem arról, hogy most minden próblémára valami framework-öt vetünk be. Persze, mivel idővel a világ összes problémáját is meg akarják oldani, ezért rettentő bloatware lesz a framework. Másrészről meg, a bonyolultabb use-case esetén is kiderül, hogy valójban nem oldja meg a framework azt a problémát, amit meg szerettünk volna úszni a használatával. Csupán a problémát már nem a programozási nyelven, vagy a platform sdk-jával kell megoldani, hanem a fölötte lévő frameworkok lehetőségeit használva. Ez sokszor egyáltalán nem könnyebb vagy gyorsabban kivitelezhető feladat, mint saját implementációt csinálni a problémára. Mert általában a hello world mindig csúcsszuperül megoldható velük, de valós életbeli problémánál már sokszor több akadályt hoznak, mint segítséget.

Aztán egy idő után, ha már mindenkinek tele van a töke, akkor egyszer csak felkapnak egy másik frameworkot, ami szintén mindenre megoldást ígér, s addig fejlesztik, hogy a mindenre is jó legyen, s egy mocskos nagy bloatware lesz abból is. Talán nem kéne minden eszközt addig fújni, míg mindenre is jó lesz, mert akkor igazából már semmire sem lesz jó. Sokszor 10x több idő a divatos megoldásokat használni, mint sajátot írni... persze a szerelmesei mindig azzal jönnek, hogy karbantarthatóbb, meg pillanatok alatt megoldható vele, meg nem kell foglalkozni sok problémával, mert alapból nem lehet az velük. Aztán két hónap múlva, amikor instabil, lassú, mégis elhasal a problémás esetben, akkor valamit összetákolnak, hogy legyen eredmény...

Partszéli belepofa: Vista óta azért ott van a töredezettség mentesítést végző időzített feladat, amivel értelmes keretek közé szorítható a töredezettség (mert egyébként valós probléma). Ahol ez elvérzik, az a task indítási feltételei: 10 perce idle a gép és "töltőn van", ráadásul ha idle vége, akkor azonnal le is lövi - amivel a laptopokon a szokásos use case (éjszaka töltőn, nappal lecsuk-kinyit, megy akksiról, amikor AC-n van, akkor meg dolgozol) mellett ki is nyírja az átlag user. (én mindenkinek szoktam javasolni, hogy amíg ebédel, hagyja ott töltőn, lockolva a gépet, pont az ilyenek miatt [pl. a Burp is megköveteli az AC-t a task schedulerből indított futtatáskor, ami ott még jogos is, mert kell a konzisztens backup...])

csak lassabb HDD-ről dolgozol, és főleg kis fájlokkal.

A sok kis fájl workloadnál SSD-vel is képes elvérezni, az ACL-ekhez olvasgatni is kell, ráadásul CPU-t is viszi, amíg az összes szabályt összegyűjti (öröklődés és hasonló mókák) és kiértékeli.

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

Az első bekezdésed nem értem. Mire fel írtad, mit nyírnak ki? A HDD-t vagy az aksit? A Linux semmilyen defragot nem végez a háttérben. Pedig támogatja már sok linuxos fájlrendszer, némelyiket még leválasztani sem kell, lehet online defragolni használat közben (pl. Btrfs). De nincsenek rászorulva a defragra, mivel eleve a fájlfoglalási stratégiájuk olyan, hogy egyenletes távolságra teszik az adatokat, amik közé szintén egyenletes távolságra írhatók további adatok, a fej meg ugrálás nélkül tudja olvasni őket, kvázi egy mozdulattal végigmegy az adatok felett a fej. Ezzel szemben az NTFS próbál mindent túlzottan sorban rendezni egymást követő szektorokba, és pont emiatt töredezik még jobban. A FAT16-32, exFAT még jobban töredezik. Eljárt már ezek fölött a MS-os szutykok felett az idő, a MS meg lusta modern fájlrendszert fejleszteni, az meg megalázó lenne nekik, ha valamelyik modern linuxos fájlrendszer támogatását oldanák meg, ami még mindig jobb lenne, mint az NTFS-sel vergődés, meg a kerék újbóli redmondi feltalálása. Az a MS és NTFS szerencséje, hogy eljött az SSD-korszak, az SSD-k nem kényesek a töredezésre, így haladékot kapott az elavult fájlrendszerük. Persze használnak még HDD-ket is, de egyre inkább csak szekvenciális archiválásra (amikor eleve kis töredezés van), nem rendszerlemeznek meg random terhelésre, mert annak úgyis állati lassú már, nagyon szűk keresztmetszet.

Meg a HDD-ken is sokan segít, mióta értelmesebb méretű cache van bennük. A régi cache nélküli és kevés cache-es (8 MB alatti) modellek jobban töredeztek, azokat tényleg rendszeresen kellett defragolni, különben használhatatlanná töredezett rajtuk az NTFS/FAT. A modern HDD-ket már nem olyan fontos, azoknak elég, ha a háttérdefrag néha részben dolgozgat rajtuk.

Az ACL-t meg cáfolni tudom, tapasztalatom szerint egyáltalán nem lassít. Elég kevés lemezművelettel jár a gyakorlatban, és a modern proci erejéhez mérten sem tétel. Főleg, hogy általában homogének az ACL-ek a mappákon belül. Nem nagyon életszerű scenárió, hogy minden egyes mappánának, azon belül almappának és fájlnak eltérő, random ACL-ei legyenek, a legtöbb azonos, öröklődik egy szinttől fogva.

Sokan ezt nem értik meg, akik az SSD-t kímélik, hogy egyrészt nem kell, meg az ilyen access time letiltása se spórol sok írást. Ezek az apró tételek nem kottyannak meg az SSD-knek. Persze ha nagyon apró fájlokról van szó, akkor igen, van olyan workload, amikor az SSD is le tud némileg térdelni, mondjuk egy eszetlen swap hegyben be tud lassulni, de ez a fajta terhelés ritkán fordul elő átlagosabb felhasználásnál, meg normálisan összeállított gépnél, amiben van az adott felhasználáshoz elég RAM. Meg szoftveres implementálással az ilyen előfordulásának elejét lehet venni okosabb fájlkezelési stratégiával, tömörítéssel, stb. Ezért kell többet ésszel, mint erővel, ész nélkül. Erről már a kernel is gondoskodik, gazdaságosabb blokkokba gyűjtve ír/olvasgat, nem darabonként pocsékolva el a háttértár sávszélességét.

No keyboard detected... Press F1 to run the SETUP

Mire fel írtad, mit nyírnak ki?

A rendszer saját önjavító mechanizmusát (gyk.: automatikus, háttérben futtatott töredezettség-mentesítés, ami nagyon nem kompatibilis egy bizonyos használati szokással...)

Elég kevés lemezművelettel jár a gyakorlatban

Ez igaz, legfeljebb 64k-val járhat a könyvtárhierarchia minden szintjén, bár lehet vicceskedni (https://www.defcon.org/images/defcon-21/dc-21-presentations/Perklin/DEF…)

Nem nagyon életszerű scenárió, hogy minden egyes mappánának, azon belül almappának és fájlnak eltérő, random ACL-ei legyenek, a legtöbb azonos, öröklődik egy szinttől fogva.

Cool, attól még erről a rendszernek meg kell győzödnie, vissza kell nézni az öröklődési hierarchiát (jó esetben ott lesz valamilyen cache-ben) és újra ki kell értékelnie...

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

De a gyakorlatban egyrészt nincsenek a mappák túl nagy mélységben egymásba ágyazva, másrészt minél nagyobb mélységben van egy mappa, annál inkább már azonos ACL-je lesz a benne lévő dolgoknak. Továbbra sem értem ez mitől nagy ügy. Egy a szteganográfiás anyagot egyelőre nem tudom mire vélni (életszerű felhasználásról van szó), ígérem belemélyedek holnap. Persze az ACL-es megoldásoknak mindenképp lesz CPU/IO overheadje, de inkább ez, mint hogy modern rendszer alá ACL-nélküli megoldást tegyél, sokat nem spórolsz vele, de oltári hátránnyal jár biztonságügyileg.

Lehet el is beszélünk egymás mellett, mert én nem csak Windowsra szűkítve írom, amit írok. Másrészt meg ha megszakad az ütemezett defrag, azzal nem nyírnak ki semmit, egy része lefut, egy része nem. Meg legközelebb apránként lefut a másik része is. Ha mindenáron öngyógyítást akarsz, akkor nem a fedél csukva tartásával meg a töltőn hagyással kell szórakozni, hanem futva hagyni a rendszert, és lefuttatni rajta kézileg egy nem ütemezett defragot.

No keyboard detected... Press F1 to run the SETUP

Másrészt meg ha megszakad az ütemezett defrag, azzal nem nyírnak ki semmit

Jó, oké, hagyjuk a "kinyír" kifejezést, látam az akadt be nálad. "Ellehetetlenít", tessék. A hülye user ellehetetleníti az automatikus defrag futását azzal, hogy tölteni csak kikapcsolt állapotban vagy aktív használat mellett szokta a gépét (így az "On AC Power" miatt nem indul el a scheduled task) ill. hogy amint nem használja, lehajtja a gép tetejét (alszik a gép, sched task nem fut le).

Ennyit írtam.

Hogy te mi minden mást olvastál bele (hol írtam olyat, hogy ne legyen ACL az FS-ben?), az már más kérdés... Annyit írtam le, hogy igen, töredezik az NTFS, az MS is felismerte, hogy töredezik az NTFS (sőt, hogy eljárt felette az idő, lásd ReFS), _tett ellene_, de a manapság legáltalánosabb use case ezt az automatizációt ellehetetleníti. Ennyi.

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

Nem tudom mit fordítasz, de a fordítás tipikusan nagy mennyiségű processz indítást igényel. Ez linux alatt sokkal hatékonyabb mint windows -ban. Nálam egy C program fordítása cygwin alatt 5 perc körül van meg, ugyanez virtuális gépen Linux alatt ~5 másodperc (a virtuális gép ugyan azon a Windowson fut). Persze a cygwin sebessége közismerten nem éppen észveszélytő.

Régebben dolgoztam úgy ahogyan te is tervezted/csinálod. Szereztem win7 alá valami ramdrive szoftvert (ingyenes volt), majd erre rámeppeltem a temp könyvtárat, illetve felmásoltam a compilert. A 25 perc körüli buildet sikerült így lefaragni 16 perc körülire. Azután vettünk Incredi Build -et és a ramdrive okafogyottá vált. Az Incredi Build -del ~5 perc alatt fordult az egész hóbelebanc.

Vigyázni kell az összehasonlításokkal, mert becsapós a téma. Engem pl. újabban nagyon zavar linux alatt, hogy laggol (legújabb Ubuntura pl. jellemzö). Ha troll lennék azt mondtanám, hogy kezd felnöni a Windows-hoz, csak nehogy megforduljon a világ egy nap.

Van amiben egyébként a Windows jobb.

--
robyboy

Részemről ez a hardvertámogatás egy rendkívül érdekes dolog. Eddig még nem találkoztam olyan hardverrel, ami nem ment az aláírásomban említett rendszer valamely verziójával. Tekintsünk el a prescott cpu-s p4-emtől, ami 32 bites, ezért a csak 64 bitre létező leap nem megy rajta. Ellenben bőven szívtam olyan hardverrel Windows alatt (pedig driver is volt hozzá), ami Linuxon pöccre indult.

--
openSUSE 42.2 x86_64

Nem tudom, milyen régre gondolsz, de elég régen a linuxos dokumentációk külön ágát jelentették azok a howtok, amelyek win alatt oob működő eszközök működésre bírását célozták meg - nem ok nélkül - és ezeknek a howtoknak az elején/végén ott szerepelt azoknak a modelleknek, almodelleknek a listája, amelyekkel már próbálkozni se volt érdemes.

A régenhez képest a linux hwtámja ma egy álom. Olykor persze rémálom.

Ez így valószínűleg nem igaz. Nehéz lenne megmondani, hogy melyik támogat több hardvert. Mennyiségileg esélyes, hogy linux alatt többféle lehet. Viszont a legújabb hardverek támogatása természetesen oda kerül be, ahová a gyártó gányol valami drivert, ami ugye a windows. Viszont win alatt sok olyan frissítés is volt, ami eldobta a kompatibilitást egy csomó régebbi hardver esetén. Win esetén teljesen normális, hogy az új winhez ki kell dobnod a nyomtatót, a scannert, vagy az egész gépet :D
Linux esetén időbeli lemaradás van, mert a gyártók általában nem segítik, vagy egyenesen akadályozzák a driverek elkészítését.

A lagot a rossz GPU driver szokta okozni. Nézz rá.

Hardvertámogatásban ma már nem jobb a Windows. Van egy kazal régi hardver (nyomtató, scanner, webkamera, stb.), amihez utoljára XP-re volt driver, meg ha volt újabbra, akkor is max. Vista, Win7, és csak 32 bites. Ezeket meg a linuxok simán viszik, 32 és 64 biten is, kevésbé bloat driverrel.

Amiben lemaradásban van a Linux hardvertámogatási téren: Wi-Fi, GPU driver GPU-nál nem is támogatásban, hanem teljesítménykihasználásban nem olyan jók még, ugyanaz a kártya windowsos driverrel, ugyanabban a játékban sokkal több fps-t ér el. Wi-Fi-ból is visz sok mindent, de firmware-csomagot kell hozzá feltenni, meg esetleg drivert meg kernelmodult forgatni, ami kezdőknek szívás lehet. Windows alatt meg csak elég a drivert feltenni. Persze Linux alatt Wi-Fi-ra mindig ott van vészesetben az NDIS wrapperes megoldás, de az már csak akkor opció, ha semmi más nem segít, és csak egy Wi-Fi eszköz miatt nem akar valaki Windowst feltenni.

No keyboard detected... Press F1 to run the SETUP