Mozilla: Firefox 58 kan WebAssembly op pagina's sneller laden

Firefox 58 bevat twee eigenschappen die het draaien van WebAssembly op pagina's sneller maken: de functie streaming compilation en een 2-tiered compiler. Daarnaast stelt Mozilla https verplicht bij komende web-facing functies van Firefox.

Bij gebruik van Firefox 58 op een desktop kan de browser 30 tot 60MB WebAssembly-code per seconde compileren en op een gemiddelde smartphone is dat 8MB/s. Dat is sneller dan de meeste netwerksnelheden en het betekent dat code bijna direct ten uitvoer wordt gebracht na het downloaden, aldus Lin Clark van Mozilla. De verbeteringen komen door het gebruik van de streaming-api van WebAssembly door Firefox 58. Deze maakt het mogelijk de code van een .wasm-module al te compileren terwijl de data van de module aan het downloaden is. "Dit maakt de kosten voor het laden van WebAssembly meer zoals het decoderen van een afbeelding dan het laden van JavaScript", claimt Clark. WebAssembly is een standaard om code te compileren op het web en een alternatief voor JavaScript die met name Mozilla als zodanig naar voren schuift.

Niet alleen kan Firefox met de ondersteuning voor de streaming-api eerder beginnen met het compileren, maar door het gebruik van een 2-tiered compiler kan dit ook sneller. De tier 2-compiler zorgt op de achtergrond voor geoptimaliseerde code terwijl de tier 1-compiler bezig is met binnenkomende code. Firefox 58 draait nu nog in bèta.

In een ander Mozilla-bericht maakt Anne van Kesteren bekend dat per direct geldt dat nieuwe web-exposed functionaliteit van Firefox zich aan secure contexts moet houden. Secure contexts is een komende W3C-standaard die ervoor moet zorgen dat bepaalde content via een versleutelde verbinding is binnengehaald en zo een man-in-the-middle-aanval moet voorkomen. Bij Firefox gaat het dan om functionaliteit die 'zichtbaar' is vanaf een webpagina of server, of dit nu via JavaScript, CSS of http verloopt. Mozilla noemt als functionaliteit extensies, nieuwe http-responsheaders en WebVR.

Door Olaf van Miltenburg

Nieuwscoördinator

18-01-2018 • 22:07

89

Submitter: user109731

Reacties (89)

89
85
51
8
0
24
Wijzig sortering
Anoniem: 457607 18 januari 2018 22:56
Tip: volg die Lin Clark, ze heeft een aantal schitterende artikelen op haar naam staan, waarin ze behoorlijk complexe concepten zeer mooi uitlegd.
Ik weet dat het maar 10 toetsaanslagen ver zit, maar je best een linkje mogen geven hoor :p
https://twitter.com/linclark
Vergeet deze link niet, daar staan die mooie artikelen bij elkaar waar hij het over heeft: https://hacks.mozilla.org/category/code-cartoons/
Zij*
About Lin Clark
Lin is an engineer on the Mozilla Developer Relations team. She tinkers with JavaScript, WebAssembly, Rust, and Servo, and also draws code cartoons.
Die “hij” sloeg op jou Fledder2000 🙂

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 19:18]

En ik dacht dat je naar Fledder2000 refereerde...
We zijn weer lekker bezig met z'n allen :+
Nu een paar gelezen en ze schrijf inderdaad heel begrijpelijk. De vele illustraties zijn ook verhelderend.

Een goeie ontwikkelaar die ook goed kan uitleggen is echt uitzonderlijk.

[Reactie gewijzigd door Anoniem: 636203 op 23 juli 2024 19:18]

Mee eens. Ik vind haar artikelen over WebRender en Stylo erg goed in elkaar gezet.
Het zijn spannende dagen voor het web. Deze en komende features zijn echt een game changer.

Bijvoorbeeld: hiermee wordt het mogelijk op niet al te lange termijn om veeleisende games met de nieuwste grafische technieken rechtstreeks in de browser te spelen.

[Reactie gewijzigd door Jeanpaul145 op 23 juli 2024 19:18]

Ongetwijfeld gaan mensen interessante (nieuwe) toepassingen vinden voor WebAssembly, maar een game changer op het gebied van in-browser gaming zal het niet zijn. 4 jaar geleden draaide Unreal Engine al in-browser op javascript+WebGL en haalde 67% van native snelheid: https://tweakers.net/nieu...-engine-4-in-firefox.html
Wellicht zal de performance met WebAssembly verder richting 100% schuiven, maar het is dus allang mogelijk (met acceptabele performance) en wordt toch nauwelijks gebruikt... (Of wellicht was het toen gewoon z'n tijd ver vooruit en "ontdekken" game ontwikkelaars in-browser gaming nu ineens, wie weet...)
De game changer is dat je nu closed source pagina's krijgt. Dat is waarom Microsoft, Google en Safari ineens zo hard samenwerken om zo snel mogelijk WebAssembly te ondersteunen.

Dit zorgt maakt dingen mogelijk als DRM, verborgen code en ads die nauwelijks te blokkeren zijn.

Het grote voordeel van het web is dat je vrijwel altijd nog kon uitzoeken hoe het werkte ondanks de obfuscation en dergelijke. Met WebAssembly wordt je dat echt heel veel moeilijker gemaakt.
Ads blokkeren wordt op 2 manieren gedaan: Fysieke HTML-elementen blokkeren en domeinen blokkeren. Beide zijn zaken waar WebAssembly weinig invloed op kan hebben, omdat het uit de browser API komt of de netwerkapparatuur.
Vraag me af hoelang het nog gaat duren tot ze erachter komen en begrijpen dat ads in iedereens strot douwen ontzettend vervelend is en het gebruiken van adblockers aanmoedigt
WebAssembly is net zo closed source as minified JavaScript.
Nope. Minified Javascript kan je nog prettifyen en is veel beter geschikt voor mensen om te lezen. WebAssembly is gecompileerd en niet geminified. Dat is voornamelijk zodat het snel uit te voeren is door processors, maar de leesbaarheid is veel lager. Tenzij je een held bent in lappen assembly ontcijferen, maar dat zijn er maar heel weinig.

Bovendien laad je waarschijnlijk geen bestand meer, maar stream je de webassembly. Dus je krijgt een eindeloze stroom processorinstructies zonder functies en objecten.

[Reactie gewijzigd door BarôZZa op 23 juli 2024 19:18]

WebAssembly kan je ook naar een tekst formaat krijgen.
Dat tekstformaat is meer geschikt om te schrijven dan om om gecompileerde code te ontcijferen. Het is simpelweg een tekstuele representatie van de processorinstructies. Het is net zo slecht te ontcijferen als normale assembly.
Anoniem: 143696 @BarôZZa19 januari 2018 17:48
Met ppci kun je het disassembleren https://ppci.readthedocs.io/en/latest/

of een directere link naar ppci wasm handling: https://ppci.readthedocs.io/en/latest/reference/wasm.html

[Reactie gewijzigd door Anoniem: 143696 op 23 juli 2024 19:18]

Zolang advertenties nog steeds niet native gehost worden zal het blokkeren altijd mogelijk blijven.
Mwah, wasm is niet echt gemaakt om met de DOM te communiceren.
Het zal altijd een combinatie van html+js+wasm blijven.
Het wasm gedeelte is vooral bedoeld om zaken uit te voeren die te sloom zouden zijn in js. Je zou bijvoorbeeld kunnen denken aan lange berekeningen, algoritmes en codecs die eerst in C waren geschreven.
In firefox kan je WebAssembly gewoon debuggen als er een source map is: https://twitter.com/slsoftworks/status/941400137921949696

[Reactie gewijzigd door NiLSPACE op 23 juli 2024 19:18]

En mensen met een slechte bedoeling gaan die source maps natuurlijk delen. 8)7
Oh, op die manier bedoel je. Ik dacht dat je bedoelde dat het ontwikkelen moeilijker zou gaan, sorry.

Ik zie hierbij niet veel verschil met minified Javascript code. Zelfs als je een prettifier zou gebruiken is het moeilijk om die code te lezen.
Minified JS valt echt wel nog goed te lezen hoor. De variabelen worden obfuscated, maar alle properties behouden hun volle naam. Met die kennis kan je op onbekende variabelen alsnog je eigen naam plakken.

