TCH (statz) | #1, Főfasz (10479) |
777 | #5950 | ^ | Idézet | Tue, 24 Dec 2024 13:59:48 +01 |
188.143.*.* | *.pool.digikabel.hu |
És így rögtön kidobnád a platformok egy jelentős részét, ahol vagy Qt6, vagy Python3 nincs. :( Ha már kinyitod a forrást és újraírod a programot úgy, hogy modularizálni akarsz (ami egyébként szerintem jó ötlet), akkor IMHO jobb lenne, ha a jelenlegi felállás (van egy standalone GUI bináris, meg van egy külön DLL, ha valaki programból akarná használni) helyett úgy állna össze, hogy van a library, amit bárki használhat, meg van az arra támaszkodó CLI bináris és van akármennyi C++-os GUI-s alkalmazás (Qt4, Qt5, akár Qt6 alá is, de lehet GTK-khoz is), amik szintén a library-ra támaszkodnak. És akkor a library-t, meg a CLI programot már célszerű lenne nem is C++-ban, hanem C-ben megírni, hogy azok aztán tényleg hordozhatóak legyenek bárhová. De ez csak az én véleményem. |
kemi (statz) | #2, Főfasz (2980) |
416 | #5951 | ^ | Idézet | Tue, 24 Dec 2024 19:44:37 +01 |
134.255.*.* | *.dsl.pool.telekom.hu |
Már sehol nincs Python2. Igazából megoldható, hogy magát a titkosítást megoldani egy .so-ban (shared object, ami *nix-en a DLL), ahhoz írni egy C(++) headert, és egy Python modult. Onnantól kezdve akár a CLI és a GUI progam is mehet Pythonban, mert a nehéz munkát a C++ program végzi. |
TCH (statz) | #1, Főfasz (10479) |
1011 | #5952 | ^ | Idézet | Tue, 24 Dec 2024 20:31:22 +01 |
188.143.*.* | *.pool.digikabel.hu |
De, a régebbi platformokon. Nálam pl. van. Igaz, Python3 is van. Hát, ha mindenáron Pythonban akarod megírni, akkor igen, bár szerintem a CLI program nem ártana, ha portolható lenne, de te tudod. Viszont, ha crossplatform lesz, akkor tudod, hogy a véletlenszámgenerálást is meg kell oldanod? Mert különben amit eltitkosítottál vindóz alatt, azt nem fogod tudni visszatitkosítani Linux, vagy épp OSX alatt és vice versa. Ha elfogadod, itt az én generátorom, amit még anno kimértem, hogy jobb mint a glibc-é. |
TCH (statz) | #1, Főfasz (10479) |
119 | #5953 | ^ | Idézet | Wed, 25 Dec 2024 00:44:47 +01 |
188.143.*.* | *.pool.digikabel.hu |
Most néztem egyébként a LinkedInen, hogy szegény miklos_akos is leépítésre került a Sophosnál év elején... Ő se mondta. |
kemi (statz) | #2, Főfasz (2980) |
186 | #5954 | ^ | Idézet | Wed, 25 Dec 2024 20:06:43 +01 |
134.255.*.* | *.dsl.pool.telekom.hu |
Már akkor amikor odakerültem elég nagy pénzügyi gebasz volt a cégnél. Októberben elvileg bezárták az irodát is, akkor azt mondták, full home office-ra áll át a cég. Sok embert elküldtek. |
TCH (statz) | #1, Főfasz (10479) |
753 | #5955 | ^ | Idézet | Wed, 25 Dec 2024 22:37:52 +01 |
178.164.*.* | *.pool.digikabel.hu |
Valószínűleg fejlesztések helyett hülyeségekre - pl.: céges kocsikra, partikra és mítingekre - ment el a pénz és az idő, a programozókat meg nem hagyták dolgozni, mert fontosabb volt a mítingeken való biciklitárolózás (valamivel meg kell indokolnia a vezetés felé a sok léhűtő HR-esnek, meg managernek, hogy miért is kapják a fizetésüket), aztán persze, amikor beüt a krach és leépítés lesz, akkor véletlenül sem a HR-eseket, meg a managereket küldik el, hanem a műszaki manusokat, hiszen úgysem dolgoznak, nem? :( Mindegy, mondom: ez se tart már sokáig, mert összedől az ipar. Azt a pár évet még csak kihúzzuk valahogy. :P |
kemi (statz) | #2, Főfasz (2980) |
622 | #5956 | ^ | Idézet | Wed, 01 Jan 2025 01:37:59 +01 |
134.255.*.* | *.dsl.pool.telekom.hu |
Hát nagyjából kész vagyok az RC újradolgozásával. C++ CLI+lib, és Python3+Qt6 GUI lett. Azért választottam mert a GUI nem kritikus része a dolognak, tehát nyugodtan lehet egy magasabb szintű nyelven írni, így sokkal kezelhetőbb a kód. Na, és a C++-t meg a Pythont még a kenyérpirító is lefordítja, szóval a cross platformsággal se lesz gond. Amúgy be lehet az egészet csomagolni egy Flatpak vagy AppImage csomagba az összes dependenciájával együtt, így nem gond olyan rendszereken ahol nincs Python3 vagy Qt6. A régi céges laptopomból csináltam egy hackintosht, úgyhogy most már macOS-en is le tudom tesztelni. Amúgy BÚÉK. |
TCH (statz) | #1, Főfasz (10479) |
1780 | #5957 | ^ | Idézet | Wed, 01 Jan 2025 04:24:19 +01 |
188.143.*.* | *.pool.digikabel.hu |
C++ compiler még csak-csak lesz kenyérpirítóra is, de Python3 intepreter is? Az azért messze nincs mindenütt. Qt5 verziót tuti nem akarsz csinálni? A Qt6 szerintem még huszadannyira sincs elterjedve, mint a Qt5. (És tekintve, hogy megváltoztatták a license-elését, lehet, hogy ez még sokáig így is lesz.) És így lesz a pár kB-os RC-ből sok MB, hogy mellé van csomagolva egy Python3 interpreter is, meg egy raklap Python3 library is. :( Arról nem is beszélve, hogy így mindjárt Flatpak vagy AppImage is kell hozzá... BTW, hogy rakod mellé a Python interpretert, mint függőséget? Forrásként? Annak a forgatása triviális lesz mindenki számára? Csak, mert ha külön tutorialokat, meg install script generátorokat (!) kell írkálni a felhasználók számára, hogy le tudják fordítani a Python3-at, akkor alig hinném, hogy ezt mindenki meg tudja majd ugrani... Vagy binárisként és akkor lesz [vindóz,macOS,Linux,FreeBSD,OpenBSD,NetBSD,Solaris,etc.] / [x86,x86_64,ARM,ARM64,POWER,POWER64,SPARC64,MIPS,RISC-V,etc.] verzió a csomagból, azaz lesz kb. (most hasamra ütök) 30 csomag? (Nyilván nincs minden OS minden CPU-ra, de érted.) Vagy egy csomag lesz, benne 30 féle Python3 binárissal? Szóval, - szerintem - ez a függőségek mellécsomagolása, ez nem a legjobb ötlet. A lábgörcs BUJJÉK bilgéc nyakába. :P |
TCH (statz) | #1, Főfasz (10479) |
1919 | #5958 | ^ | Idézet | Thu, 02 Jan 2025 00:56:22 +01 |
188.143.*.* | *.pool.digikabel.hu |
kemi, nézem az RC2.DLL forrását és benne a tábla generálását:Procedure Gen_Table(KeyVal: Int64); var i: Integer; k: Cardinal; gb: Byte; bTable: Array[0..255] of Boolean; Begin For i := 0 To 255 Do bTable[i] := False; RandSeed := Random(KeyVal); i := 0; Repeat k := Random($FFFFFFFF); gb := k And 255; If NOT bTable[gb] Then Begin bTable[gb] := True; _table[i] := gb; Inc(i); End; Until i > 255; End;Ezt így emelted át az RC3-ba, hogy véletlenszerűen generálja az indexeket és nézi, hogy az az index volt-e már generálva és ha igen, akkor generál másikat? Mert szerintem ez nagyon nem jó így. (Persze jobban tenném, ha csöndben maradnék, mert ez az én saram...de már 21 éve követtem el; még fiatal voltam és kellett a pénz pillanatnyilag jó ötletnek látszott. :P Ja igen, tévedtem: a 2.00-ás verziót is én írtam még meg eredetileg Delphiben (meg is találtam most a forrkódot), de te csináltál belőle C++/Qt5 portot.) Szóval, ez baromi lassan generálódik így le; IMHO jobb lenne, ha ehelyett lenne egy 256 elemű tömb, amiben szépen sorban szerepelnek a számok 0-tól 255-ig és utána csak simán cserélgetve keverné össze őket az algoritmus: int i; uint8_t ri, tmp; for (i = 0; i < 256; ++i) { ri = rng_fuggveny() & 0xff; tmp = table[i]; table[i] = table[ri]; table[ri] = tmp; }Ez sokkal gyorsabb lenne és a hatékonyság szempontjából mindegy, hogy hogy van kialakítva a véletlenszerű sorrend a replacer táblában. Mit szólsz? Ja, másik kérdés: thread-safe módon csináltad meg, azaz a táblát is beleraktad egy struct-ba, vagy class-ba? Csak mert az eredetiben én sajnos globális változót használtam, ami nem thread-safe, hiszen mindenki ugyanazt a táblát piszkálná... |
TCH (statz) | #1, Főfasz (10479) |
1870 | #5959 | ^ | Idézet | Thu, 02 Jan 2025 02:25:51 +01 |
188.143.*.* | *.pool.digikabel.hu |
Na, gyorsan át is írtam az RC2-őt C-be; itt az RC3 C változatának egyelőre alfája: http://oscomp.hu/depot/rc3.c Ezt most direkt backward compatibility-vel csináltam meg, azaz benne van az RC2 (és RC1) táblagenerátora is, meg ez a sima cserélgetős is és lehet választani. Fogtam egy ~4.3 MB-os fájlt, amiben az a sor van 65536x ismételve, hogy Egy kicsi kecske felment a hegyre. Le nem jött, mert döglött ló.A teszt abból állt, hogy 16 byte-os ablakmérettel (azaz 16 byte-onként generálta újra a táblát) eltitkosította mode1-gyel, majd vissza mode2-vel, aztán eltitkosította mode2-vel, majd vissza mode1-gyel és természetesen mind a négy buffert kimentette. És ezt eljátszottam mindkét táblagenerálási eljárással. Az eredmény: 2.448s volt az egyszer végigmenős és véletlenszerűen cserélgetős és 11.695s volt a régi, kizárósan-generált feltöltős. 4.77737-szer lassabb a régi. És az eltitkosított fájlok ugyanolyan katyvaszok voltak; nincs hatásfokban különbség. És ha levettem az ablakot 1 byte-ra, akkor 25.941s volt az új és 171.474s a régi. 6.61015-szörös különbség. Szerintem nem éri meg a régivel nyűglődni. (A véletlenszámok generálását a már linkelt - szintén threadsafe és crossplatform - véletlenszámgenerátorommal csináltam; ez nem eldöntött, hogy ezzel lesz-e, de még nem mondtad, hogy a véletlenszámokat hogyan akarod generálni; az OS-ek libc-jének beépített véletlenszámgenerátora csak ugyanazon OS/libc kombón fogja ugyanarra a seedre ugyanazt az eredményt adni: nem lesz hordozható a végeredmény. Még Linuxról-Linuxra sem, ha az egyiken glibc van, a másikon meg mondjuk musl. Akkor IMHO, már jobban járunk a psrand-dal; a glibc generátoránál jobb... :P) |
Lia Sana (statz) | #?, Szarfasz (?) |
61 | #595a | ^ | Idézet | Mon, 13 Jan 2025 17:20:21 +01 |
176.100.*.* | *.pautina.ua |
Kaszinós duplapost-spam, deleted. - TCH |