Archief - [PROG]Java vs .NET

Unzip Attack · 29 okt 2005

meeneemchinees zei:
@Unzip Attack : ik zou graag wat meer weten over uw MHP ervaring. Heb je dat voor zelf wat te "spelen" gedaan, of was dat in opdracht van iemand (school, bedrijf ... welke)?
En waarop hebben uw xlets gedraait? Enkel emulators (xletview, IRT reference implementation) of ook op een echte settop box (welke)?

vakantiewerk aan onderzoeksinstelling. over de eigenlijke inhoud mag ik nix kwijt, omdat het nogal 'gevoelig' ligt en zeer actueel allemaal is *zeker met hevige strijd tussen verschillende idTV concurrenten*. Twas allezins een enorme ervaring, en zeker niet makkelijk omdat bijna alles dat er geimplementeerd is, zeer recent was en zeer weinig op het net over te vinden valt.

Qua emulator kan ik wel zeggen dat xletview gebruikt is, maar ook veel getest op een settop box (Philips, het exacte type weet ik niet juist).

als je meer wil leren over al die concepten, er is 1 site van iemand die ook zowat de enige iDTV boek heeft geschreven : http://www.interactivetvweb.org/ da's zowa de referentie in idtv land.

meeneemchinees · 29 okt 2005

Meh, ik heb er al genoeg over geleerd. Ik heb ook al een project achter de kiezen (VRT). Ik weet niet of ik erover mag vertellen (niet dat er veel te vertellen valt). Ik ga maandag een keer vragen op mijn werk. In ieder geval : leuk om eens iemand te ontmoeten die er ook ervaring mee heeft.
Wat ik er klote aan vond : ook al compileer je voor java1.1, uw compiler gebruikt nog altijd libraries van uw eigen java. En alles werkt nog altijd prima op een emulator. En als je dan dolblij je xlet op een settop box zet, blijkt het dan toch niet te werken. Methods die toen nog niet bestonden etc. Dan mag je het zelf implementeren. Na een tijdje leer je wel in de javadocs te kijken naar @since tags, maar in't begin was het heel frustrerend.

Unzip Attack · 29 okt 2005

meeneemchinees zei:
Meh, ik heb er al genoeg over geleerd. Ik heb ook al een project achter de kiezen (VRT). Ik weet niet of ik erover mag vertellen (niet dat er veel te vertellen valt). Ik ga maandag een keer vragen op mijn werk. In ieder geval : leuk om eens iemand te ontmoeten die er ook ervaring mee heeft.
Wat ik er klote aan vond : ook al compileer je voor java1.1, uw compiler gebruikt nog altijd libraries van uw eigen java. En alles werkt nog altijd prima op een emulator. En als je dan dolblij je xlet op een settop box zet, blijkt het dan toch niet te werken. Methods die toen nog niet bestonden etc. Dan mag je het zelf implementeren. Na een tijdje leer je wel in de javadocs te kijken naar @since tags, maar in't begin was het heel frustrerend.

hehe inderdaad ja, dat geprul met java versie vond ik ook soms frustrerend ;D En eigenlijk xletview ook, ale op zich is dat een mooie emulator maar als je weet dat eigenlijk nog maar voor 50% implementatie is gebeurd, dan kom je regelmatig toch ook dingen tegen die wel op settop box werken en niet op xlet... *mja op zo'n maandje werken wordt het dan al snel "xSletview"

*
Bijvoorbeeld vrij onbegrijpelijk dat een achtergrond image niet getoond wordt in xletview en elementen soms al eens beetje anders komen te staan, gevolg : veeeeeeeel testen op tv...

Anyway is je project al in gebruik ? Dat wat ik deed, was prachtig toekomst-gericht onderzoek dat bijvoorbeeld wel kan gekocht worden (bewijs van schaalbaarheid, haalbaarheid enzo bevat het met wetenschappelijke paper die geschreven is, dus het is echt werkend resultaat)... Mooie was eigenlijk dat niemand op voorhand wist of de verschillende dingen wel combineerbaar waren, met aanvaardbare complexiteit enzo...

Vond jij trouwens de boxen zelf ook vrij traag ? ik had wel een die al een jaartje ofzo oud was, maar die ging toch vrij traag vond ik

wat ook tof was, was het herschrijven al die standaard Java componenten als textfields enzo, wegens pokketraag ;D