Als je de code bovendien live bewerkt (=het origineel vervangt door een lokale kopie), krijg je in debugmodus steeds meer context mee voor de resterende onbekende functies. Zo is een script van meer dan 1000 regels (prettified) reverse engineeren echt nog goed te doen. Je hoeft dan ook niet alles te ontleden.

[Reactie gewijzigd door FlaffTweakr op 23 juli 2024 19:18]

Acceptabel voor een webpagina is anders dan acceptabel voor een (veeleisend) spel.

Ik maak vaak genoeg mee dat alle javascript die hier en daar meedraait (zelfs op andere tabs!) gewone videos al laat stotteren met audio/video desync als gevolg.

Het komt op mij over als het bouwen van een prachtige wolkenkrabber in het midden van een moeras met een fundering die gewoon structureel ongeschikt is.
Ik maak vaak genoeg mee dat alle javascript die hier en daar meedraait (zelfs op andere tabs!) gewone videos al laat stotteren met audio/video desync als gevolg.
In tegenstelling tot je eerste indruk is het in 99% van de gevallen gewoon brak programmeerwerk. Javascript kan prima werken en ook voor audio/video ingezet worden (of daarnaast zijn ding doen) zonder dat het problemen oplevert. Omdat de drempel voor webdevelopment laag is, heb je dus ook veel mensen die de verkeerde dingen aanleren. Of bedrijven die niet inzien hoe hun werkwijze de gebruikservaring schaad. We zijn al best ver met veel tools, hulpmiddelen en testing, maar lang niet iedereen doet dat, kan dat of wil dat doen
Ik heb het in dit geval helaas over de Twitch chat, en ik mag aannemen dat die wel een nette pagina in elkaar kunnen zetten met alle analytische zaken die maar nodig zijn. Zelfs met maar een tab open welk op de stream in kwestie staat kan ik merken dat een drukke chat een catastrophisch gevolg heeft op de prestaties van de video.

Daarnaast geldt dat pakweg twee jaar terug FTL nog niet goed werkte (1 a 2 fps) op de webasm-achtige variant die bij HumbleBundle beschikbaar was gesteld. Tuurlijk is er een boel voortgang in twee jaar, maar als een sprite-gebaseerd spelletje het nog niet goed af kon zie ik AAA-verhalen echt nog niet een toekomst in de webbrowser hebben.
Je klaagt over het feit dat een chat met duizenden zoniet tienduizenden of veel meer de rest traag maakt? Dat is geen issue van Javascript. Niks gaat dat vloeiend laten werken. Het grote probleem is dat alles in 1 grote chat wordt geplempt en vervolgens gaat ie zo snel dat er ook niks meer van te lezen is. Ik heb het vooral bij de E3 van afgelopen jaar gemerkt, je hebt er gewoon niks aan. Daar gaat WebAssembly echt 100% niets voor oplossen. Ze zorgen al dat je maar 1 bericht per 10 seconden mag toevoegen maar zelfs dan is het flut.

En als je AAA games in de browser wilt hebben, dan moet je toch echt wat andere demo's kijken. Maar dan heb je het al snel over WebGL en dat werkt gewoon prima.
Deze streamer heeft rond de duizend viewers, en de spam is echt niet op GDQ niveau met gemiddeld een bericht elke seconde oid. Daarnaast blijft gelden: full screen? Dan zou chat uberhaupt niet moeten updaten IMHO. Er is geen reden om dan plat te worden gelagd.

Maar ja. Het is wat het is.
Het komt op mij over als het bouwen van een prachtige wolkenkrabber in het midden van een moeras met een fundering die gewoon structureel ongeschikt is.
Haha, tsja. Welkom op het Internet. Doet me ook denken aan dit artikel van een aantal jaar terug trouwens (extra van toepassing op het ontwikkelen van een web browser).
Ik speelde Interstellar Marines en nog een ander spel (kan het nu even niet vinden) in de browser, flinke tijd terug. Die zijn er allebei weer vanaf gestapt naderhand. Snelheid te laag, te vaak onverklaarbare effecten en crashes. En dat was alleen maar sneller als je ook maar 1 andere tab open had.
Eigenlijk snap ik totaal niet waarom er niet geleerd wordt van het verleden en keer op keer dezelfde fouten gemaakt worden. Waarom moet het makkelijker worden gemaakt om vage externe code in de browser te draaien? Javascript heeft al genoeg problemen dat er al heel lang plugins zoals noscript bestaan om troep te weren, en nu willen ze het mogelijk maken om nog meer verschillende code in de browser uit te voeren? En nog zo native mogelijk? Alsjeblieft niet zeg. Dit wordt een speeltuin voor hackers, trackers, advertisers en nog veel meer gespuis. Dat je er ook games mee in je browser kan draaien? Who cares. Die paar games zijn de nadelen niet waard.
Je begrijpt het totaal verkeerd. Webadembly heeft dezelfde mogelijkheden en draait in dezelfde omgeving als JavaScript. Het is alleen veel makkelijker te parsen en te optimaliseren. Ook is het een veel makkelijkere taal om naar te transpilen vanaf andere talen zoals rust, c of c++.

Het is een doorontwikkeling van asm.js wat een subset van JavaScript was en daarmee ook veel beter te optimaliseren was.
Als dat zo is, waarom wordt hier dan overal gesproken over performance verbeteringen tov javascript? Hoe kun je meer performance krijgen tov native javascript wanneer het hetzelfde systeem is en er nog een vertaallaag tussen zit?
Waarschijnlijker op de korte termijn zullen advertenties zijn die middels canvas & webasm de gouden flash tijden laten herleven.
Firefox op mijn smartphone is echt sloom, het lijkt alsof ie eerst de vorige paginas wil openen tdrwijl ik al een nieuw zoekopdracht heb ingetypt. Chrome doet het beter. Terwijl op de pc het andersom is.
Ik ervaar eenzelfde probleem. Het lijkt wel of Firefox moeite heeft met verbinden. Ik vraag me af of dit Google is die traag reageert (al dan niet opzettelijk) wanneer het de Firefox Mobile user agent ziet. Je krijgt op Firefox namelijk ook een hele oude variant van Google search results te zien.

Type bijvoorbeeld eens "weather" in je zoekveld. Op Chrome (Android) zie je dan een mooie kaart met het weer voor de komende 24 uur en week. Op Firefox Mobile krijg je 3 statische afbeeldingen met een temperatuur-tekst eronder. Als je een add-on installeert waardoor de Chrome user agent aangehouden wordt, krijg je wel de nieuwe versie van de zoekresultaten te zien.

[Reactie gewijzigd door Laloeka op 23 juli 2024 19:18]

Dat soort dingen doet Google al jaren. Niet alleen bij Mozilla maar vooral ook bij Microsoft en Apple. Beter gewoon niets van dat immorele bedrijf gebruiken...
Ik zou heel graag FF op Android willen gebruiken, maar hij hangt inderdaad bij het verbinden echt heel lang, en heb even niet zo'n zin daar uitgebreid onderzoek naar te doen. Ik kan me voorstellen dat Google flauw doet, maar volgens mij is het bij enkele andere pagina's ook zo. (Of komt dat doordat er libraries van Google cdn ingeladen worden ... Analytics enzo gaan async)
De firefox variant gefocused op privacy is bloedje snel, die raad ik echt aan voor ff snel een website laden. firefox focus heet het geloof ik.

[Reactie gewijzigd door t link op 23 juli 2024 19:18]

Ja, maar Focus gebruikt helemaal geen rendering engine van Mozilla. Het is gewoon een schil om Google's WebView.
Dat geldt toch voor alle Android browsers? Dat is een verplichting van Android dacht ik.
Nee firefox mobile draait niet op webview maar op geckoview, daarmee hopen ze webview te vervangen.

[Reactie gewijzigd door t link op 23 juli 2024 19:18]

En je punt is? chrome is sneller om dezelfde reden alleen is dit dan mozilla's variant met goeie integratie in het mozilla ecosysteem (op extensies na dan)
Het artikel gaat over verbeteringen in Firefox en zijn engine. Ik wilde even aangeven dat dit op geen enkele manier te maken heeft met de Focus/Klar apps.
Ah oke, je was meer on topic dan ik was dan :P
wat is het verschil met in firefox een privevenster te openen? ik heb dan ook nog ublock en noscript aan staan op windows dan wel. en dan heb je natuurlijk ook de snelle geschiedenis wis button vergeten.
Het is een gestripte versie van firefox. zie het als een chromium variant maar dan firefox.
Firefox focus heeft maar 1 tab en is bloedje snel.
Ik gebruik zelf Firefox Beta op mijn mobiel. Heb nooit Release gedraaid, maar ik heb gehoord dat Beta veel sneller is op Android omdat in Release nog niet alle Project Quantum onderdelen zitten die wel al in desktop zitten.

Edit:
Nightly schijnt nog sneller te zijn.

[Reactie gewijzigd door NiLSPACE op 23 juli 2024 19:18]

Welke telefoon heb je? Op mijn S8 is de native browser de enige browser die niet lagt. Ik kan met Firefox of Chrome niet eens zonder lag door de hoofdpagina van Tweakers scrollen. Echt drama.
Ik heb de Huawei P10 Lite. Ik zal niet ontkennen dat Chrome sneller is op Android, maar het voordeel dat ik ook extensies kan gebruiken zorgt dat ik bij Firefox blijf.
Dat komt omdat op Android pas bij Firefox 59 project Quantum krijgt, die halverwege maart uit zou moeten komen.
"Firefox zich aan secure contexts moet houden", ja, compiled code, wat kan er fout gaan zou je haast denken. Een scripting taal is al triviaal secure to houden in de sandbox zoals is gebleken, en java applets, flash en silverlight waren ook geweldig... :+
Dit heeft niets te maken met veilige of onveilige code. Ook malware kan prima over een HTTPS verbinding gestuurd worden. Het gaat vooral om de andere kant op, van de gebruiker naar de server.

Jij kan bijvoorbeeld beslissen dat een site jouw locatie mag weten middels een GEO api als die site daar om vraagt. Daar vraagt de browser jou toestemming voor als een site dat wil weten. In Secure Context mag dat soort informatie alleen nog maar over HTTPS verzonden worden. Jij mag bijvoorbeeld wel vinden dat die site jouw locatie mag weten, dat wil nog niet zeggen dat je dat ook wil meedelen aan meeluisterende ISP’s, vage proxies, iedereen op een publiek WiFi netwerk etc.

Doordat browsers HTTPS gaan afdwingen voor dit soort zaken worden site eigenaren gedwongen aan de privacy van hun bezoekers te denken.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 19:18]

Ja, want HTTPS is de magic silver bullet voor security uiteraard. De meeste aanvallen gebeuren omdat je boosaardige ISP een man-in-the-middle attack opzet. Site eigenaren denken natuurlijk niet aan de privacy van hun bezoekers: die denken juist hoe ze dat zo snel en winstgevend mogelijk kunnen gebruiken. En anders wel een van de exploits die lokaal al lang draaien voor je uberhaupt iets encrypt.
De meeste aanvallen gebeuren omdat je boosaardige ISP een man-in-the-middle attack opzet.
Volgens mij snap je https niet. Https voorkomt juist mitm aanvallen, door alles end-to-end te versleutelen, dus dan kan jouw “boosaardige” ISP niets meer, want die ziet alleen een stroom encrypted bits.

Maar over het algemeen is het niet je ISP die aanvallen uitvoert. Dan zouden ze al hun klanten kwijtraken. Aanvallers zijn meestal buitenstaanders die het verkeer op een of ander manier om kunnen leiden. Boosaardige wifi hotspots zijn veel gebruikelijker, dus beter gewoon geen onvertrouwde wifi gebruiken.
Https is op zich secure... naar de server waarvan jij het certificaat accepteert. Alleen hoeft die server niet altijd te zijn wat jij verwacht. Met een nep-certificaat is te vaak nog teveel mogelijk.
Is dat niet het doel van HSTS preload?
Anoniem: 200498 @ArmEagle19 januari 2018 10:09
Tijd voor een extra groen slotje (of geen groen slotje meer met alleen https).

