ezt a kódek nevű betegséget még a fehér kalapos hacker előtt ki kellene irtani, rögtön az abu-dzabi után.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Javaslat?

<!-- Hello tourist on the right side, hello tourist on the left side -->

Azért ez nem egy rossz dolog. Reméljük ekkora nevekkel mögötte lesz is belőle valami.

[ Szerkesztve ]

A HEVC jogdíjas ám?

"Ezért lovagol a pokolba a konzumer IT piac. A hülye igények... . Azt sem tudod, hogy mit akarsz de az jöjjon havonta frissités formájában."

Igen (link)

<!-- Hello tourist on the right side, hello tourist on the left side -->

Reméljük be is fogják tartani az elvárásaikat... Na meg hogy minél hamarabb lesz is belőle valami kézzelfogható...

és a webm(vp8,9)?

Nyilvan nincs csak irni kellett valami nagyot

Ikea Tafjord, Kínai indukciós töltő, Victorinox Traveler, 10 Tojás M (3 már hiányzik),Rádiós ébresztőóra piros kijelzővel, Varta akkutöltő

kodek.
olyan rövidítés, ami a magyar kódoló-dekódoló vonalon jött volna létre, nem terjedt el, mert kó nincs, akkor pedig kóddeknek kellene írni.
tehát az angol codecet fogadjuk el kicsit magyarosított jövevényszónak, és így legyen belőle kodek.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Miért, kik ezek? Sose hallottam róluk...

miután a gugli megcsinálta őket (vp8-9) utánna lebegtette be pár cég hogy bizonyos szabadalmakat sért és akkor a gugli fizetett nekik, és így nekünk végfelhasználókak már ingyenes a de a guglinak nem volt az

ezek most tejesen saját kútfőből akarják csinálni, de elég nehéz lesz minden szabadalmi dolgot kikerülniük

[ Szerkesztve ]

"Az internet olyan, mint az MTV: annak idején az MTV nagyon trendi volt, aztán hirtelen elavult” - Prince

+1

én is utálom a kóóódeket, pedig ugornyi paraszt vagyok!

हरे कृष्ण हरे कृष्ण कृष्ण कृष्ण हरे हरे हरे राम हरे राम राम राम हरे हरे Góranga!

Az nem fizetős, viszont lassú.
#9: meggyőztél, rövidítettem.

<!-- Hello tourist on the right side, hello tourist on the left side -->

En mar a lajknal feladtam es figyelmen kivul hagyom az ilyeneket.

Ikea Tafjord, Kínai indukciós töltő, Victorinox Traveler, 10 Tojás M (3 már hiányzik),Rádiós ébresztőóra piros kijelzővel, Varta akkutöltő

Mi a gond az Xvid-del? még a kenyérpirítóval is kompatibilis, és jól skálázható..világszinten elterjedt...és nincs gépigénye.... Jaaaaa hogy akkor nem lehetne elnyomni egy halom felesleges új eszközt?

[ Szerkesztve ]

Elavult, pl. a h.264 ugyanakkora méret mellett jobb minőségre képes

“If you don't read the newspaper, you're uninformed. If you read the newspaper, you're mis-informed.”

Illetve azonos képminőség mellett kb. fele méretet eredményez. - ez talán szemléletesebb.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Tehát akkor ez az új csapat a H.265 (HEVC) utódján dolgozik? Esetleg egy alternatív, de nagyon hasonló hatékonyságú kodeken?

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

Legyen webre optimalizált
Alacsony számítási igénnyel
legjobb minőségű
Szóval legyen jó tömör, jó gyors és jó minőségű. Álmodik a nyomor...

Skálázható az összes modern eszközre és sávszélességre
Alacsony számítási igénnyel és hardveres optimalizációval rendelkezzen

