181–190 of 259 posts
People should look at existing emscripten projects to see what the future will be like since compiling to asm.js is already pretty mature (just a bit slow and bloated as noted in the article). Any emscripten project can compile to WASM trivially by adding a `-s WASM=1` compilation flag. Example projects: - OCR (tesseract): http://tesseract.projectnaptha.com/ - Computer vision (opencv): https://docs.opencv.org/master/…
Earlier quoted context omitted.
So, viral GPL FTW? Seriously, there's no shared libraries in compiled monolithic WebAssembly, is there? I think[1] that means included GPL code will require exposure of the source. Maybe if we're lucky some best practice will emerge that the source is often available as a sourcemap so companies don't have to worry about being sued for infringing the GPL. It sure would be nice to finally see an outcome of companies er…
What? There's absolutely no need for such companies to view this as anything more dangerous than the past. Nothing in the GPL says you have to be provided with a copy of the source along with the program. It also doesn't say the program has to come with a link to an online repository for the code. The GPL says that the code has to be provided when requested . So go ahead, contact the company and request the code. Alw…
What did I say that made you think that? I said the GPL requires exposure of the source, and maybe some best practices could emerge if we're lucky that might amount to it being easily available.
> Always cracks me up how many people think the GPL means "I get everything I want, exactly how I want it".
Interesting, as it always cracks me up when people decide to interpret statements in contorted, narrow ways just so they align with a pet peeve and they have something to rail against.
Earlier quoted context omitted.
Yet each of those steps solved a different problem. Early computers did not have the local processing power needed to run heavy jobs. Early PCs did not have the storage. WWW solved an entirely different problem, namely distribution and communication. JS et. al. solved the problem of responsiveness and interaction ie. latency. I don't really see those as exhibiting cyclical traits, at best I see it as a correlation ie…
> JS et. al. solved the problem of responsiveness and interaction ie. latency. You mean "introduced", right? Back before the modern web, when we all expected software to run on our machines , there was no responsiveness and latency problems, because data didn't travel over the wire unless it absolutely had to.
Earlier quoted context omitted.
That's basically what Chromebooks already are. I think it's the future too. The only problem is that it moves away from the "upgrade your device every X years" paradigm that makes consumer electronics manufacturers money. They'll have to switch to a subscription model and people may not like that (and personally I'm terrified of the alternative situation where a company would rather I give them my personal informatio…
> One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming. That would be great, if only we could make it not belong to Amazon or Google . Consider the same idea phrased like this: apartment complex have servers in their basement offering compute, and services you use work on those se…
Earlier quoted context omitted.
These things are cyclical: * Early computers (1960-1980s): Dumb Terminal - Remote Server * Early PCs (1980s-1995): Local Processing - Remote Storage * WWW (1995-2010s): Dumb Terminal - Remote Server * JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will…
That's basically what Chromebooks already are. I think it's the future too. The only problem is that it moves away from the "upgrade your device every X years" paradigm that makes consumer electronics manufacturers money. They'll have to switch to a subscription model and people may not like that (and personally I'm terrified of the alternative situation where a company would rather I give them my personal informatio…
Don't Chromebooks have ~4yr end-of-support lifecycles where they stop receiving upgrades?
Earlier quoted context omitted.
I don't understand this fear of webasm. Anyone can run their javascript through minifiers, or compile C++ to asm.js right now. Webasm doesn't move the needle of obfuscation much at all. The binary format can be turned into the textual ast representation directly. http://ast.run/
Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly. Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS.…
Also, I don't know how you think there's a noticeable difference of readability between minified asm.js and textual wasm for the average person. It might be more difficult for a programmer to read the wasm, but I can't imagine that "disassembled" asm.js is particularly readable in the first place (and both are completely incomprehensible to a non expert)
Earlier quoted context omitted.
> JS et. al. solved the problem of responsiveness and interaction ie. latency. You mean "introduced", right? Back before the modern web, when we all expected software to run on our machines , there was no responsiveness and latency problems, because data didn't travel over the wire unless it absolutely had to.
You can't download the entire internet. And loading a new web page every time you push a button is slow.
That said, what I meant is modern JS enabled moving into the web things that should have stayed local. It's literally two step backwards (moving software into "the cloud") and one step forward (giving back some responsiveness through AJAX).
We shouldn't. All the nonsense we're trying to cram into the Web is making it harder to justify connecting to it. I long for the days when simple images and text were the norm. Nowadays, I need to have and devote constant system resources to a tracking-blocker, cookie-blocker, an ad-blocker, a script-blocker, a separate javascript-blocker, and a who-knows-what-else-blocker, just to do the things I want to do; let alo…
Okay, say every browser had a built-in tracking, cookie, ad, script blocker etc. How would you propose websites then make any money?
Earlier quoted context omitted.
> One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming. That would be great, if only we could make it not belong to Amazon or Google . Consider the same idea phrased like this: apartment complex have servers in their basement offering compute, and services you use work on those se…
Let's imagine we could solve the easy problem of writing the software that is fully distributed to each complex and interacts with the software in any other complex. How do we solve the operations problem of running the machines in the complex?
Earlier quoted context omitted.
That’s not my problem to fix, no proposal is required of me.
Okay, then don't expect anybody to build one. Web browsers are incredibly complex, and nobody is going to build one for free nowadays.