Wanneer ook nog gebruik wordt gemaakt van Public Key Pinning en dnssec zou het veilig moeten zijn, althans, je moet natuurlijk nog steeds checken op "typefouten" bij bezoeken van een site (typosquatting)
Anoniem: 890159 @kozue19 januari 2018 10:59
Maar over het algemeen is het niet je ISP die aanvallen uitvoert. Dan zouden ze al hun klanten kwijtraken.
Er zijn wel een aantal gevallen gerapporteerd maar daar durfden de anti-virus boeren de naam van de ISP niet te geven. Dat ging waarschuijnlijk om overheids malware. De meeste dreiging gaat in de praktijk uit van MITM attacks van anti-virus zooi en corporate firewalls.
En omdat veel site eigenaren niet zoveel geven om de privacy van hun gebruikers dwingen browser bouwers ze er nu dus toe. Wil een site eigenaar een bepaalde functie gebruiken dan moet dat over HTTPS anders werkt dat deel van die site simpelweg niet.
Je bedoelt nontriviaal ;)

Het verschil van WebAssembly met java/flash/silverlight is dat WebAssembly VM van de browsermaker is. Een 3rd party plugin heb je geen controle over. Dat is ook de reden dat dat soort plugins out-of-process geladen worden: de kans is daarmee kleiner dat dat de schade kunnen aanrichten aan het browserproces. De kans bestaat wel nog dat zulke plugins schade kunnen aanrichten aan het systeem van de gebruiker, want de beveiliging daarvoor wordt overgelaten aan de VM die flash/java/silverlight draait.

Wat is dan nog het verschil, want WebAssembly is net zo'n VM, zou je denken. Behalve dan dat WebAssembly niet berust op een VM (Java, .NET, Flash) die ook buiten de browser draait en daar net iets teveel toegelaten wordt. De WebAssembly VM kan fundamenteel veilig worden gebouwd, terwijl het bij de andere genoemde VM's een soort "strict mode" (zo noem ik het maar even) zal zijn, en we hebben gezien dat het mogelijk is om uit die strict mode te breken.
Anoniem: 988299 18 januari 2018 22:34
Ben nu een week over van Chrome naar Firefox en bent echt tevreden over Firefox.
Nu maar hopen dat het de vlotte browser blijft die het nu is.
Klopt, Firefox is op windows een perfecte browser, gebruik Chrome alleen nog om de krant te lezen vanwege de ingebouwde flash plugin.
Ook interesant: Een Firefox component die eerst in Javascript geschreven was is vervangen met WebAssembly https://hacks.mozilla.org...ith-rust-and-webassembly/
Hoe zet je web assembly uit? Ik heb daar eerder al naar gezocht en het is niet te vinden.

Ik wil dit absoluut niet in mijn browser. Met ActiveX in het achterhoofd heb ik geen zin in deze enorme attack surface.
Firefox: in de adresbalk "about:config" en zoek op "wasm".
Maar je angst is waarschijnlijk ongegrond, Web Assembly draait in de dezelfde omgeving als JavaScript en kan dus hetzelfde (of minder) als Js. Het is enkel een andere taal, Javascript is een scripttaal en wasm is een intermediate language.
Als google zijn zoekresultaten af laat hangen van de snelheid zou dan het gebruik van een snelle browser daar ook invloed op hebben?
WillySis in 'nieuws: Laadsnelheid pagina's gaat meewegen bij mobiele Google-z...

[Reactie gewijzigd door tw_gotcha op 23 juli 2024 19:18]

Je kan ook gewoon een abonnement nemen op Tweakers en ze daadwerkelijk belonen voor de moeite die ze doen om dit soort artikelen te schrijven, je? https://tweakers.net/abonnementen/
Of anders gewoon een uitzondering maken, zodat je wel reclame ziet. Het is niet alsof dit alles zonder inkomsten kan worden gedaan, dus draag je steentje bij.

[Reactie gewijzigd door Caelorum op 23 juli 2024 19:18]

Je kan ook gewoon een abonnement nemen op Tweakers en ze daadwerkelijk belonen voor de moeite die ze doen om dit soort artikelen te schrijven, je? https://tweakers.net/abonnementen/
Of anders gewoon een uitzondering maken, zodat je wel reclame ziet. Het is niet alsof dit alles zonder inkomsten kan worden gedaan, dus draag je steentje bij.
Je reageert niet op mijn constatering dat addblocking uBlock-origin schijnbaar even niet werkte.
Jammer dat je er om 3.50uur 'snachts een discussie over adblocking van Tweakers van maakt. Dat was niet mijn bedoeling.