Na most melyik.. mert nekem az elsőből az jön le, hogy továbbra is b*szhatod a P4 és Centrino M éra gépeit (amit még nagyon sokan használnak, és hát akarnak rajta webezni is, sőtmitöbb: videót nézni online).
Az alacsony számítási igény (ha nem tesszük oda zárójelben, hogy "modern" eszközön) azért ad némi reményt. Hardveres optimizáció megint egy olyan hogy most ez lehet jó is meg rossz is.

''Milliárdnyi meggyilkolt csillag sikolya elhal az éj békéjében, és a kétségbeesésnek csak néhány, törékeny, kőbevésett szó áll ellen.''

Ez a próbálkozás csak egy ponton fog elbukni. Nyílt forráskódon nehezen, illetőleg hosszú ideig nem törhető titkosítást csinálni katasztrofálisan nehéz lesz mert ez lesz az első amit a kalózhackerek támadni fognak. De sok sikert nekik, ebből mindenki csak jól jöhet ki ha megvalósul.

te is nap mint nap töröd a pgp-t?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az nem úgy megy ám, hogy akkor most két nap alatt összedobják a cuccot...

Már csak azért sem, mert rengeteg szabadalom közt kell lavírozni. A dct alapú codec -eket gyakorlatilag már körbe bástyázták, és jelenleg ez a leghatékonyabb megoldás. Mondjuk a vp9 -el sikerült olyan képfelbontási eljárást kidolgozni, ami úgy működik mint a h265, nem ütközik azokba a szabványokba...

Viszont, vélhetően ezek a nagy cégek most nem ilyet akarnak. A hatékonyságot muszáj nekik a h265, és vp9 -el minimum megegyező mértékűre emelni, vagy túl is szárnyalni azt...

Mire ezt megcsinálják, az 5 - 6 év... Ha a gugli bedobja a közösbe a vp tanulságait, még akkor is... Igazság szerint a vp9 sem lett túl nagy eresztés, mert még egy olyan ótvar lassú encodert, mint a libvpx, nem találsz a piacon.... Évek alatt sem tudtak írni hozzá egy normálisat. És ha ki is várod az időt, akkor is egy széttaknyolt videó lesz az eredmény. (bár... az x265 sincs még abban az állapotban, amiben kellene neki, de az legalább sokkal gyorsabb...)

Egyébként igazán jó ötlet... az audió codec -ek piacán már megcsinálták, amit meg kellett.. Alacsony bitrate mellett az opus igazán jó darab. Most végre a videóval is komolyabban foglalkoznak.

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

A dct alapú codec -ek mentén valóban...
De lehet, hogy ők majd más irányban okoskodnak... voltak egyéb ötletelések, az mpeg féle megoldáson túl...

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Az xvid, egy korábbi mpeg szabvány, részmegvalósítása, vagyis azon technológiák segítségével működő, pc -s codec. Sosem volt szabványos, de a nagy gyártók rácuppantak, és végül már mindenki támogatta. A divx meg a fene tudja, hogy maradt életben az üzletpolitikájával...

Viszont, ma már szinte értelmetlen használni, mert a codec -et egy szálra tervezték, és sosem fogják már átírni. Így lehet az, hogy egy átlagos 4 magos cpu -n, az x264, a komplikáltabb kódolási eljárás ellenére is, gyorsabb tud lenni, az eredmény minősége pedig, a h264 szabványnak megfelelő, és elég jó minőségű. Mivel szabványos lesz, ezért az ég világon minden lejátssza, pár régebbi dvd lejátszón kívül. Még a telefonokon is hardware -es decoder van, így nem zabálja az aksit...

Jelen pillanatban, a h264 a leghasználhatóbb formátum.

A videó tömörítés azonban mindig is a sávszél, és tárhely igényről szólt... és ha ezeket le lehet szorítani, akár 10x -es számítási kapacitásért cserébe, akkor meg is fogják tenni, mert megéri.... Ezért jött létre a h265 szabvány, és a vp9 codec is....

