- Nem szavazza meg Musk 56 milliárd dolláros csomagját a norvég állami vagyonalap
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- A call centerekbe viszi az AI-t a Microsoft
- ASUS routerek
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Mozilla Firefox
- Max
- Otthoni hálózat és internet megosztás
- VMware
- Tombol az AI-láz: az NVIDIA már értékesebb, mint az Apple
-
IT café
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
bambano
#30099
üzenetére
Ja, hát ezek a legmodernebb 8-10 genesek már igen, mert az Intel érzi az AMD Ryzen konkurenciának a szorítását, és most bevetnek mindent, mert már nem élhetnek vissza az erőfölényükkel. Így most pakolják bele dögivel a legalsó kategóriás procikba is a sok magot, cache-t, hiányzó utasításkészleteket, hogy ne kelljen lehúzniuk a rolót. De szerintem ezek a modern i3-ak sem érik meg, mert hasonló árban vehetsz helyettük Ryzent.
De a szóban forgó 2-3. gennél még abszolút fölénye volt az Intelnek, és az i3-akból sok mindent letiltott.
-
Frawly
veterán
válasz
Dißnäëß
#30103
üzenetére
Ja, hobbivirtualizációra, OS-eket tesztelni, meg minimális OS-eket építeni jó az 512 MB RAM egy prociszállal. De ezzel komoly dolgot nem tudsz kezdeni, én VM-nek is minimum 4 GB RAM-ot és min. 2 prociszálat adnék, az is abszolút minimum. Ilyen 1 vCPU meg 512 MB RAM-nál abszolút felejtősek azok a dolgok, amivel dobálózni szoktál, ZFS RAID, meg MySQL InnoDB és társai.
-
Frawly
veterán
válasz
bambano
#30109
üzenetére
Nekem meg elsőnek a KVM. Xen csak akkor, ha nem akar valaki még host OS-t is telepíteni, meg konfigurálgatni. De teljesen jó a KVM, nem kell semmilyen extra virtualizációs szoftver, pláne nem fizetős. Ott a KVM a kernelben, azt lehet használni QEMU-ban, tökéletes kombináció ilyen tanulásra szánt VM-ekhez, még a VT-x, VT-d is támogatott benne, ha a gép is támogatja, akkor simán megy.
A Hyper-V-t kipróbáltam anno sima desktop Win10 Prof-on, 64 bitesen, 2. gen i7-es laptopon, hát, lomha, lassú fosch az egész, de a MS-tól nem is vártam mást. Akkora overheadje van, mint az állat (ThinkPad X220 i7-2620M + 16 GB RAM mellett próbáltam). Ezt max. az ellenségemnek ajánlanám. Ha Windowson akar valaki hobbi VM-ezni, akkor VirtualBox, ha az nem tűnik elég stabilnak a feladathoz, akkor VMware Workstation ingyenes verzió.
(#30106) Dißnäëß: de én pont azt mondom, hogy én nem fukarkodnék, ha már virtuális gép, főleg szerver (vagy nem szerver, de valami modern desktop OS), én alapból min. 4GB-ot adok neki RAM-nak, és min. 2 prociszálat. Ezeket emelem is, ha szükséges, mert nem fut kielégítő sebességgel. 1 szál, meg 1 GB RAM nevetséges, annyit max. ilyen retro Win9x-es virtuális gépnek adnék, esetleg WinNT4, Win2k-hoz, de már utóbbiakhoz is belőnék 2 szálat, mert tudják kezelni.
[ Szerkesztve ]
-
Frawly
veterán
válasz
bambano
#30111
üzenetére
Ezt nem tudtam, hogy az is ott van a kernelben. Akkor lehet kipróbálom azt is. Én eddig úgy tudtam, hogy a Xen-t külön fel kell telepíteni.
(#30112) inf3rno: ezt teljesen jól tudod. De ha már VM-ben próbálgat valaki, akkor valós szimulációként próbálkozzon, és maradjon a dedup, cow, tömörítés, mindenféle redundancia stb. bekapcsolva. Ahogy kikapcsolgatsz mindent, meg ilyen minimalista ideálkörnyezetben próbálkozol, az nem fogja visszaadni, amit majd a valóságban tapasztalsz.
-
Frawly
veterán
válasz
Krystal_s
#30194
üzenetére
Próbáld meg parancssor alól. Ha még mindig Ubuntu alatt vagy, ott bontsd a Wi-Fi kapcsolatot kézzel, grafikus menüből.
Majd nyitsz egy terminált, abba (kér root jelszót, meg a Wi-Fi eszköz neve lehet nálad nem wlan0 lesz, hanem wlp-akármi, és a channel sem 1 lesz):
su
systemctl stop NetworkManager
ip link set wlan0 down
iw dev wlan0 set channel 1 HT40+
ip link set wlan0 up
wpa_supplicant -B -i wlan -c <(wpa_passphrase SSIDd WPA2jelszó)
iw devAz utolsó parancs az utolsó előtti sorban írja a width-nél hogy hány MHz-en megy. Majd mérd le, hogy mennyivel megy, megvan-e az a 270 Mbit, amit akarsz. Esetleg ha a fenti parancsok nem segítenek, akkor újrabootolsz. A grafikus felületen megint bontod kézzel a kapcsolatot. Szintén terminálba ezt adod ki:
su
nmtuiEbben bekonfigolod a kapcsolatot, és kapcsolódsz. Nézd meg, hogy itt engedi-e a 20/40 MHz-et állítani. Ha kapcsolódtál az új beállításokkal, akkor iw dev paranccsal nézd meg terminálban, hogy átállt-e 40 MHz-re.
-
Frawly
veterán
válasz
Krystal_s
#30196
üzenetére
Nem tudom mi lehet a gond. Az rfkill üzenetből ítélve mintha le lenne tiltva a Wi-Fi valami gomb-bal fizikailag a gépen.
Próbáld meg feltelepített Linux alól, ha fent van a gépen. Úgy kivédjük ezeket az rfkill hibákat, és miután kapcsolódott az SSID-hez, jobban erre a csatornamódosításra, HT40+ vagy HT40- kapcsolóra tudunk koncentrálni, hogy az iw dew utána visszaadja-e a 40 MHz-es értéket. Mert most én úgy látom, hogy jelenleg így Live-on nem is tudja egyáltalán használni a Wi-Fi-t. Grafikus felületen tudsz csatlakozni, ahogy szoktál?
-
-
Frawly
veterán
Igen, tedd be a /etc/fstab-ba az adott partíciókhoz a discard paramétert. Vagy futtasd időnként kézzel az fstim-et, vagy ütemezd be systemd service-ként systemctl-lel.
Azért létezik a két megoldás együtt, mert kezdetben egyik fájlrendszer ezt a megoldást támogatta, a másik a másikat. Ma már kb. minden fájlrendszer támogatja mindkét módszert, így mára az maradt, hogy ki melyik módszerre esküszik. A Linux disztrók zöme fstrim-et használ systemd-vel beütemezve, az Arch Linux és a rá épülő disztrók fstab discard-ot. Mindegy melyiket használod.
Ami gond lehet még, az az USB-SATA adapter. A TRIM parancsot nem mindegyik engedi át az SSD felé. Az adapterchiptől függ.
-
Frawly
veterán
A JMS 578 megfelelő chip, az elvileg támogatja az UASP módot, TRIM-et, és SMART-tot is. Nekem is van egy, igaz a SMART talán nem megy, de a TRIM és az UASP mód igen. De rég próbáltam, lehet minden menne ma már vele.
Az fstrim-nek ez a működése. Ha újrabootol a rendszer, akkor a felcsatolt partíciókon az egész szabad helyet végig TRIM-ezi (vagyis nem teszi, csak kiküldi a TRIM parancsot ezekre a szektorokra az SSD vezérlője felé). Viszont ha nem bootolsz újra, akkor második-harmadik, stb. futásnál megjegyzi, és nem TRIM-ezi meg az egész üres szabad helyet, hanem csak azokat a szektorokat, amik a legutolsó fstrim futása után szabadultak fel.
-
Frawly
veterán
válasz
bambano
#30364
üzenetére
Egyetértek. Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál.
A DDR5 állítólag megszünteti ezt a mizériát, mert abból csak ECC-s lesz, még desktopon is. Megszüntetik ezt a kettős vonalat.
De elvileg a DDR4 vezérlésében már most is vannak olyan elemek, amik valamilyen szintű hibajavításról gondoskodnak, ettől még a non ECC DDR4 RAM nem lesz ECC-s, azt teljesen nem váltja ki, de a semminél jobb.
Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Vagy HDD lett bad sectoros, vagy áramszünet miatt sérült az adatintegritás. De bitflipből még sose lett gondom. Amikor meg nagyon ritkán mégis előfordul valakivel, annak a kivédésére jók a szoftveres megoldások. Ez az ECC-mánia túl van spilázva. Ilyen szintű biztonság max. bankoknál, hadseregnél, CIA-nél, stb. indokolt.
[ Szerkesztve ]
-
-
Frawly
veterán
Igen, de ha nem tudok róla, meg nem volt belőle adatvesztés, akkor miért számítana? Általában egy RAM vagy jól működik, vagy nem. Utóbbi esetben sokkal durvább jelei vannak, mint a bitflip. Ha meg működik, akkor meg a bitflipnek nincs gyakorlati jelentősége, annyira ritka.
-
Frawly
veterán
válasz
inf3rno
#30375
üzenetére
De milyen adatvesztéshez? Tegye már fel itt a kezét, aki bitflip miatt vesztett adatot. Mondom kizárólag bitflip miatt, nem teljesen hibás RAM, bedöglött háttértár, villámkár, kártevő miatt, hanem tényleg csak is kizárólag bitflip miatt. Na, ugye, hogy senki.
Arról nem is beszélve, hogy a tömörített fájlok, médiafájlok (kép, videó, audió), SQL adatbázisok, torrentek, komoly fájlrendszerek (mint a Btrfs, ZFS, és társaik, meg az összes többi fájlrendszer, ami használ tömörítést vagy titkosítást) stb. eleve valamilyen szinten mindig használnak valamiféle CRC megoldást, alapból. Tehát maximum nagyon alap fájlrendszereken lévő plain text fájloknál, és binárisoknál vagy kitéve, hogy a bitflip miatt félremehet valami. De binárisoknál is elméleti az esélye, mert ha egy bit is félremegy, az már másik opcode, azonnal crashel a program, vagy fagy az egész gép, nem marad észrevétlen. Plain text fájlokban, úgy, hogy tömörítve sincsenek, azokban nem tárol senki kritikus fontosságú adatot. Forráskódok általában fent vannak git-en, helyileg pedig megint tömöríteni szokták őket. Így maximum logokról meg CSV fájlokról tudom elképzelni, hogy csak így plain text-ben vannak hagyva, natúron.
-
Frawly
veterán
válasz
inf3rno
#30378
üzenetére
Értem, szóval a bitflip még mindig urban legend, mindenki hallott róla, csak még senki nem tapasztalta. Amit a képen mutatsz, olyat én is láttam már, az nem bitflip, hanem okozhatja meghibásodott háttértár, rossz letöltődés. Persze RAM hiba is, de nem bitflip, hanem en bloc kaka RAM. Ezért kell CRC-ről meg redundanciáról gondoskodni, mert nem csak a RAM lehet hibás, meg nem csak bitflip fordulhat elő, önmagában az ECC sem tesz csodát, csak plusz egy védelmi intézkedés a sok közül.
Félre ne értesetek, nem az ECC RAM ellen vagyok, ha a platformja támogatja és valaki tud szerezni olcsón (pl. DDR3-ból még olcsóbb is az ECC, mert sok szerverből kukázott RAM-ot árulnak használtan), akkor miért ne, plusz egy védelmi vonal, senkit nem vitt még el a mentő, mert ECC-set használt. Én arról beszélek, hogy ez a divathájp, meg tömegpánik, hogy ZFS, jajjaisntem, csak-ECC, jajjmerhamivanhabitflipvanezeréventeegyszer hiszti csak ilyen marketingesek által felfújt baromság. Nem szabad neki bedőlni, van élet az ECC-n túl is.
-
Frawly
veterán
válasz
Mr Dini
#30404
üzenetére
A testdisket nem ismerem, de ezt Windows alól kéne csinálni, GetDataBack for NTFS nevű progival. Ha lehetséges némi adatot visszahozni, az képes rá, és tud önállóan bootolni, nem kell neki létező Windows telepítés. Mindent nem fog tudni az se helyreállítani, mert mint írtad, az adatok egy része felül lett írva, így a felülírt adatok mindenképpen elvesztek örökre, visszaállíthatatlanul.
Ez egy windowsos probléma, windowsos partíciókkal, felesleges a Linuxot belekeverni. Hiszen NTFS és FAT32 fájlrendszerekről van szó.
Illetve a particionálást ezért nem szabad laikusokra bízni. Főleg, ha a tárolt adatokról nincs biztonsági mentés. Nem véletlenül írja minden particionálóprogram, hogy mekkora méretű lemezt particionálsz, hogy nehogy valami másikat válasszon valaki véletlenül, meg még utána 5× rákérdez, hogy „biztosan akarja?”, „biztosan akarja, minden adat el fog veszni a lemezről”, „biztosan de biztosan akarja?”, „végül: biztos abban, hogy biztosan, de biztosan akarja?”. Ezek a kérdések nem azért vannak, hogy kényelmetlenséget okozzanak, hanem ennek a „véletlen” adatvesztésnek a károkozásait elkerüljék.
-
Frawly
veterán
válasz
vargalex
#30408
üzenetére
Ezt jó tudni, egyik megoldást sem ismerem, szükség esetén meg fogom próbálni. Nálam régen a GetDataBack for NTFS vált be, de az is kb. 10 éve használtam utoljára valakinek a gépén, akinek meghalt a HDD-je.
Mióta Linuxot használok, nem volt ilyenre szükségem. Egyszer írtam felül véletlenül (jó itt korrigálnék, nem véletlenül, hanem szín tisztán a FreeDOS telepítő hibájából) a partíciós táblám (FreeDOS-szal játszottam retrózás képpen), csak a GPT táblát (partíciók érintetlenek maradtak), de azt emlékezetből rekonstruálni tudtam, 100MiB-os EFI partíció, 50 GiB-os ext4, maradék ext4, mindegyik egész MiB-os (2048 db 512 bájtos) szektorhatáron kezdődik, rebootkor már minden működött, minden adat a helyén volt. Igaz volt mentés a felhasználói adatokról, de azért örültem, hogy a rendszert nem kellett újrahúzni, mert az azért melós lett volna, arról nem volt mentés.
-
Frawly
veterán
válasz
I02S3F
#30410
üzenetére
Nem, nem mentem. Azért szoktam le a rendszer mentéséről, mert állandóan változnak a felhasználási szokásaim. Kb. fél-egy évente úgyis újrahúzom az Archot, teljesen másik grafikus felülettel, meg pár progit is mindig lecserélek, ezért nem látom értelmét régi rendszert eltenni. Nekem a belakott rendszer nem szent, szeretek tiszta lappal kezdeni, meg különféle dolgokat kipróbálni. A konfigjaim a /home-on viszont el vannak téve, meg mentem őket, azokból fel tudok használni az új rendszer alatt, meg a csomaglistát is elmentem.
-
Frawly
veterán
Igazából nálam is csak pótcselekvés, meg hoppolás, hogy mindig újratelepítem, mindig másik megoldásokkal fűszerezve. Természetesen a rolling arról szólna, hogy sose kell újratelepíteni, 10 év múlva sem. De én szeretek tiszta lappal kezdeni, úgy, hogy a rendszerbe nincs begyűlve semmi sallang, semmi felesleges csomag, és ilyenkor tényleg megragadom az alkalmat, hogy valami mást is kipróbáljak. Igaz ez is egyre jobban változik, mert ahogy megyek egyre jobban a minimalizmus, terminálalapúság, tiling WM-ek irányába, úgy már egyre kevésbé váltogatom a programokat, mert már nem találok nagyon hatékonyabb megoldásokat.
-
Frawly
veterán
válasz
I02S3F
#30443
üzenetére
Szenvedni kell ilyen spéci telepítők meg kernelek telepítésével, ami később egy csomó anomáliához vezet, egy nagy rakás szoftver bugosan működik rajtuk. Ezt a latencyt létező problémaként két felhasználási területen tudom elképzelni:
1) valaki zenész, és effektezett hangszeren nyomja, és fontos, hogy ahogy lenyomta azt a billentyűt, akkor azonnal az a hang szóljon
2) emulátorplatformokon, hogy esetleges emulációs overhead miatt nehogy késsen a hang pár ms-ot a játékbeli akcióhoz, kirajzoláshoz képest.De ezen a latency dolgon pont olyan szoktak vergődni, akiknek igazából nem fontos, nem kötelező Reaperhez sem, meg hifistáknak sem, külső DAC-os bithelyes lejátszáshoz sem kell.
-
Frawly
veterán
Akkor ezek szerint az 1)-es pont alá tartozol, akkor vedd úgy, hogy nem szóltam. Én általában hifistáknál olvasom, hogy tyűűá, asio, meg latency, hogy jól szóljon a FLAC, ez az, amit sose értettem. Ha tényleg szükség van a low latency-re valami spéci felhasználás miatt, akkor oké.
-
Frawly
veterán
Nekem még semmilyen rendszer alatt nem volt reccsenés a zenében. Sem anno XP alatt, sem 7 alatt, sem 10 alatt, ASIO-val és anélkük sem, sem Linux alatt, normál kernellel sem, disztrótól függetlenül.
Mondom ezt úgy, hogy pl. a Pulseaudio-t utálom, de nem azon fog múlni, meg nem a kernel latencyjén. De ezek szerint csak kellően nagy buffert kell neki adni. Mai 4-32 GB RAM-os gépek korában nem hinném, hogy +/- 1 giga audio buffer okozna gondot bárkinek, vagy a sok magos procik nem bírnák a szoftveres mixelési tempót effektezésnél.
-
Frawly
veterán
válasz
bambano
#30452
üzenetére
Igen, azért írtam, hogy zenésznek fontos lehet a low latency. Hifista Jóskának viszont nem, és továbbá nem, nem 5 másodperc múlva hallja a zenét, hanem pár ms késéssel, ami nem határoz meg semmit minőségben, mert minden adat ugyanannyi ms-ot fog késni, így jitter sem lesz, a hangminőségbe nem fog beleszólni, recsegés sem lesz, mert amik lennének késés miatt hirtelen egyenetlenségek, azokat a buffer és az azt kezelő eszköz belső órája, szinkronizációja kisimítja.
-
Frawly
veterán
válasz
CPT.Pirk
#30453
üzenetére
Igen, ez tisztán csak a Wine-fejlsztőknek mond valamit, oda bugreportold. Ilyesmiket én is kapok mostanában, mikor Apple iTunes-ből kivett QAAC encodert futtatok Wine alatt:
00b8:fixme:advapi:GetCurrentHwProfileA (0x21e930) semi-stub
qaac 2.69, CoreAudioToolbox 7.10.9.0
00b8:fixme:ver:GetCurrentPackageId (000000000021E480 0000000000000000): stubEmiatt nálam hol működik ez a progi, hol nem (hibás fájlokat gyárt le). Attól függően, hogy épp hogy frissül a Wine.
-
Frawly
veterán
válasz
sh4d0w
#30457
üzenetére
Nem sh4d0w-nak szánom, de mégis az ő hsz.-ére nyomom most a választ, mert ide tartozik. Ezt nagyon nem kéne gyerekek. Ezt az övön aluli ütéseket nagyon utálom, gerinctelenség. Hozzászóltam kettőt ebben a topikban, erre a fix.tv-s low latency-re reagálva, erre most látom, hogy szép csendben törölve lett. Tessék tudomásul venni, hogy ez egy fórum, ahol nem mindenki ért egyet, különböző véleményeket írnak be és ütköztetnek az emberek. Ha némileg lazul is egy-két esetben a témához kötöttség, attól még meg kéne hagyni, ha valakit annyira zavar, tegye OFF-ba a hsz-t, vagy kérje meg az embereket, hogy kanyarodjanak vissza szorosabban a témához, vagy ha nagyon feszültség van a véleménykülönbségek miatt, akkor csak hagyják annyiba. Ez lehet óvodában, meg Észak-Koreában divat, hogy a cenzúra malmai szép halkan, észrevétlenül őrülnek, egy nyugathoz tartozni akaró ország legnagyobb informatikai fórumán viszont nagyon gáz. Egyszerűen nem nem korrekt, hanem kifejezetten sunyi húzás, moderátori jog ide vagy oda!!!!!!!!!!!!!!!!!!!!!!!!!!
Tényleg nem a kollégának szánom, csak azért erre a hsz-re írom ezt válaszként, mert eredetileg is az ő hsz-ére reagáltam, ezért oda tartozik.
[ Szerkesztve ]
-
Frawly
veterán
válasz
Jester01
#30519
üzenetére
Nem tudni mitől döglenek a vezérlők. Szerintem a gyártók méretezik alul tervezett elavulás képpen. Szinte sose a NAND fárad ki, hanem a vezérlő fekszik ki, és ez akkor is megtörténik x időn belül, ha nem írtál a NAND-ra sokat. Nem csak azoknál az SSD-knél, amik a te kezed közé kerültek, hanem kb. az SSD-k 99,9999%-a ilyen.
(#30517) sh4d0w: nem értem, hogy mi ez, ami van. Az SSD vezérlője nem lát partíciókat, meg fájlokat, meg akármiket. Low level szinten kezeli az adatokat, így ezért mindegy, hogy titkosítva van vagy nincs. Vagyis egy esetben nem mindegy: egész lemezes szoftveres titkosításnál külön át kell engedni a TRIM-et a titkosítási rétegen, különben a vezérlő úgy látja, hogy az egész meghajtó be van telve, minden cellában lévő adatra szükség van, nem szabadíthat fel egy cellát sem. Viszont az átengedett TRIM meg gyengíti a titkosítás biztonságát, mivel mintázati támadást tesz lehetővé. Bár csak elméletileg, olyanról nem olvastam, akinek a titkosított adatait megtörték volna emiatt.
Aki SSD-t akar titkosítani, annak inkább hardveres titkosítást ajánlom. Egyetlen buktatója, hogy nem elég az SSD-nek tudnia ezt, hanem az alaplapnak és BIOS-nak is támogatnia kell (vagy nem kell, de akkor bootolni nem lehet róla), és a legtöbb konzumer lap nem támogatja, csak a céges kliensek, munkaállomások, üzleti laptopok, stb.. Meg ugye az SSD gyártójának a zárt hardveres titkosítása mindig megbízhatatlan, mivel nyílt forráskód híján csak bízni tudsz benne, hogy nincs az implementációjában gyengeség vagy kiskapu.
-
Frawly
veterán
válasz
BeeNiTTo
#30535
üzenetére
Kár volt kiszerkeszteni, főleg hogy azóta a kezdőben sem kérdezted meg. Játék Linuxon: de, igenis sokat változott a helyzet. Lényegében pár kivétellel az összes játék megy már, azok nem mennek főleg, amely játékok valami anti cheat, DRM védelem, hozzáláncolt Win only Launcher (ez is egyfajta DRM) miatt nem mennek, de ne feledd, hogy ez szándékos, nem a Linux hibája, hanem a játékot írták meg szándékosan úgy, hogy Windowson kívül semmi sehol máshol ne fusson. Pedig amúgy mennének ezek is Linuxon, nem lenne technikai akadálya, csak a játékkiadó fél, hogy Linuxon ilyen extra védelmek nélkül könnyű lenne törni a játékot, vagy cheatelni, mivel a Linux közvetlenebb rendszer és hardverhozzáférést tesz lehetővé, és nem kell rejtett szolgáltatásokat kerülgetni, ahogy Windowson.
De ugyanez van videóstreameknél is. A Netflix Linuxon 720p-re van korlátozva, pedig menne az 1080p, önkéntesek meg is csinálták, de a Netflix mindig buherál valamit, hogy ne menjen, mert az 1080p+ Windows/Mac/spéci médiaplatform only, így egyeztek meg a kiadókkal, hogy DRM csak ezeken engedje a nagyobb felbontásokat. Az HBO ennél is rosszabb, az HBO Max eddig ment Linuxon, most pl. sehogy nem megy, mert szándékosan így intézte az HBO, megint DRM védelem és jogkezelés miatt.
-
Frawly
veterán
válasz
CPT.Pirk
#30541
üzenetére
Nem működik már jó ideje a firefoxos Netflix 1080p addon. Amíg ment, használtam is, de már van majdnem egy éve nem megy. Nincs böngészőhöz kötve, vagyis olyan értelemben, hogy a böngésző a widevine DRM plugint használja, és ezzel kapcsolatos a korlátozás. De ez nem csak Linuxon van, androidos eszközök legtöbbjén is korlátozva van a felbontás, néha még jobban is, mint Linuxon a 720p, pl. a Xiaomi A2 telómon csak 480p-re, mert a gyártó nem tejelt extra pénzt a Netflixnek, emiatt nem kapott meg valami magasabb DRM minősítési levelt, és emiatt csak SD-re van korlátozva. Pedig ugyanaz az Android, egy ugyanolyan SoC procijú másik telón meg viszi az 1080p-t, mert ott a gyártó (pl. Motorola, Samsung, stb.) kipengette a zsarolási sarcot.
Ez nem a szoftverről, meg a Linuxról szól, hanem kő kemény üzlet, stratégia, marketing, jogkezelési keverés. Maga a Linux és Android kiválóan vinné mindegyik ilyen streamszolgáltatást 1080p-ben meg 4K-ban is. De eleve így van lezsírozva, hogy a Microsoft, Apple, prémium androidos gyártók extra pénzt tejeltek, hogy az ő excluzív feature-ök lehessen a FullHD és attól felfelé, és nem akarják, hogy linuxos ingyenjánoska meg énvagyok a programozó típusú Stallman-féle neohippik is gondtalanul tudják élvezni, mikor ők meg nem fizetett érte extra védelmi pénzt. Ez erről szól, maffia az egész stream meg jogkezelés.
Anticheat játékoknál is van fejlődés, ja, de itt számítani kell szívásra. De mint írtam, ez sem a Linuxban vagy Wine-ban lévő technikai korlát, hanem a játék van így szándékosan megcsinálva, tehát pont ez az, hogy olyan jól működik, hogy még azt is felismeri, hogy nem jó platformról fut, és emiatt megtagadja a futást. Ez direkt egy olyan védelmi funkció, ami pont azért tettek bele, hogy még véletlenül se menjen, és ha a kernelesek meg Wine-osok belenyúlnak ebbe, akkor egy ideig mennek ezek a játékok is, míg majd a játékkiadó meg nem unja, kihoz egy újabb frissítést, amibe implementálnak valami másik korlátozó trükköt, hogy ne menjen.
Itt azt kell érteni, hogy nem linuxos inkompetencia miatt nem megy, hanem a játékkiadó nem akarja, hogy Linuxon játssz. Mert azt akarják, hogy Windowson meg konzolon játssz, mert ott mindenféle védelmi meg korlátozó service-t a nyakadba tudnak tenni, amit nem tudsz megkerülni, mert ezek zárt platformok, meg ezekre lett exkluzivitás véve. Félnek, hogy ha Linuxon lehetővé teszik, az egy nyílt, hekkelhető, átlátható rendszer, és megkönnyítik vele a kalózok meg cheaterek dolgát, meg ingyen élvezed azt, amiért más extra pénzt fizetett, mivel a MS, Apple, stb. ezt a védelmi sarcot, amit ők fizettek, beépítette a termék árába, de ha linuxozol, akkor ezt nem fizeted meg, ilyen alapon meg ők gondolják úgy, hogy akkor rohadj meg ingyenélőke, ne használd, szépen szívjál vele.
-
Frawly
veterán
válasz
CPT.Pirk
#30546
üzenetére
Akkor most lehet épp megint működik. Egy hónapja teszteltem, mikor mondtam vissza a Netflixet, akkor nem működött Firefoxban. Lagolt vele a videó, meg csak 480p-ben ment. Ezek szerint javították, de nem marad ám ez sokáig így, mert a Netflix érzékelni fogja a logokban, hogy linuxos gépekről megy tömegesen orrba-szájba az 1080p stream, és megint variálni fognak valamit, hogy ne menjen.
Engem nem is érdekel, visszamondtam a Netflixet. Korlátozzák a kínálatot, korlátozzák a felbontást, elmozgatnak azokból a tartalmakból is, amik korábban legalább elérhetőek voltak az adott régióban. De legjobban akkor rágtam be rájuk, mikor lementett (értsd előre letöltött) videókat próbáltam ingázás közben nézni telón, és behányta rendszeresen az 1043-as hibát, hogy a szolgáltatás nem elérhető. Na, itt döntöttem el, hogy ezért nem fizetek, mert ez így lúzerség, hogy lépten-nyomon megaláznak, meg ügyfélként semmibe vesznek, és én még pénzzel is tömöm a zsebüket, jutalomképpen. Múlt hónapban ezért visszamondtam. Majd előfizetek Amazon Prime-ra, de azt mondják az se jobb. HBO-t utálom, a Hulu meg nem elérhető a UK-ben.
Spotify-t is visszamondtam, azzal az volt a baj, hogy Highest Quality-ben (320 kbps-os Ogg Vorbis) is fosadék volt a minősége (pedig maga az ogg tud jó minőséget, főleg 320 kbps-os bitrátán, rendes encoderrel), mindegy milyen jó hangfelszereléssel vagy melyik eszközről hallgattam, egyszerűen tompa, kásás. Próbáltam normalizálást kikapcsolni, de ez se segített. Így átnyergeltem egyelőre Tidal-ra, rohadt drága, de legalább a minősége normális, desktopon losslessben használom, telefonon 320 kbps-os aac beállítással. Keresője, kliensse, webes felülete épp úgy hulladék, mint a Spotify-nak, meg ahogy nézem, a kínálat is korlátozottabb, de egyelőre kárpótol a minőség.
-
Frawly
veterán
Utránanéztem. De pofátlanság, hogy nézek egy 3 évados sorozatot, a 3. évad közepén járok, erre törlik a 3. évadot, ami nemrég jelent meg. Az 1-2 évad bezzeg fent maradt, csak azt törlik, amit néznék.
A letöltéssel is tisztában vagyok, nem kell kioktatni, kösz szépen. Még 14 nap után se gond, ha egy videó akkor lett letöltve. Ha ez lenne a gond, akkor azt írná, hogy érvénytelen letöltés, lejárt az érvényessége, ezzel nem lenne gond. Itt arról volt szó, hogy 1-2 napja letöltött videókat se engedett megnézni, az 1043-as hibakód akkor szokott lenni, ha túlterhelt a szerverük. Na de ne vicceljenek már, pont azért töltöm le ELŐRE, hogy ne függjön szerverterheltségtől, hanem csak a kulcsot kell validálja akkor, az egy pár KB-os letöltés. És nem nézhetem, amiket MÁRIS előre letöltöttem, és a szerverükön sem okoznék vele nagy többletterhelést. Kösz, de nem. Birkának ne nézzenek.
A HBO-t azért utálom, mert mindig is túlárazott volt, és nem tetszettek soha a sorozataik. Azt nem tudtam, hogy nincs UK-ben, de mindegy is, mert mint írtam, amúgy sem érdekelne. Ezért nyergelek át Amazon Prime-ra. Ami szintén lehet nem a legjobb, de legalább nem a Netflix zsebét tömöm.
Illetve az audiovizális tartalom rendszere: a jogkezelés egy dolog, de az, hogy a jogkezelő azt is eldöntse, hogy FullHD-ben csak Ringyózról tudjam nézni, Linuxról ne, meg egyik androidos telón menjen 1080p-ben, a másikon csak 480p-ben, az már a világ legnagyobb pofátlansága, ne haragudj. Ezt nekem senki nem meséli be, hogy ez így rendjén van. Ugyanannyit fizetek érte, ugyanarról az eszközről nézném, és mégis hátrányosan vagyok megkülönböztetve.
Ezt a fajta szemétséget elvből nem engedem, mert mi jön legközelebb? Eldöntik, hogy csak fejen állva nézhetem, vagy csak akkor, ha még a villanyszámlát is ellenőrizhetően kifizettem? Vagy mit találna még ki?
Nem érdekel, szabjanak meg egy árat, ha kell, legyen magas ár, de akkor korlátlanul nézhessek mindent, regionális korlátozások nélkül, eszközfüggő felbontásfüggetlen feltételek mellett. Ne legyek megkülönböztetve, meg előre eldöntve, hogy ezt csak így, csak úgy nézhetem. Nem érdekel, akkor ne 9 font legyen, legyen 19, vagy 39, de nézhessem, amit akarok. De ezek szerint nem kellett nekik a pénzem, mindent megtettek, hogy ne fizessek elő.
Ugyanerre a sorsra jutott a Spotify is. Ott a szar minőség döntött, hogy vissza kellett mondanom. Kikapcsolt normalizáció mellet is tompa, kásás a minősége, minden eszközön, még jobbfajta DAC-kal is. Előfizettem inkább Tidalra, sokkal drágább, de legalább normális a minősége, tényleg CD minőség.
-
Frawly
veterán
válasz
gelbelex
#30552
üzenetére
Igen, ez a Fast Startup miatt van, az ugyanis egyfajta félhibernációba teszi le a gépet, nem állítja le a szokásos módon, és nem csatolja le a megnyitott fájlrendszereket, de mikor a Linux bootolna, nem tudja rendesen felcsatolni ezeket, és belekever az NTFS fájlrendszer konzisztenciájába. Windows alatt erőszakolj ki egy fájlrendszerellenőrzést, majd ha ez végzett, javította a hibákat, akkor Linux alól töröld a kérdéses mappákat és fájlokat.
-
Frawly
veterán
válasz
gelbelex
#30555
üzenetére
A jövőben arra is figyelj, hogy nagy évszakos Win10 update-ek sunyi módon vissza szokták kapcsolni a Fast Startup-ot, akkor is, ha te korábban kézzel kikapcsoltad. Ezért néha frissítések után rá kell nézni, hogy nincs-e bekapcsolva. Ha még egyszer gond lesz az NTFS kötetekkel, akkor erre kell gyanakodni az első körben.
-
Frawly
veterán
válasz
CPT.Pirk
#30567
üzenetére
Az mindegy, a HP-knak, mivel üzleti gépek, elég jó szokott lenni a linuxos támogatásuk. Mind az Intel GPU, mind a Synaptic touchpad szokott menni probléma nélkül, gyorsgombokkal, fényerőállítással, mindennel együtt. Egyedül Wi-Fi kártya hibádzhat, ha valami nem gyári, spéci modulra lett cserélve. Más gond ezekkel nem szokott lenni. Ha egyik OS alatt sem megy az egér, az hardverprobléma lesz. A Dell-nek meg a Lenovonak is szintén ugyanez igaz az üzleti gépeire, probléma nélkül szokott rajtuk menni bármilyen Linux.
-
Frawly
veterán
válasz
ubyegon2
#30587
üzenetére
Ezzel sose értettem egyet, hogy új gépeket FreeDOS-szal szállítanak. Azzal a felhasználók 99%-a nem tud mit kezdeni, a másik 1% is biztosan lecseréli. Semmiben nem különbözik attól, mintha OS nélkül jött volna a gép.
A gyártóknak valami népszerű disztrót kéne feltenni, pl. Ubuntu, Mint, vagy ami tetszik nekik, benne olyan hasznos dolgokkal, mint GParted, memtest, hőmérséklet-monitorozó és hasonlók. Nem nagy munka, csinálnak az egyikre telepítést, beállítják, majd a lemezképet felhúzzák az összes gépre.
A Linuxot is sokan lecserélik, persze, de azzal azért használható a gép, míg a user nem telepíti fel rá a saját OS-ét, meg a Linux arra is jó, hogy ki lehet próbálni a gépet, billentyűzet, tapipad működik-e, tesztelni lehet a 3D grafikus képességeket, lehet róla böngészni. Így még az is, aki Linux-ellenes és Windows/Hackintosh-fetisiszta, tudná tesztelni a gépet, és nem saját OS telepítése után veszi észre, hogy ez meg az nem működik.
-
Frawly
veterán
Amiért a topikba jöttem, az egy Bash-kérdés. Hogy lehet egy proginak többféle inputot is adni? Mert 1 inputot tudok neki adni, pl. progineve < fájl, a fájlban a bevinni kívánt karakterek. De nekem úgy kéne most, hogy beadagol neki egy ilyen fájlt, ám ha elfogytak a karakterek belőle, akkor a felhasználó is tudjon még billentyűzetről bevinni parancsokat.
A kpcli (KeePass CLI változata) ugyanis nem tud induláskor automatikusan lefutó utasításokat kezelni. Tud nem interaktív módot, fájlból parancsokat beolvasni, de utána kilép, nekem úgy kéne, hogy ne lépjen ki. Ezt úgy akarom kivitelezni, hogy inputként megkapja a fájlt, és a billentyűzetet is. Ha fájl inputtal hívom meg, akkor meg a parancsok elfogyása utána futva marad a program, de nem tudok parancsokat kézzel bevinni.
-
Frawly
veterán
válasz
bambano
#30593
üzenetére
Bocsánat, nem láttam, hogy olyan topik is van. Ez a megoldás nem jó. Ugyanis ezzel ugyan nem csak a fájlban eltárolt és az általam kézzel megadott input kerül be, és UTÁNA indul a program. Nekem úgy kéne, hogy a progi induláskor végrehajta a fájlban lévő parancsokat, aztán visszakerül az irányítás hozzám, de úgy, hogy a program NEM lép ki. Ezt félinteraktív módnak nevezik, a terminálos calc progi pl. tud ilyet a -i kapcsolóval, elindul, a proginak előre átadott inputot végrehajtja, majd ha ezzel végzett, visszaadja a felhasználónak az inputot, hogy további parancsokat vihet be.
Jelenleg viszont ez a kpcli csak annyit tud, hogy végrehajt előre megadott parancsot (már ez önmagában problémás, hogy csak egyet), és utána KÖTELEZŐEN kilép, ami nekem baj, ezt akarom megkerülni. Az is igaz, hogy a megoldás se fog segíteni, mert < fájl inputból meg valami miatt cseszik végrehajtani a parancsokat. De a megoldást továbbra is keresem, mert más CLI/TUI alkalmazásoknál is jól tud jönni.
-
Frawly
veterán
válasz
bambano
#30595
üzenetére
Igen, nem lehetetlen, hogy én értek félre valamit, azért nem értem.
Amit ti írtok, az a megoldás azt csinálja, hogy bekéri az előre rögzített fájlinput mellé az én felhasználói billentyűzetinputomat, de mikor azzal végeztem, csak UTÁNA indítja a programot, és mikor már a progi fut, akkor én már NEM tudok utólag beleszólni, más parancsot is bevinni.
Ami nekem kell megoldás, ott a dolgok SORRENDJE teljesen más. Először indul a progi, aztán hajtja végre automatikusan a fájlinputot, amibe az előre beszögelt utasítások vannak (amolyan autorun jelleggel), majd átadja NEKEM az irányítást, mert előre én sem tudom, hogy mit fogok majd bevinni a billentyűzetről, az annak lesz a függvénye, hogy az előre berögzített input alapján mit ír ki a progi.
Abban valószínű igazad van, hogy át kéne írnom a kpcli-t, hiszen csak valóban csak egy Perl-script, és nekem nem is kéne nagy módosítás, csak annyi, hogy induláskor bevegyen több parancsot is, és azok végrehajtása után ne lépjen ki automatikusan. Magyarán nem sok változást kéne a kódban eszközölnöm.
-
Frawly
veterán
válasz
Jester01
#30596
üzenetére
Akkor én értettem valamit félre, és valóban ez a megoldás, amit keresek. Bár azt még mindig nem értem, hogy a cat parancs, miután átadta a kimenetét a programnak, honnan fogja tudni, mit adagolok be billentyűzetről a program indulása UTÁN. Mert valóban működik, igaz nem a kpcli-vel, de tényleg úgy viselkedik, ahogy mondjátok.
kpcli-vel is csak azért nem működik, mert az mintha kiürítené a bemeneti buffert, gondolom biztonsági okból.
-
Frawly
veterán
Egyszerű, terminálos, szimmetrikus ki/betitkosító megoldást keresek, ami min. AES256 biztonsági szintű, és létezik hozzá Androidon használható biztonságos megoldás is. Lényegében egy jelszavakat tartalmazó titkosított fájl kezelése lenne csak a feladata, nagyon minimalistán. Erre várok ötleteket.
Ki is próbáltam néhány alternatívát, de egyik sem tetszik. A klasszikus gpg2 csomagból a gpg parancs, de ez alapból mindenféle keyring-et akar használni, amit le lehet tiltani, de pl. a grafikus jelszóbekérő ablakát is hekkelni kell, hogy terminálos legyen, és az androidos kezelése sincs megnyugtatóan megoldva. Eléggé túl van bonyolítva.
Aztán kipróbáltam a ccrypt-et. Ez majdnem megfelelő lenne, egyszerű, terminálos, minimalista, 0 függőség, nincs bonyolítva keyringgel és grafikus elemekkel, de Androidon nincs megoldva a kezelése.
Jött az aescrypt. Ez megint nem teljesen jó. Egyszerűségben, minimalizmusban megfelelne, Androidon is van hozzá kulturált app, de egy dolog nagyon nem tetszik benne. Az általa titkosított fájlokba túl feltűnő headert tesz, ami egy esetleges támadónak felhívás keringőre:
AES... CREATED_BY... aescrypt 3... majd csak ezután jön a titkosított bináris tartalomMegoldhatnám 7-zip-pel, ki-betömöríteni fájlt, és Androidon is működésre lehetne bírni, de a kitömörítés nem lenne biztonságos szerintem, igaz ezzel még kísérletezek. Headert ez is alkalmaz, de kikapcsolható, úgy tudom.
Eddig erre a KeePass-t használtam, ez kezelhető terminálból (kpcli), illetve biztonságos androidos app is van hozzá, de a terminálos kezelőfelülete elég gyopár, nehézkesen kezelhető automatizáltan. Igaz, mivel a kpcli Python-alapú, így beszéltük múltkor, hogy belehekkelhetek, amit lehet meg is teszek, de előtte szétnézek, hogy van-e valami egyszerűbb megoldás helyette.
Ott lenne még a VeraCrypt meg a LUKS dm-crypt, de azok nagyon ágyúval verébre megoldás egyetlen fájl minimalista titkosítására. Kicsit már a jelszavazott 7-zip-ezést is overkillnek érzem.
[ Szerkesztve ]
-
Frawly
veterán
Azzal, hogy egy esetleges támadónak segítség, hogy mi van benne. Motiválja a törésre. Ha csak egy bináris fájl lenne, fejléc nélkül, akkor még az se lenne biztos, hogy micsoda ez a fájl, egy szoftverhez tartozó adat, vagy fájltöredék, vagy mi. Így reklámozva van, hogy hülye vagyok, üssetek, gyertek, mindenki, fontos dolgot titkolok, hekkeljetek.
A gpg-vel mint írtam, két gond van. Ha ezt lefuttatod, akkor feldob egy GRAFIKUS jelszókérő ablakot. Ezt ugyan át lehet hekkelni ncurses pinentry agent megoldásra, de megint felesleges bonyolítás, és az Androidon való kititkosítás sem megoldott biztonságos formában, azaz egy validált, auditált app a memóriába bontaná ki, ahonnan azonnal eltüntethető lenne, nem hagyva maga mögött a fájlrendszeren nyomot.
Ezt az openssl-t meg is próbálnám, de így, hogy írod, hogy valami komolytalan, PDF-es megoldás, így az élből nem játszik, meg szerintem androidos, kulturált megoldás nincs rá.
Mondom, bonyásan meg tudom oldani ezt, de én minimalista, terminálos megoldást keresek, jelszóelfelejtés esetére, amibe beverek egy mesterjelszót, terminálkimenetben kiköpi a webes jelszólistát, megnézem, bezárom, és ugyanez Androidon is kivitelezhető legyen, igaz ott nem kell terminálosnak lenni, de legyen rá valami kulturált, ingyenes, reklámmentes app, ami vagy csak simán biztonságos, vagy auditált. Vagy-vagy.
Így lehet az lesz, hogy vagy a kpcli forráskódjába nyúlok bele, hogy jó legyen, vagy fejlesztek ehhez valami ultraminimalista saját megoldást, ami tényleg csak olyan szinten AES256-oz végig egy plain text fájlt, amit Androidon a cryptol app meg tud nyitni. Mert nekem nem kell bonyolítás, nem kell grafikus felület, nem kell random kulcsgenerálás, nem kell adatbázisba szervezés, nem kell limitált ideig vágólapkezelés, nem kell online szinkronizáció, és egyéb bonyolítás.
[ Szerkesztve ]
-
Frawly
veterán
Kösz szépen, ezekre rá fogok nézni. Tudtam, hogy rád számíthatok.
A többieknek szép sorban: tudom, kicsit nehéz, hogy spéci igényeim vannak. Azért a haladó topikban kérdeztem. Ha csak az kéne hogy letitkosítsak valamit valahogy, arra van már több multiplatform megoldásom is.
A Java, meg igen, bloat. Headert meg lehetőleg nem akarok, akkor se, ha az AES törhetetlen gyakorlatilag.
Ez a PDF viszont így másodszor belegondolva nem tűnik hülyeségnek! Először nem tetszett az ötlet, de most, hogy belegondolok, a PDF formátum is támogat AES titkosítást, és a PDF-et minden platformon megnyitja egy valamilyen tetszőleges pdf olvasó, nem kell hozzá spéci app meg szoftver. Igaz nem plain text megoldás, de végül is nem is annyira bloat, Zathurával terminálból meg tudom nyitni, nem egy nagy tétel. Szóval ki fogom próbálni, meg megköszönném emvynek is az ötletet, meg hogy foglalkozott a problémával. Még ha ebben a formában, amiben ő írta nem is jön be, de ötlet formájában hasznosulhat ez a megközelítés, és egyszerűbb és időkímélőbb lehet, mint nekem forráskódokba belenyúlkálni. Persze nem tökéletes megoldás, mert headerje meg figyelemfelhívó jellege van a tiktosított pdf-nek is, de a módszer egyszerűsége csábító.
[ Szerkesztve ]
-
Frawly
veterán
válasz
I02S3F
#30642
üzenetére
Azért, mert ha elhagyom vagy ellopják a telót, akkor azon nincs a háttértár titkosítva. A teló le van zárva, de az meg törhető.
Természetesen ha csak a linuxos gépemre kéne, akkor még egy tiktosítatlan plain text file is megfelelne, mert a háttértáram titkosítva van, rendszer jelszóval védve, lezárva hagyva, más nem fér hozzá, nem tud belematatni, még akkor se megy vele semmire, ha kiszedi belőle az SSD-t, és átrakja másik gépbe.
Itt most arról van szó, hogy a Keepass-nál egyszerűbb megoldások után nézek, mielőtt fölöslegesen feltalálom a kereket, és belenyúlok a kpcli kódjába. De még a gpg-s, vagy opengpg-s megoldás is játszhat, ha kulturáltabb formában meg tudom oldani túl nagy hekkelés nélkül. Itt most csak lényegében lustaságból próbálok plusz munkát megúszni, hátha lehet alapon.
-
Frawly
veterán
Ez meglepett, ezzel a rövidítéssel nem találkoztam, meg kell mondjam. Természetesen utána fogok nézni, mert én a dokumentumformátumra gondoltam nagy hirtelen, de nem baj, adtál vele ötletet, ne röhögjetek. Ne feledjétek, hogy nem NSA szintű titkosításra van szükségem, egy Keepass szintű átlag megoldás elég, csak legyen egyszerűbb. Nem követelmény a katonai fokozatú biztonság. Android eleve biztonsági szinten totál komolytalan, Google nem megbízható, tele a boltjuk ellenőrizetlen fingóappal, amiknél a zárt forráskód miatt meg se tudsz róla győződni, hogy megbízható-e. Szóval ha Android, akkor a biztonság örvénylik lefelé a klozetban. Itt csak arról van szó, hogy telón ne ilyen titkosítatlan formában legyen ott.
Mert még ha tényleg megbízható megoldással is csinálom, pl. 7-zip-ről biztosan tudom, hogy megbízható, de azon kívül, hogy arra overkill, amire én akarom, az vele a baj, hogy nem tudni, hogy a telefonos 7-zip app hogy kezeli le, hová bontja ki a titkosítatlan fájlt, az hol, meddig marad látható, SD kártyára, belső tárolóra kerül-e, vagy memóriában tartja, teljesen lutri az egész. Mert a hajamra kenhetem az AES256-t, ha az app bénán van megírva, kibontja egy nem illékony fájlrendszerre temp fájlként az épp kititkosított cuccot, és onnantól az egésznek nincs értelme, lazán támadható az egész egy kis leleményességgel, nem kell semmilyen bruteforce hozzá.
-
Frawly
veterán
Eléggé meg leszel szivatva, csak úgy mondom. Nem is konkrétan a appod miatt, hanem ha új feltöltőként csatlakozol a store-jukban, akkor mindenféle regisztrációs díj, meg igazolás, meg lófütyi van állítólag. Én még nem csináltam, de aki ezzel foglalkozik, az azt mondja, hogy állati szopás. Persze ha az appod is olyan, hogy beleesik egy szűrőbe, amiatt is megszivathatnak extrán.
-
Frawly
veterán
válasz
vargalex
#30665
üzenetére
Nem tudom, nálam Archon a /proc/cpuinfo-ban is az aktuális órajelet mutatja, szálanként eltérően, külön. Most egy gyors grep /proc/cpuinfo nálam ezt mutatja egy 2,5 GHz-es i5-2520M-en, ami gyárilag 3,2 GHz-re boostol:
cpu MHz : 1292.870
cpu MHz : 1610.595
cpu MHz : 1367.475
cpu MHz : 2015.892Pillanatról pillanatra ingadozik, 800-3198 MHz között bármi előfordul, az aktuális magok, szálak terhelésének függvényében.
Új hozzászólás Aktív témák
- Milyen légkondit a lakásba?
- Politika
- A nagy Szóda, Szódakészítés topic - legyen egy kis fröccs is! :-)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- LEGO klub
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- E-book olvasók
- Diablo IV
- Samsung Galaxy A52 - royal cuvée
- XGS24 - Gameplay előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
- További aktív témák...
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Eladó Steam kulcsok kedvező áron!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen