Sajnos titkosításra szükség van, még egy jófogás jellegű oldalon is
Nem, nincs.
hogy csalók meg hekkerek ne hányjanak bele middleman támadással a szerverről jövő és oda visszaérkező forgalomba
Minden Jófogást böngészőre jut egy hacker a Magyarországon élő tízmillió hackerből, aki a szomszéd WiFi-jét feltörve, vagy az optikai gerinchálózatba belebarmolva izgatottan várja, hogy rosszindulatú csomagokat fecskendezhessen szegény Jófogásozók HTTP forgalmába. 🤡 Kezded zuhanórepülésben közelíteni a tech-bulvár szintet.
meg lehet köszönni a sok rosszindulatú hekkernek, akik ahelyett, hogy elmennének dolgozni értelmes munkát, otthon ülve antitech hülyéket próbálnak lehúzni csalásokkal.
Csak hát ugye a HTTP forgalom megbuherálása pont nem megy otthon ülve. 🤡
Az a 165 MB/sec elég szép AES-re attól a muzeális géptől,
Nincs muzeális gépem. Mai igényeket, használati eseteket, a mindennapi munkámat kiszolgálni képes gépem és rendszerem van.
rohadt nagy mákod van, hogy a 2 mag, 64 bit, 4 giga RAM, SSD
Nincs egy szemnyi mákom sem. Én döntöttem így, tudatosan, hogy felbővítem 4 GB RAM-ra, meg veszek bele SSD-t.
megment
Nem kell megmentenie semminek semmitől. :) Neked tényleg nagyon átmosták az agyadat valamivel, hogy állandóan valamilyen külső veszélyt vizionálsz mindenhova, ahol számítógép- és szoftverhasználatról van szó.
Azt is elfelejted, hogy a SATA1 már kb. senkinek a gépében nincs
Megint divatalapon közelíted meg. Nekem van a gépemben egy háttértár, ami ~180 MB/s átviteli sebességet tesz lehetővé, továbbá nincs lényegi különbség a random read / sequential read teljesítménye között. Raynes, fogd már fel, hogy sehova se kell rohanni! Akkor sem, ha a szomszéd asztalnál ülőnek NVMe-s SSD-je van.
Ez, hogy az utasításkészletek kihasználatlanok maradnak sok esetben, ez a Windows-féle bináris only ökoszisztéma, és a zárt forráskód hibája.
Pontosan ugyanúgy optimalizálható Windows-os binárist előállító GCC-vel, de még a régi Visual Studiokkal is, hogy használja-e a processzor utasításkészleteit. Azon meg majd gondolkodjál el, hogy a nem adott CPU-ra optimalizált és még egy Pentium 1-en is elinduló mp3DirectCut hogyan képes századannyi CPU-ból és harmadannyi memóriából megcsinálni azt, amit a mindenféle CPU-utasítást is kihasználgató ffmpeg. 🤡 Úgy, kedves Raynes, hogy a bloat-on nem segít a compiler.
Pont ezért lenne a nyílt forráskód fontos, nem azért, mert néhány ingyenélő linuxos hippinek az idealizmusa igényelné, hanem bizonyos rendszerekre portolhatóságban, hatékonyabban futó binárissá fordításában segítség, ezáltal kitolja egy adott szoftver használhatósági körét, és így az egész szoftver jobban ellenáll az elavulásnak, meg mesterséges elavultatásnak.
Ez mind szép és jó, de egyrészt nem igaz arra, amit elmondtál (a kódoptimalizációra), elvégre a GCC sokszor nagyobb és bloat-abb kódot generál Windows-ra, mint az egyszerűbb, Windows-os compilerek, másrészt az elavulás nem ezen múlik, hanem azon, hogy a régi rendszeren fordított bináris elindul-e az új rendszeren. Windows-on elindul a 20 éve fordított bináris. Sőt Linuxon is elindul wine-nal. Szóval próbáld meg inkább erről az oldaláról megfogni. Vagy egy pillanatra gondolj bele, hogy a Linux disztrók csomagjainak forgatása közben mennyi áramot pöfögtetnek el feleslegesen.