Pagina 3 van 5

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:28
door Michael1954
From: Arminius the Terrible

Trouwens, zo zie je maar weer, als het waar was, had hij had het als open source moeten vrijgeven

Als je de rijkste man op Aarde kunt worden, ga jij er dan open source van maken? :ugeek:

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:29
door Michael1954
From: Halfgaar

Ja, ik denk het wel. Ik ben principieel tegen gesloten software en bedrijfsmacht. Vooral dat laatste moet een zapruder aanspreken…

Als je kijkt naar iemand als Steve Ballmer, dan zie je maar dat je van geld niet gelukkig wordt…

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:31
door Michael1954
From: Komodo

Het Sloot Digital Coding System (soes) zou de wereld opschudden: een nieuw alfabet voor digitale informatieopslag
dat niet langer meer gebruikmaakt van het binaire stelsel van nulletjes en eentjes, maar een veel efficientere methode hanteert.

Zijn toch gewoon nog nullen en enen ?
Het heet ook het Sloot *Digital* Coding System.
Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek.

‘s Kijken...1 KB=1024 Bytes=8192 bits=2^8192 = 1.090748 * 10^2466 mogelijkheden.
( dus een 1 met 2466 nullen )

Dat is een vaststaande hoeveelheid !
Dat zou inhouden dat er een grens is aan de aan het aantal boeken en films dat geschreven/gemaakt kan worden.
Het is heel veel maar op een gegeven moment zou het “op” moeten zijn.

Dat geloof ik niet en daarom is het systeem volgens mij een hoax.

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:32
door Michael1954
From: -V-

heheheheh Balmer = de digitale Cheney

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:33
door Michael1954
From: -V-

Maar zoals ik het begrijp is dat “de data” van een film of wat ook op een schijf staat, het is alleen de combinatie/volgorde van de data die het tot een leesbaar bestand maakt niet de inhoud die is voor alle gelijk. Enkel de volgorde is van belang. Dus je hebt een sourse code van 350mb op je HD staan of in het aflees apparaat, daarvan kan je alle digitale data maken, als je maar de sleutel hebt en die had hij.

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:37
door Michael1954
From: Komodo

Het probleem is dat computers alleen in enen en nullen rekenen.

Iets wat enigszins op een alfabet lijkt zijn hexadecimalen maar dat is slechts een hogere versie van binair (enen en nullen).

Basic is wat dat betreft de hoogste computertaal wat wil zeggen dat mensen er makkelijk mee uit de voeten kunnen. De computer moet al die programmaregels echter weer omzetten naar binair en dat leverde vroeger aanzienlijke vertraging op (voordat de computers “turboboost” kregen).

Niet helemaal.

Basic is zo langszaam omdat het geinterpreteert wordt d.w.z. regel voor regel ingelezen/vertaald/uitgevoerd.

Talen als Pascal , Forth, C etc. worden eerst gecompileert (=omgezet in machinetaal ) en draaien dan veel sneller
omdat ze niet elke keer vertaald hoeven te worden.

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:39
door Michael1954
From: Halfgaar

maar zoals ik het begrijp is dat “de data” van een film of wat ook op een schijf staat, het is alleen de combinatie/volgorde van de data die het tot een leesbaar bestand maakt niet de inhoud die is voor alle gelijk. Enkel de volgorde is van belang. Dus je hebt een sourse code van 350mb op je HD staan of in het aflees apparaat, daarvan kan je alle digitale data maken, als je maar de sleutel hebt en die had hij.