[Reactie gewijzigd door Bruin Poeper op 23 juli 2024 19:18]

Onzin, tweakers is een bedrijf met een verdien model. Dat verdien model kun je omzeilen, dat moet je zelf weten of je dat doet. Zo download ik spul waar ik eigenlijk voor zou moeten betalen, en ik betaal wel weer voor tweakers. Daar zit verder geen logica achter.
Weet jij waar Tweakers aan verdient?

Gebruikersreviews, forumbijdragen. Daar heb ik er een stuk of wat van geleverd. Gratis en helemaal voor niks.
Wat krijg ik er van Tweakers voor? Een grote mond.
Je gedraagt je als een hinderlijke straatmuzikant die slecht of luidruchtig speelt en boos wordt als je geen centjes toestopt krijgt
Als Tweakers er niet tevreden over is moeten ze me bannen: doe maar gerust!!!!! Jullie hebben mij meer nodig dan ik jullie.

[Reactie gewijzigd door Bruin Poeper op 23 juli 2024 19:18]

Volgens mij gedraag ik me helemaal niet naar jou toe als wat dan ook. Ik geef aan dat het aan ieder zelf is om te bepalen wat hij/zij doet.
Goh kan jij van aandacht je rekeningen betalen? Tweakers site kost gewoon geld en de mensen die content produceren moeten ook betaald worden. Maar ben wel benieuwd hoe jij denkt dat ze dat beter kunnen financieren ipv via advertising of abo.
Goh kan jij van aandacht je rekeningen betalen? Tweakers site kost gewoon geld en de mensen die content produceren moeten ook betaald worden.
Ik produceer hier (en elders op Tweakers) content. Waar blijven mijn centen?
Dat neemt niet weg dat iedereen vrij staat om te doen wat hij/zij wil. Degene die uBlock-origin gebruikt heeft net zoveel gelijk als iemand die een abonnement heeft. Het heeft dus geen zin om daarover te discussieren. Het gewoon een keuze van een persoon en daar hoef je hem/haar er niet op te wijzen.
Dat is de reden waarom @Bruin Poeper zo reageerd gok ik zo.
Ik zie dat anders. Je hebt zeker niet even veel gelijk en ik zal mensen er gewoon op wijzen. Het is aan hun om er dan wat mee te doen, maar gezien de manier waarop hij/zij reageert vermoed ik dat hij/zij heel goed weet dat het verkeerd is. Het is een beetje als al die mensen die auteursrechtelijk beschermd materiaal downloaden. Die wijs ik er ook gewoon op, maar ik ga niet met een stok aan de deur staan en ze dwingen :-)
Je probeert de mensen die hier niet aan jouw bedoeling voldoen politiek incorrect te maken.
Daarmee ben jij de foute figuur.
Als je geld wilt voor je 'auteursrechtelijk beschermd materiaal' moet je het niet publiekelijk op internet zetten.
Voor de folders die ik (ongevraagd) in de bus krijg wordt me ook geen rekening aangeboden, het zou me wat moois wezen indien toch...

Auteursrechtelijk beschermd materiaal downloaden.
  • Ik zal je even een voorbeeld geven. kWas bezig een matras te kopen. Voor de hardheid is er de ISO3386 norm. Die is pas echt beschermd. Probeer die maar eens gratis te downloaden. Dat gaat je niet lukken.
  • Daarmee vergeleken doet Tweakers geen enkele moeite om zijn auteurs materiaal daadwerkelijk te beschermen. In tegendeel: men steeft juist naar gratis maximale verspreiding.
  • Dat ik het lees zou mij tot iets moeten verplichten??? Kom op zeg!
Jij houdt er dus een bijzonder hypocriete redenering op na.

[Reactie gewijzigd door Bruin Poeper op 23 juli 2024 19:18]

Wie heeft het over politiek incorrect of bedoeling? Jij begint keihard te reageren op een normale opmerking van mijn kant en dan ga je mij proberen weg te zetten als fout figuur? Prima...

Op dit item kan niet meer gereageerd worden.