Ez pedig, végső soron mindenkinek csak jó... És újabb bizonyíték is egyben, hogy az opensource jól működő fejlesztési forma, a software -ek világában, amit mindenki tévesen, pár hobbi programozó játékszerének szokott gondolni...

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Tudod... a jó titkosító eljárás az, ahol nem maga az eljárás a "titok"...

A kriptográfia egyik alapszabálya. Egy gpg kódját hiába böngészed át, attól még a megfelelő kulcsok nélkül igen nehéz dolgod lesz, ha lopsz tőlem egy titkosított email -t.

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Nem azt mondtam hogy lehetetlen sem azt hogy jobb ha kód titkos. Csupán annyit hogy a megvalósítás nehézségi szintje látványosan magasabb nyílt forráskód esetén. (Mert nem lehet elbújni a kód titkossága mögé egy silányabb minőségűvel arra bazírozva, hogy úgysem fejtik meg csak az adatfolyamból, hanem kénytelenek rendesen megírni). És egyet értek a kód minősége annál jobb minél több ember auditálja. Mind a mai napig a legjobb kriptográfiai programnak tartom a Truecrypt utolsó előtti változatát.

Az elvárások nagyon jók. Most már csak be kell tartani őket. Meglátjuk, hogy sikerül.

[ Szerkesztve ]

Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.

Mi az, hogy átlagos négy magos cpu? Az nagyon nem átlagos...nagyon sok ember még pentiumon1-es, p2-esen, vagy dual core procis gépet hajt otthon! (esetleg core2duo-t) Így azon cs.szheted az h265-öt (meg az h264-et is bizonyos esetekben), el sem indul a legtöbb esetben az illegális film lejátszása. Főleg nem 720p, vagy afelett.

Viszont az Xvid-et egy 233-as proci is megeszi, lényegében minden támogatja. Én itthon a házi videóimat próbáltam mindennel VHS-ről... h265 (264-t is), és társai siralmas kompatibilitást mutattak amikor arra próbáltam váltani és újrakódolni a videókat VHS-ről ilyen formátummal, nagyon sok tv nem játszotta le őket USB-ről a családban, asztali lejátszók sem, a telefonokon sem remekelt.. viszont az XviD ment mindennel. És nem tartom magam balf.sznak, lényegében '97-óta kódolok házi videókat szóval végigjártam a VCD korszaktól mindent és minden buktatót, tehát nem arról van szó, hogy rosszul állítom be a kódoló programot.

Amióta felbomlottak az íratlan méretbeli szabványok értsd cd méret, két cd-nyi méret stb.. azóta méretről beszélni felesleges szerintem. Az adattárolás dinoszauruszai, mint én foglalkoznak még ilyennel, hiszen én mindent duplán DVD-re mentek winyó mellett... A házi videókat csak így tárolom. (sőt mind a mai napig 8 karakternél hosszabb fájlneveket sem alkalmazok! Soha nem lehet tudni! Meg "old habits die hard", a 80-as évek végén-90-es elején a pc korszakban megszokta az ember, úgy tanulta meg )

A gond az új formátummal az erőforrásigényben van. Ha csak nagyon erős gépekre lesz elérhető, akkor jelentős réteget zár ki a használatból - ergo a terjedés lassul. Persze itt jön be az illegális tolvaj oldalak szerepe a lopott filmekkel - magyarul torrent, hiszen megfelelő (illegális) anyagi ösztönzéssel a nagy cégek elérhetik, hogy ne fogadjanak be pl XviD állományokat, vagy más formátumokat, de az új formátumot igen, ezzel is növelve a terjedést... lássuk be ez így működik. Ha a vezető - világszintű és lokális helyi - oldalakat erre a cégek ráveszik, akkor a terjedés felgyorsulhat. - és vissza is üthet, mert megjelennek a downkódolt filmek a kisebb oldalakon pl Xvidben... így azok erősödnek, ezzel növelve a kalóz másolatok terjedését!

[ Szerkesztve ]

Mert nem lehet elbújni a kód titkossága mögé

Éppen ez az, hogy nem is kell... Egy jól kitalált titkosítási eljárás esetén, teljesen mindegy, hogy te ismered -e a módszert, vagy sem. SŐT... mivel nem lehet maga az eljárás a megfejtés kulcsa (cézár kódtól azért már messze vagyunk... ) ezért minél többen látják azt, annál többen lesznek képesek megtalálni benne az esetleges problémás részeket. Az aes -t is ismerheted, ha akarod... na és? Küldök egy állományt, és törd fel nekem... a titkosító program forráskódjával együtt megkaphatod... na? Vállalod?

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Kvantum számítógéppel ripsz-ropsz feltörhető. Csak még nincs ami rendesen működne.

Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.

Az átlagos 4 magos cpu, az azt jelenti, hogy a 4 magos cpu -k bármelyike.
Hidd el nekem, egy core2quad -on, ami egy 2007 -es eresztés, azon is gyorsabb az x264 encoder, mint az xvid. Egyszerűen azért, mert 4 szálra képes bontani a feladatot, jó hatékonysággal, míg az xvid nem.
Ezt írtam fentebb, hogy hiába komplexebb h264 -et kódolni, mégis nagyobb sebességet érsz el, egy minimum négy magos, 8 évesnél nem régebbi cpu -val.

Ma pedig, amikor már a létező leggagyibb mobil biztbaszok, és az összes létező vga, az 5000 ft -ostól kezdve, 5 - 10 éve rendelkezik hardware -es decoder -el, nem hinném hogy bárkinek is gond lenne a h264 lejátszása.

Akinek meg p1 233 -asa van, az nyilván nem is nagyon akar videót kódolni, semmilyent sem... Ha meg nézni akar, akkor meg a telefonjával is jobban jár, mint a p1 -el... tesco gazdaságos 40 ropis pc -t is vehet, és azon is tud majd h264 -et nézni, mert már jó ideje a procik mellé pakolt vga -k is tudják hardware -ből ezt a formátumot. De a tesco pc még software -ből is elég lenne a feladatra, a 8000 ft -os pentium cpu -val...

Szóval nem értem hogy mi a gondod pontosan. A hardware -es decoder -ek miatt, gyakorlatilag kevesebb lesz a terhelés, mint ha xvid -et néznél...

A h265 ideje még valóban nem jött el, és egyelőre csak skylake -el, vagy gtx 960/50 -el lehet gyorsítani a lejátszást, de 720p -ig még software -ből is le tudod játszani akármelyik pc -vel, ami (mint fentebb is írtam) nem régebbi 8 évnél.

Az x265 -el csak az a gond, hogy 10x nagyobb számítási kapacitás kell neki (nem lejátszásról van szó, encoder -ről... ), mint az x264 -nek, mert a h265 -ös szabvány sokkal komplexebb... és cserébe kb 40% -ot kapsz méretben, de ez is erősen felbontás függő. Bizonyos szint fölött pedig egyelőre a végletekig csiszolt x264 jobb eredményt produkál.....

[ Szerkesztve ]

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Majd ha lesz, akkor elavulttá válik ez a cucc is... majd kitalálnak valami mást helyette... Van elég őrült matematikus a világon...

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

Már kitaláltak, csak kell hozzá egy kvantumszámítógép. A Kvantum titkosítás. kvantum titkosítás

Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.

Haladni kell a korral! Mire ebbôl lesz valami, egy Atom IGP-je is 500 GFLOPS körül lesz ( +2 generáció ), és a 4 vagy több mag is 3 GHz felett járhat. Ez lesz a kis teljesítmény, amit majd az új kodek igényel.

Xvid-et felejtsük már el!
Igazából itt arra megy ki a játék, hogy a fizetős tartalmakat hogyan titkosítsák.
Nem kellene itt új codec, a h265 még el sem terjedt.