--
Wat Komodo zegt geldt dan. Je kan dan maar 2[sup]8192[/sup] mogelijkheden maken. Het aantal combinaties pixel met een bepaalde kleur over 180000 frames (2 uur) is volgens mij veel groter. Theoretisch kan het dus niet. Daarbij komt ook nog eens, dat hier gesteld wordt dat de sleutel altijd 1 KB is. Wat dan als de film een millennium lang is?
--
Overigens, 2[sup]8192[/sup] is (backslash is nieuwe regel, het dus één getal):
--
10907481356194159294629842447337828624482641619962326924318327861897\
21331849119295216264234525201987223957291796157025273109870820177184\
06361097976507755479907890629884219298953860982522804820515969685161\
35916381967718865426093245601212905539018863010179002525357999172000\
10079600026535836800905297805880952350501630195475653911005312364560\
01484742603529355124584392891875276869627934408805561751569434994540\
66778251408149006161059202564385045780133264935658360472424073824428\
12245131517757519164899226365743722432277368075027627883045206501792\
76170094569916849725787968385173704999690096112051565505011556127149\
14925153421057489666295470327863215057308284302216649703243961386352\
51626409516168005427623435996308921691446181187406395310665404885739\
43483287742816740749537099351186875635997039011702182361674945862096\
98570062636120827067154081570665751372810270223109275649102767591605\
20878304632411049364568754920967322982459184763427383790272448438018\
52697776494107271561158043469082745933999196141424274141059911742606\
05564837637563145276113626586283833686211579936380208785376755453367\
89915694234433955666315070087213535470255670312004130725495834508357\
43965382893607708097855057891296790735278005493562156109079584517295\
41159729274798775277385600082041185589300047777487277618538135104938\
40581861598652211605960308356405941821189714037868726219481498727603\
65361629885617482241303348543878532402475141941718301228107820972930\
35373728045743720952287036227763639452908698062584223551485075710396\
19387449629866808188769662815778153079393179093143648340761738581819\
56300299442279075495506128881830843007964869323217915876591803556521\
61571154029921202761556078731079374774668415283629877086994501520312\
31862594203085693838944657061346236704234026821102958954951197087076\
54618662279629453645162075650935101890602377382153953277620867697858\
97319663303088933046651694361850783506415683369445300514374913112988\
34367265238595404904273455928723949525227184617404367854754610474377\
01976802557660588103807727070771794222197709038543858584409549211609\
98525389039746557039439730860909305969633607675299649384145981857059\
63754561497355827813623833288906309004288017321424808663962671333528\
00923275835087305961411872378142210146019861574738685509689608918918\
04413395585248228675411132126387936755676503403629700319300233978284\
65318547238244232028015189689660418822976000815437610652254270163595\
65087543385114712321422726660540358178146909080657646895058766199718\
6505665475715792896
--
Ik denk dus ook dat het een hoax is. Wellicht is hij daarom wel aan een hartaanval gestorven; hij wilde de boel bedriegen voor miljoenen, en kon de stress niet meer aan…

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:40
door Michael1954
From: P.Uncia

Of de schande van het ontmaskerd worden, dus zelfmoord 8-)

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:41
door Michael1954
From: -V-

Als je in meerdere dimensies denkt kan het wel, een infinite loop.

Re: De Broncode van Jan Sloot

BerichtGeplaatst: vr 27 aug 2010, 19:42
door Michael1954
Fro9m: Halfgaar

Even doorberekend op mijn vorige post:
--
Ik ga uit van PAL 4:3, wat 720x576@12bit is (ik zei eerder 24, maar dat is fout). Eén pixel kan 2[sup]12[/sup] mogelijkheden hebben:
mogelijkheden_per_pixel = 2[sup]12[/sup]
Er zitten 720x576 pixels in een frame:
pixels_per_frame = 720 x 576 (= 414720)
Per frame heb je dus zoveel mogelijkheden:
mogelijkheden_per_frame = mogelijkheden_per_pixel[sup]pixels_per_frame[/sup] (= een getal van een paar honderd regels lang...)
In een film van twee uur zitten 180000 frames, dus het aantal mogelijkheden van pixelwaardes voor de hele film zijn:
mogelijkheden_per_film = mogelijkheden_per_frame[sup]180000[/sup]
--
Als mogelijkheden_per_frame al een paar honderd regels lang is, dan is mogelijkheden_per_film bijvoorbeeld 200[sup]180000[/sup] lang. Gigantisch dus.
--
Je kan in die 1 KB dus niet alle mogelijkheden kwijt.
--
Doe ik iets fout?