waar werk je trouwens ?

Joriz · 30 okt 2005

@unzip: je geeft me dus gelijk...

meeneemchinees · 30 okt 2005

Ik werk op de VRT. Wij hebben daar eerder onderzoek gedaan dan proberen een echt werkend project te maken. We vonden dat html browsers voor MHP te beperkt waren en om voor ieder project xlets te schrijven had je een vaste java programmeur nodig die dan praktisch nergens anders kon worden ingezet. En iets als Cardinal studio zagen we ook niet zitten.

Dus hebben we een framework gebouwd waarmee je via xml files zowel de content, de layout en de logica kon bouwen. De xmls werden op de box zelf geïnterpreteerd (zodat we content van onze websites na een xslt simpelweg naar de box konden sturen - eigen xmlparser moeten schrijven omdat de bestaanden niet klein en snel genoeg waren). Systemen gebouwd om zoveel mogelijk asynchroon te kunnen laden etc. Maar omdat we tijdens het programmeren nog regelmatig van idee veranderden (het was dan ook een onderzoeksproject), is het niet echt heel mooie code geworden (understatement).

We hebben er uiteindelijk wat tests mee gedaan, en konden er qua complexiteit bijna evenveel mee als handgeschreven xlets. Wat betreft snelheid : ons systeem was niet de snelste, maar we hebben nog tragere systemen gezien, dus het mocht er toch wel zijn (snellere systemen hadden ook meer beperkingen).

Uiteindelijk het enige wat we toen nog moesten maken was een WYSIWYG editor, maar dat is er nooit van gekomen. Ik ben terug mijn normaal werk gaan doen (grotendeels J2EE), en het project ligt ergens op de CVS server stof te verzamelen, voor zover ik weet.

Ik heb toen gewerkt met de proef-boxen van Telenet, maar we zijn er ook eens mee langsgeweest bij Sony, waar ze een TV met ingebouwde MHP-stack hadden. Die boxen van Telenet waren een stuk krachtiger (maar toch nog traag). Met de uiteindelijke Telenet boxen heb ik niet gespeeld, maar het zou me niet verbazen als ze nog krachtiger waren.

Ik vond het uiteindelijk toch ook wel tof. Je kreeg met MHP bijna het gevoel alsof je een operating system of zo schreef, gewoon omdat je (relatief) low-level moest gaan.

Unzip Attack · 30 okt 2005

Joriz zei:
@unzip: je geeft me dus gelijk...

tuurlijk niet, jij zevert gewoon een beetje. jammer dat die 'ervaring' vraag toch beetje tegenvalt

Anyway meeneemchinees da's mooi projectje, en ligt echt volleeeedig in de lijn van wat VRT eigenlijk de laatste jaren doet. Nix anders dan hun content omzetten via XSLT's naar alle mogelijke formaten. Zo weet ik dat hun nieuwswebsite, teletext, ... allemaal via xml en xslt worden omgezet. Mooi systeem maar ik denk dat het nog veel beter en minder complex zou kunnen

MHP was idd vrij low level, nuja mij heeft dat niet echt afgeschrikt. Dat boxen vrij traag zijn is echt understatement, da's het eerste wat mij opviel... Nuja dat zal er denk ik snel op vooruit gaan. Bij ons hadden we ook een sattelietbox die een pak sneller ging...

wat gebruiktte jij trouwens als gewone java editor ?

azerty · 30 okt 2005

imho:
Wat je ook niet mag vergeten mee te nemen in je 'kost'-berekening is de leercurve die programmeurs moeten doorgaan om JAVA of .NET onder te knie te krijgen. Uit persoonlijke ervaring moet ik dan toch zeggen dat hier Microsoft een stapje voor is. (mijn subjectieve mening)
Eveneens heb je bij dot.net het voordeel dat je de keuze hebt uit verschillende telan zoals C-sharp en vb en C++ en ... Dit biedt je het voordeel als bedrijf dat programmeurs met verschillende achtergronden gemakkelijker op te leiden zijn om te gaan ontwikkelen in dot.net dat in Java. Bijkomend trekt C-sharp zeer fel op Java (om niet te zeggen dat M$ zich er zeer sterk heeft door laten inspireren), wat je nogmaals het voordeel biedt dat Java programmeurs ook snel om te vormen zijn.
Microsoft heeft zich ontegensprekelijk laten "inspireren" door Java en zoals meestal met M$, hebben ze positieve punten weerhouden en nagatieve punten verbeterd.
Binnenkort met het 2.0 framework en Visual Studio 2005 denk ik dat ze een grote stap voorwaarts zullen zetten. Waar ze in het verleden mischien een beetje achter JAVA aanhuppelden denk ik dat ze nu JAVA ver achter zich gaan laten.
Dan nog een van de vele argumenten: JAVA is platformonafhankelijk en .Net draait alleen op Windows. Ten eerste JAVA is platformonafhankelijk IN THEORIE. In de praktijk komt er toch meer bij kijken. En met Mono (en andere initiatieven) zal .NET binnenkort bijna even platformonafhankelijk worden dan JAVA.

WHiSPy · 30 okt 2005

azerty zei:
imho:
Wat je ook niet mag vergeten mee te nemen in je 'kost'-berekening is de leercurve die programmeurs moeten doorgaan om JAVA of .NET onder te knie te krijgen. Uit persoonlijke ervaring moet ik dan toch zeggen dat hier Microsoft een stapje voor is. (mijn subjectieve mening)
Eveneens heb je bij dot.net het voordeel dat je de keuze hebt uit verschillende telan zoals C-sharp en vb en C++ en ... Dit biedt je het voordeel als bedrijf dat programmeurs met verschillende achtergronden gemakkelijker op te leiden zijn om te gaan ontwikkelen in dot.net dat in Java. Bijkomend trekt C-sharp zeer fel op Java (om niet te zeggen dat M$ zich er zeer sterk heeft door laten inspireren), wat je nogmaals het voordeel biedt dat Java programmeurs ook snel om te vormen zijn.
Microsoft heeft zich ontegensprekelijk laten "inspireren" door Java en zoals meestal met M$, hebben ze positieve punten weerhouden en nagatieve punten verbeterd.
Binnenkort met het 2.0 framework en Visual Studio 2005 denk ik dat ze een grote stap voorwaarts zullen zetten. Waar ze in het verleden mischien een beetje achter JAVA aanhuppelden denk ik dat ze nu JAVA ver achter zich gaan laten.
Dan nog een van de vele argumenten: JAVA is platformonafhankelijk en .Net draait alleen op Windows. Ten eerste JAVA is platformonafhankelijk IN THEORIE. In de praktijk komt er toch meer bij kijken. En met Mono (en andere initiatieven) zal .NET binnenkort bijna even platformonafhankelijk worden dan JAVA.

Dat visual studio .net 2005 de concurrentie ver achter zich gaat laten zou me toch verbazen, hoor. IntelliJ IDEA en eclipse hebben immers honderden plug-ins voor de meest uiteenlopende zaken. (jaja, zelfs plugins voor project-management) De grootste "vernieuwingen" in de 2005 editie zijn voor zover ik weet de built-in unit-testing en de refactoring waar _eindelijk_ eens iets aan gedaan is.

Ik ben misschien bevooroordeeld, maar ik denk dat .Net toch nog altijd mooi achter hinkt op JEE op bepaalde vlakken. (omgekeerd is het ook wel zo, dat geef 'k toe) Ik denk dan maar aan de ports van spring, hibernate, ant, cruisecontrol, etc. Die frameworks worden rechtstreeks geport ipv dat ze hun eigen ding zouden doen. (Nhibernate is 'n letterlijke (!!) port van hibernate 2.1. Bekijk de source maar eens en ge zult eens goed fronsen denk 'k.)

azerty · 30 okt 2005

't hangt er allemaal vanaf hoe je 't bekijkt,
Hier is er ook nog een interessant artikel: http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tcP
en dit ook: http://www.computable.nl/artikels/archief5/d29hb5hy.htm

Maar zelfs indien spring en andere initiatieven eerst ontwikkeld worden voor J2EE en erna 'geport' worden naar dot net (zie ook NUnit), dat pleit nog meer voor DOT.NET. Daar is toch niets mis mee. Zo is dotnet ook ontwikkeld, raap alle goeie dingen van anderen samen en gebruik dat om er iets beter van te maken. Je kan Spring ook beschouwen als een (geslaagde) poging om J2EE ontwikkelingen zo productief te maken als .NET projecten.

Nog een groot probleem, vind ik, van JAVA is als je bijvoorbeeld 2 nieuwe (maagdelijke) programmeurs naast elkaar zet en de ene gaat zich verdiepen in J2EE en den andere in DOT.NET, dan zal je bijna altijd merken dat de J2EE programmeurs zeer snel al 't bos niet meer door de bomen zien en de DOTNETTERS al zeer snel productief zijn. Voor een bedrijf is dat belangrijk, want productiviteit = centen...

azerty · 30 okt 2005

volgend verhaal moet je eens lezen:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
(dit gaat op zowel voor J2EE als DOT.NET)

dotJan · 30 okt 2005

Java is trager omdat het geïnterpreteerd wordt.

Java is meer dan alleen een programmeertaal, het is een technologie.

azerty · 30 okt 2005

dotJan zei:
Java is trager omdat het geïnterpreteerd wordt.
Java is meer dan alleen een programmeertaal, het is een technologie.

Dot Net is ook een technologie.
Tegenwoordig gaat dat niet meer zo fel op hoor, interpreted talen zoals Java, met de JIT, zijn al een pak sneller geworden en in sommige gevallen sneller dan C++:

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html

WHiSPy · 30 okt 2005

dotJan zei:
Java is trager omdat het geïnterpreteerd wordt.

Java is meer dan alleen een programmeertaal, het is een technologie.

Tot zover uw kennis van .Net? Want dat werkt op net dezelfde manier als java, hoor. Beide talen worden omgezet naar bytecode en dus niet geïnterpreteerd. (een scriptingtaal wordt geïnterpreteerd)

Trouwens azerty: Spring is geen poging om de .Net productiviteit na te apen. Het hele concept staat uitgelegd in J2EE design and development. Indien het ook zo'n poging zou zijn, dan zou ge ook geen ports moeten zien, hé.

azerty · 31 okt 2005

WHiSPy zei:
Tot zover uw kennis van .Net? Want dat werkt op net dezelfde manier als java, hoor. Beide talen worden omgezet naar bytecode en dus niet geïnterpreteerd. (een scriptingtaal wordt geïnterpreteerd)
Trouwens azerty: Spring is geen poging om de .Net productiviteit na te apen. Het hele concept staat uitgelegd in J2EE design and development. Indien het ook zo'n poging zou zijn, dan zou ge ook geen ports moeten zien, hé.

Tot zover dan uw kennis van dotnet, want er is wel degelijk een verschil, dotnet wordt niet geinterpreteerd. Het wordt, zoals bij java, omgezet naar een IL (intermediate language) die dan gecompileerd wordt naar native machine code. Waardoor, vergeleken met standaard java, het veel sneller is...
http://www.codeproject.com/dotnet/clr.asp

Spring is er gekomen omdat de standaard wijze om applicaties in J2EE te maken te ingewikkeld werd. Men is terug naar de basis gegaan en heeft met spring op de proppen gekomen, net om zo productief als in andere ontwikkelomgevingen applicaties te kunnen bouwen.
http://nl.wikipedia.org/wiki/Spring_(framework)

Emerxill · 1 nov 2005

azerty zei:
Nog een groot probleem, vind ik, van JAVA is als je bijvoorbeeld 2 nieuwe (maagdelijke) programmeurs naast elkaar zet en de ene gaat zich verdiepen in J2EE en den andere in DOT.NET, dan zal je bijna altijd merken dat de J2EE programmeurs zeer snel al 't bos niet meer door de bomen zien en de DOTNETTERS al zeer snel productief zijn. Voor een bedrijf is dat belangrijk, want productiviteit = centen...

Ik zie dat eerder als "het kaf van de koren scheiden"

. Da van die centen is een goed punt maar ge kunt het ook verder door trekken.
Een beginnende .NET-er is rapper met .NET weg omdat de echt complexe dingen mooi weggestoken worden. En daarom heeft dat imo een kortere leercurve.
In Java duurt het even langer voor ge ne developer kunt inzetten die echt productief is, maar als em 1x der mee weg is, dan kan hij et ook.
Alst in .NET 1x echt complex begint te worden zijn der nieveel die daar rap mee weg zijn ookal hebben ze enkele jaren professionele ervaring. En dan is .NET msdn niet echt duidelijk terwijl Java API dat wel is.
En dan gaat net .NET-er ook een pak minder productief zijn...

Daarmee dat ervaren Java-developers zo gegeerd zijn en beginners rapper in .NET worden aangenomen dan in Java imo.

azerty · 1 nov 2005

Het heeft weinig te maken over 't scheiden van kaf en koren, maar eerder met je weg terugvinden in de documentatie. Het probleem met Java en J2EE is dat er eigenlijk veel te veel documentatie over terug te vinden is en ook zoveel frameworks en extras en ..., dat je als beginner meestal gewoon niet weet waarmee te beginnen. Dat heeft Microsoft veel beter aangepakt, met bijvoorbeeld de msdn, www.asp.net en www.windowsforms.net, ea. Je vind er veel sneller informatie terug over 'Hoe pak ik nu best dit soort project aan.'
Op dit gebied kan Sun nog wel 't een en 't ander leren van Microsoft.
Ik spreek echt uit eigen ervaring hoor. Een paar jaar geleden heb ik me op J2EE gesmeten (begonnen met een cursuske bij Cronos) en erna veel docs gelezen enzo, maar vooralleer ik productief was heeft 't toch even geduurd. Omdat ik goede en toffe en ervaren collegas heb bij m'n bedrijf (CSC) hebben zij me ook goed gecoached en op weg geholpen. Onlangs ben ik me dan beginnen te verdiepen in Dot NET en 'k moet zeggen, dat gaat veel vlotter. Natuurlijk zal m'n ervaring ook meespelen, als je J2EE een beetje kent, ben je ook rap weg met Dot Net. Maar ik merk dit ook fel bij m'n nieuwe beginnende collegas.
Het feit of iemand nu begint met J2EE of met DotNet heeft zeer weinig te maken met het feit of die persoon een goede developper gaat worden. Dat zit gewoon in iemands karakter. De 'moeilijke zaken', zelfs al zijn ze mischien een beetje meer afgedekt binnen DotNet, worstel je toch door als je er interesse voor hebt.
Persoonlijk, imho, kan je pas een goede developper zijn, als je een beetje alround bent. Dwz geen J2EE of M$ evangelist, maar interesse voor beiden, en liefst ook nog van andere omgevingen (C++, Delphi,...). Het is niet echt de taal die belangrijk is, want dat komt neer op synthax en klassenamen, maar de methodologie en principes en architectuur (patterns) die erachter steken die je moet beheren. Eenmaal als je die achter de kiezen hebt, ben je zeer snel weg met gelijk welke taal hoor...

dotJan · 1 nov 2005

Objectgericht programmeren is idd meer dan alleen een taal leren. Dat dit gebeurt aan de hand van de programmeertaal Java is eerder bijkomstig. Ik vind voor het grootste deel van de programmeeropdrachten die heden ten dage van een ontwikkelaar gevraagd worden, op dit moment Java de beste taal, maar de basisconcepten van het objectgericht programmeren zijn belangrijker en onafhankelijk van een bepaalde taal. De projecten kunnen even goed toegepast worden in C++, Eiffel, Smalltalk, Ada '95 of Delphi.
Deze invalshoek is naar mijn mening erg belangrijk. Vaak worden mensen opgeleid om een aantal technieken vlot te kunnen toepassen, en wordt voorbij gegaan aan de onderliggende rationale voor de technieken. Voor mij is het efficiënter dat mensen, op eender welk niveau, opgeleid worden met een diep inzicht in de materie. Dit vraagt in eerste instantie een grotere inspanning van alle betrokkenen omdat zo een opleiding meer tijd vraagt. Het blijkt echter dat deze inspanning bijna onmiddellijk rendeert.
De kwaliteit van de software die geproduceerd wordt door programmeurs die de achterliggende begrippen onder de knie hebben is veel hoger dan wanneer ze enkel technieken toepassen. Dit resulteert vrijwel onmiddellijk in stabielere software, die minder gereviseerd moet worden, en makkelijker te reviseren is indien het toch moet, en een snellere time-to-market.
De opgeleide mensen worden ook minder afhankelijk van de programmeertaal en van de programmeeromgeving. Iemand die is opgeleid in de principes van het objectgericht programmeren kan zonder veel problemen overschakelen van Java naar bijvoorbeeld C++. Dat is veel moeilijker als enkel technieken werden aangeleerd, want die zijn net erg taalafhankelijk. De investering die in de opleiding werd gedaan is dus veiliger en kan langer renderen. Het is ondertussen wel duidelijk dat deze kennis niet snel irrelevant zal worden. Nieuwe programmeertechnieken die nu aan het ontstaan zijn, zoals het componentgebaseerd ontwikkelen, hebben allemaal hun basis in objectgericht programmeren.

[BAT] Hydra · 3 nov 2005

dotJan zei:
Objectgericht programmeren is idd meer dan alleen een taal leren. Dat dit gebeurt aan de hand van de programmeertaal Java is eerder bijkomstig. Ik vind voor het grootste deel van de programmeeropdrachten die heden ten dage van een ontwikkelaar gevraagd worden, op dit moment Java de beste taal, maar de basisconcepten van het objectgericht programmeren zijn belangrijker en onafhankelijk van een bepaalde taal. De projecten kunnen even goed toegepast worden in C++, Eiffel, Smalltalk, Ada '95 of Delphi.
Deze invalshoek is naar mijn mening erg belangrijk. Vaak worden mensen opgeleid om een aantal technieken vlot te kunnen toepassen, en wordt voorbij gegaan aan de onderliggende rationale voor de technieken. Voor mij is het efficiënter dat mensen, op eender welk niveau, opgeleid worden met een diep inzicht in de materie. Dit vraagt in eerste instantie een grotere inspanning van alle betrokkenen omdat zo een opleiding meer tijd vraagt. Het blijkt echter dat deze inspanning bijna onmiddellijk rendeert.
De kwaliteit van de software die geproduceerd wordt door programmeurs die de achterliggende begrippen onder de knie hebben is veel hoger dan wanneer ze enkel technieken toepassen. Dit resulteert vrijwel onmiddellijk in stabielere software, die minder gereviseerd moet worden, en makkelijker te reviseren is indien het toch moet, en een snellere time-to-market.
De opgeleide mensen worden ook minder afhankelijk van de programmeertaal en van de programmeeromgeving. Iemand die is opgeleid in de principes van het objectgericht programmeren kan zonder veel problemen overschakelen van Java naar bijvoorbeeld C++. Dat is veel moeilijker als enkel technieken werden aangeleerd, want die zijn net erg taalafhankelijk. De investering die in de opleiding werd gedaan is dus veiliger en kan langer renderen. Het is ondertussen wel duidelijk dat deze kennis niet snel irrelevant zal worden. Nieuwe programmeertechnieken die nu aan het ontstaan zijn, zoals het componentgebaseerd ontwikkelen, hebben allemaal hun basis in objectgericht programmeren.

In deze tekst zit duidelijk een grond van waarheid

, allemaal waarheden na elkaar opgesomd, je hebt precies kennis van zaken, waar werk je?

dotJan · 3 nov 2005

Dankje hydra, ik ben al 5 jaar professioneel programmeur, momenteel werk ik bij GB (carrefour) bij de fijne vleeswaren en en de fruit&groenten afdeling om het personeelsbestand verder uit te werken ;-) voor de rekverdeling van de producten te optimaliseren ben ik momenteel bezig aan een gesofisticeerd systeem waar ik alle noodzakelijke informatie omtrent de implementatie ervan uit de lineaire algebra en zijn toepassingen haal, vooral bij de uitwerking van afrondingsfouten bij de producten van twitte product draag ik de numerieke stabiliteit bij io dotJan

H@voc_!nc. · 17 nov 2005

zo af en toe leest ge hier toch eens iets zinnig

Archief - [PROG]Java vs .NET

Unzip Attack

Legacy Member

meeneemchinees

Legacy Member

Unzip Attack

Legacy Member

Joriz

Legacy Member

meeneemchinees

Legacy Member

Unzip Attack

Legacy Member

azerty

Legacy Member

WHiSPy

Legacy Member

azerty

Legacy Member

azerty

Legacy Member

dotJan

Legacy Member

azerty

Legacy Member

WHiSPy

Legacy Member

azerty

Legacy Member

Emerxill

Legacy Member

azerty

Legacy Member

dotJan

Legacy Member

[BAT] Hydra

Legacy Member

dotJan

Legacy Member

H@voc_!nc.

Legacy Member