"Viszont az Xvid-et egy 233-as proci is megeszi, lényegében minden támogatja. Én itthon a házi videóimat próbáltam mindennel VHS-ről...": hát ja, az ócska félsd 325 soros vhs forrásodat valószínűleg tényleg jobban eszi az xvid.

próbáltad már egy rendes, 1080p-s anyaggal ugyanezt?

az emberek többsége nem akar encode-olni, tehát a kódolás erőforrásigénye senkit nem zár ki semmiből (vagyis csak pár embert). a dekódolás meg már a málnán is hardverből megy, és mindenki boldog, pedig az aztán egy gyenge cucc.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nekem is volt egy csomó ilyen felvételem, meg csak SD-ben létező filmem. Rászántam egy kis időt, mindet átkódoltam x264-be, így jó pár giga tárhelyet nyertem azonos képminőség mellett.

Kaeraman77-et nem igazán értem. Ma már az a ciki, ha valami nem játszik x264-es mkv-t. Hála az égnek az nCore-on is kitiltották az xvidet.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Ez kezd fárasztó lenni hogy kibogozzam mit is szeretnél mondani ezért engedd meg kérlek hogy leegyszerűsítsem...

Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". Egyetért / Nemért egyet

"Az aes -t is ismerheted, ha akarod... na és? Küldök egy állományt, és törd fel nekem... a titkosító program forráskódjával együtt megkaphatod... na? Vállalod?"

Komolyan srácok mi ez a személyeskedési hullám??? Először is az AES egy remek megoldás amikor a saját gépeden egy állományt akarsz titkosítani mert ott minden kulcs lokális. Nehezen törhető, mivel minimálisan is 128 bites kulcs titkosít! De nem is igazán arra van kitalálva hogy egy online streaming szolgáltatásnál több szereplő (peer) esetén alkalmazni lehessen. Minden kriptográfiai eljárásnak az növeli leginkább a megvalósítási nehézségét minél több peer között kell hogy mozogjon az adat, és az csak hab a tortán hogy a kézfogás online valósul meg.

De ha ez még nem lenne elég fejfájás. Akkor ott van a másik probléma amiről még nem beszéltünk (mert őszintén nem hittem hogy kelleni fog). Minél biztonságosabb titkosítást akarnak megvalósítani azzal arányosan nőni fog a szükséges számítási igény is! Ezért egy külön tortúra lesz annak a kibalanszozása hogy mennyi extra terhelés az ami még elfogadható...

Mindezek figyelembevételével mondtam azt amit mondtam. Tehát ha nem értetek egyet azzal hogy ezek meglehetősen megfogják nehezíteni ennek az új szabványnak a megvalósítását, akkor tiszteletben tartom a véleményeteket. Viszont akkor tényleg semmi értelme itt koptatnom a billentyűzetet.

"Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". ": ez nemcsak, hogy marhaság, de még önellentmondásos is.

"Minél biztonságosabb titkosítást akarnak megvalósítani azzal arányosan nőni fog a szükséges számítási igény is!": ez meg egy terelés, féligazság. nem az a kérdés, hogy a jogosult dekódolás számítási igénye mennyi, hanem az, hogy az illegális dekódolási kísérlet mekkora számítási igénnyel vihető végbe. ilyen a pgp is, ha tudod a kulcsokat, akkor nagyjából mindegy, hogy mekkora kulcsokkal dolgozol, mert nem nő vészesen a számítási igény a kulcs méretével, ha meg nem tudod, akkor peched van, mert sosem töröd fel.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az a legjobb, hogy minden résztvevő mást vár a projekttől

42# Titkosítást miért is akartnak megvalósítani? Amúgy azért nő a számítási igény a titkosítás mértékével, mert a bruteforce ellen jelenleg (az extrém hosszú kódhosszon kívül) csak a nagy számítási kapacitás és a nehéz párhuzamosíthatóság az egyetlen bevált módszer.

