AshleysBrain

> Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase.

> Recent reports that these exploits are caused by a “bug” or a “flaw”

[Unprivileged] reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.

> any performance impacts are workload-dependent, and, for the average computer user, should not be significant

Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...

> However, Intel is making this statement today because of the current inaccurate media reports.

This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.

Hi everyone, our browser-based game editor Construct 3 is completely free for the next two weeks for the Newgrounds/Construct gamejam - the theme is "Good things come in threes". Would welcome any feedback on the editor! Links to full announcements:

https://www.scirra.com/blog/206/its-time-to-jam

http://www.newgrounds.com/bbs/topic/1423023

As far as I can tell it's just a web view wrapper for desktop. It's missing all the node features that Electron or NW.js add, which makes me wonder... why not just run it in a browser like normal?

We took the same bet with CSS grid, and it paid off. Lots of features can make a massive improvement to the development experience. We used a wide range of experimental features starting around 2014. Most of them came to fruition. HTML imports has been the only tricky one so far, which I think is a pretty great result on all the bets we took.

Perhaps I should have added another qualifier: for a team of three developers. (One initially.)

No, HTML imports are the kind of technology that are the perfect architecture for this kind of web app and arguably are what make it possible. It'd take a whole blog post to explain, hopefully I can write it up soon!

Layout performance is the biggest problem probably - when things change the browser too often does a full layout of the document. We use tons of CSS containment but there are still bugs where Chrome does far more layout than necessary, e.g.: https://bugs.chromium.org/p/chromium/issues/detail?id=667370

Virtual DOM is completely unnecessary to us. We have minimal problems with DOM calls. It is all to do with layout performance, and VDOM makes no difference at all there.

You just need Chrome 57+ which is already on the stable channel. Just go to Help -> About Google Chrome and it should work.

We can potentially polyfill them - we're waiting for dialog element support first, that's still holding back support in most other browsers. HTML imports are outrageously under-valued as a technology for building this kind of web app. We're hoping to do some blog posts highlighting how awesome they are and try to turn around opinion on that.

Sorry folks, we only launched yesterday, if you happen to see a 404 message please just visit: https://www.construct.net

CSS grid was the main reason: it's new in Chrome 57 and we use it heavily!

Sorry about the 404, shouldn't happen to everyone but we're working on it...

57 is already stable so just check in Help -> About Google Chrome!

Template strings look like a better way to do JSX, imo: why can't html`<p>Hello world</p>` be made to return the DOM element for the p tag?

I think consumer software has so much to gain by moving to front-end web tech, we bet our next product on it: https://www.scirra.com/blog/184/a-first-look-at-construct-3

It's important to download JS-generated data as well, such as something in a Blob. You can't set a HTTP header on local content. The 'download' attribute lets the user "download" that without having to wastefully post it to a server and back.

I'd say that if the user is using a private browsing mode, they are explicitly indicating to the browser not to store anything, and they will know that will happen. It's the whole purpose of the feature, so I don't think it counts as "silently" doing anything. I don't think there's any reason to then potentially break web pages that (quite reasonably) expect storage APIs to work.

This is a great library. It's simple but flexible. You can treat it like async key-value storage but it has extra features like using different databases, all while handling the details of IndexedDB, WebSQL or localStorage support.

Ideally these libraries will fall back to in-memory storage, which is lost when you navigate away, but keeps pages working when they expect to be able to write then read back a value in the same page.

Some browsers like Firefox throw exceptions when you try to touch storage in private browsing mode. This can be super annoying since it tends to break pages that use storage and haven't been specially tested in that mode in that browser. A library-based memory fallback helps avoid that. AFAIK it's what Chrome does with storage in incognito mode: just save calls in RAM, return them if asked for, then throw it away when navigating.

There's a PR to add this for localforage but it's been stuck in purgatory for a while and seems to have some resistance despite the utility: https://github.com/localForage/localForage/pull/555

I imagine the big problem is anything depending on user input, which is unpredictable. Then the unpredictability probably propagates a long way through the program.

A simple example would be something like `x = (isUserOnMars() ? "foo" : 1)`. The type of `x` depends on if the user is on Mars. In practice they never will be, but a compiler can't tell that and so must consider that case and make code appropriately generic. A JIT however can see that it always appears to be false, and optimise around `x` tending to be a number, with bailout if it's wrong (which it likely never will be). Then the use of `x` may propagate a long way through the program in all sorts of places, extending the effect.

Can you explain how you would optimise an expression like "a + b" at compile-time when the types are ambiguous? Surely you have to fall back to generic code, which is slower than a JIT that can observe that both types are e.g. a number and emit the ideal instructions for it.

Seconded. An "offline" compiler can't use things like the type information gathered at runtime. So I'd expect this to actually be slower than JITs. Benchmarks should be provided before making performance claims!

Exactly, the appeal of P2P is you don't need to run servers. And it seems like a reasonable feature to allow browsers to reliably host multiplayer games.

Minimising still suspends. And IMO pop-ups are slightly user hostile compared to just staying in the tab.

No, we run our own signaling server and wrote the connection establishment parts ourselves. The client ends aren't that complicated in that regard.

We've been using WebRTC Datachannels for multiplayer gaming in the browser in our game editor Construct 2 (www.scirra.com) for a couple of years now. Generally they work great! However the main problem we have is switching tab suspends the game, which if you're acting as the host, freezes the game for everybody. This is really inconvenient. There ought to be some way to exempt tabs with WebRTC connections from being suspended. I filed a bug for it here: https://bugs.chromium.org/p/chromium/issues/detail?id=676036

I have a large existing C++ codebase but haven't worked in Rust yet. But from what I've seen, Rust looks like a very well designed language that has the low-level and performance aspects of C++, with similar flexibility. IMO the killer feature is the borrowing mechanism which provides provably-safe memory access, eliminating whole classes of memory/security bugs, with minimal performance impact. I don't think C++ will ever expand to encompass that. I haven't got much experience with the Rust toolchain but I think that's a strong reason to seriously consider Rust for any new projects.

HTTP/2 out of the box with a free download is a great reason to use it over nginx. Are any performance comparisons available though? I suspect nginx's maturity may make up some of the difference.

If you can't reproduce it reliably and it's kind of rare... isn't that enough to explain it? :P First thing you need in a bug report is a reliable way to get it to happen!

Also having read Raymond Chen's "Old New Thing" blog for a while, it's very common that some third party software/extension does something insane with the desktop window and breaks things. It could be something like that. Can you reproduce it on a completely empty fresh install of Windows?

Yeah, I think locking down the private browsing/incognito modes is a good compromise. Things like the battery level, WebGL render string etc. (anything that can be used to improve tracking) could return fake data in incognito mode, but real data in normal mode. IMO that's the best compromise between "keep my information private" and "things work usefully by default". I don't know if browsers already do that though?

I should have specified - we build desktop software! But I think the principle of "don't ask the user questions they can't answer" still stands.