Amúgy az AES-sel semmi gond nincs online titkosítás esetén. SSL/TLS esetén disztributált (pl. DH) AES kulccsal kommunikálnak a felek ([link]).

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

"Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". ": ez nemcsak, hogy marhaság, de még önellentmondásos is.

Kérlek legyél kifejtőbb erre így nem tudok reagálni.

"ez meg egy terelés, féligazság. nem az a kérdés, hogy a jogosult dekódolás számítási igénye mennyi, hanem az, hogy az illegális dekódolási kísérlet mekkora számítási igénnyel vihető végbe."

Hát izé azt mondod hogy én terelek... Jó megkérdem ez a szabvány kinek is készülne vagy pontosabban milyen céllal? Mert abból amit mondasz úgy tűnik hogy elsődleges a Hackerek számítási teljesítménye és az ö ellehetetlenítésük. Viszont másodlagos a célszemély tabletének telefonjának számítási teljesítménye (csak feldobtam mint célplatformot) amin a videotartalom lejátszásra kerül... Hmm?? (Someting not compute)

De legyen mivel nem rendelkezem mért adatokkal ezen a téren ezért elfogadom amit mondtál. Azt azért viszont áruld el kérlek hogy arányosan kulcsméret növekedésével százalékosan mekkora plusz teherről beszélünk?

Köszi szépen a linket. Ezzel eddig nem találkoztam össze. Mindig van új tanulni való

azért nehezebb titkosítást csinálni, mert nem tartalmazhat titkosítást gyengítő kódot???
egyébként pedig a kiindulási állítás, hogy nehezebb nyílt kódú titkosítást írni (gondolom, mint zárt kódút), nem igaz, tele van a net ellenpéldával, pl. pgp.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Oké ez a te álláspontod elfogadom.

"azért nehezebb titkosítást csinálni, mert nem tartalmazhat titkosítást gyengítő kódot???"

Tudom hogy röhejesen hangzik de igen nehezebb, időigényesebb. Mivel a folyamatos széleskörű auditálás nem enged annyi hibát keresztül. Ezért a végtermék minősége magasabb mint zárt-kódú társainak de az oda vezető út is jóval rögösebb.

Azt azért viszont áruld el kérlek hogy arányosan kulcsméret növekedésével százalékosan mekkora plusz teherről beszélünk?
Kulcsméret bitben van megadva, elméletben bitenként duplázódik a számítási igény. Gyakorlatban a számítási igény a kulcs entrópiájától függ. Random kulcs esetén az entrópia a véletlenszámgenerátor entrópiája (jó esetben közelít a kulcsmérethez). Humán kulcs esetén viszont ez jóval kisebb. Pl egy 8 karakteres véletlen jelszó entrópiája 64 bit. Egy 8 karakteres kisbetű + kötelező nagybetű és szám entrópiája maximum 51 bit. Csak kisbetű és legalább egy szám esetén pedig csak maximum 45 bit.
Mivel bitenként duplázódik a számítási igény, ezért a random és a komlex között 2^13 (8 192-szeres) a különbség, míg a kevésbé komlex esetében már 2^19 (524 288-szoros) - félmilliószorosával, 52 428 800%-al erősebb a random, mint az ember.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Tudom hogy röhejesen hangzik de igen nehezebb, időigényesebb. Mivel a folyamatos széleskörű auditálás nem enged annyi hibát keresztül.

Egyrészt kevered a titkosító eljárás kidolgozásának, és az implementáció megírásának kérdéskörét, másrészt pedig, ha programozásról van szó, akkor álláspontod szerint a "gyorsabban írhatunk szarabbat" a jó, és követendő megoldás, egy széleskörű terjesztésre szánt megoldás esetében? Most komolyan?

[ Szerkesztve ]

„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)