STRML

Why is obvious marketing material allowed here?

This is quite dramatic, in that I can actually feel my Macbook not heating up as much, nor can I hear the fans anymore.

We do quite a lot of work on a trading website that has heavy use of Canvas and CSS animations, and the latter really kills performance. Two runs on our production website from Intel Power Gadget, pre and post upgrade, show decreased temperature, a lot fewer power spikes, less DRAM wattage, lower GFX clocks, and about 40% less power overall:

Before: https://i.imgur.com/WkdWaHx.jpg

After: https://i.imgur.com/3ojMyjT.jpg

It's legacy. This dates back to April 2015 when there were still some reasons to use prefixed properties. Rather than list all of them in css - which would have been ugly - I choose the one useful to your browser.

They don't have any actual inside information about the Taycan, so they switch to talking about the ZF transmission.

This is only true on the Model 3. Indeed, on the S, the dual-motor variants were more efficient due to different gearing. It is still unclear the community why the 3 dual motor variants are as much as 10% less efficient. It is not totally accounted for by weight, and the extra induction motor should be capable of torque sleep.

And in fact, something called "money.js" - or the successor to money.js - ought to be able to properly round decimals such that floating point error never becomes the developer's concern.

JS, like Java, now has implementations that will also store strings as Latin1 when the implementation believes it is safe to do so. This results in significant memory savings [1] in most programs.

1. https://blog.mozilla.org/javascript/2014/07/21/slimmer-and-f...

As in the MDN article:

    All major engines have also implemented corresponding trimLeft and trimRight functions - without any standard specification. 

So ES2019 implements trimStart() and trimEnd(), which are symmetrical to padStart() and padEnd(), but trimLeft() and trimRight() aliases are maintained as not to break working code.

It's a lot more verbose than _.mapValues() is, but it's nice to have a relatively simple solution without using a library.

Re: Haptic feedback on the touch bar, see https://github.com/niw/HapticKey, which is surprisingly good despite being a massive hack.

That's what WebKit's devtools look like, across all branded browsers. Blink stayed with the old layout and iterated on it.

I don't really care which one I use, but change for changes' sake is frustrating. I'm used to Blink/old Webkit and I don't see any reason to learn a new layout.

Incredible pitch, I wish you luck. This would be an amazing alternative to batteries in areas where there would otherwise be renewable over-capacity. While it appears less efficient, it is transportable and easy to store.

Please keep us all updated on how it goes, I'm sure you will see a lot of excitement about what you are doing.

It was very successful. Complicated projects require complicated build config. Parcel does fine for simple projects, but lacks the raw power & configurability of webpack.

Webpack now does simple config as well with the 'mode: "production"' and 'mode: "development"' presets.

Scoping dependencies to their author by default would help (not eliminate) this problem.

For example, if this had been @dominictarr/event-stream the entire time, and he chose a new maintainer, that would then by definition change the name of the package to @right9ctrl/event-stream, requiring all users to intentionally change their dependency.

Yes, it's painful. But it prevents getting caught out by a malicious patch release.

That said, the whole github/npm relationship is broken to begin with. No simple mechanism exists that I'm aware of to verify that a tag as pushed to GitHub is exactly the same as what is published to npm. And due to various prepublish hooks, it can be very difficult to actually prove this. One solution would be GitHub support for building & publishing packages, with a Travis-like build log, so users can be assured that the package as it sits on npm actually was built from expected source.

@right9ctrl could have just avoided committing this entirely, and just published a malicious patch release. If he had done that for a few days then published another that removes the injection, it might have gone unnoticed for months.

> It is unclear what he means by "If your system clock jumps from one time to another...". If this is talking about NTP, it's probably accurate.

I don't know what he's talking about either. Most popular NTP clients (ntpd, chrony) will try very hard to make sure this never happens by simply slowing down or speeding up time. You don't know what will break if you just gap time like that.

FWIW, this is something U2F somewhat solves. There is still the following exhaustive list of problems:

1. Education for and purchase of U2F keys 2. Key loss recovery mechanism 3. Key stolen defense (you can't just rely on the U2F key alone, there must be a pw or other type of second factor) 4. Widespread browser & device support (without it, a user/pass is required as a backstop)

Nevertheless, it is progress.

There's nothing about <keygen> specifically that requires a central signing authority. You could just as well generate a public/private pair, feed the website your public key, and sign challenges with the privkey to log in.

In a certain sense this existed with the `<keygen>` element (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...) which is unfortunately deprecated. But you still have all the same issues of moving and safeguarding key material.

These days with browser/mobile sync, maybe it's actually possible. But like a synced password manager, it makes a primary account breach that much more devastating.

This was written in 2014, when Crankshaft was still the JIT in V8. Turbofan was shipped in late 2016 and made primary in 2017. It's a much better JIT - it is tolerant to many more code patterns, including ES6 features - but IRHydra2 no longer works with Turbofan, so this type of introspection is more difficult to do.

A few years ago I hand-tuned some kdb+/q interop code on Crankshaft using IRHydra2 and d8. The results were impressive: about 10x by just shuffling code around to be friendlier to the JIT. It was fun, but more than a little mysterious.

Tuning on Crankshaft was all about avoiding bailout (https://github.com/vhf/v8-bailout-reasons/blob/master/README...). Tuning for Turbofan is less about "gotchas" and more about making sure your functions don't go megamorphic. Using TypeScript or Flow helps you do this just to get your code to typecheck anyway so it's a good habit.

As mentioned in this comment (https://news.ycombinator.com/item?id=15067462) there is still some minor analysis of the IR possible in IRHydra2 on TurboFan.

Anecdotally, the 2018 key travel feels better than the 2017. But I can't stand the touch bar even after a year with it.

While it's technically true, it's worth noting that part of the weight & thickness savings in the 2016+ MBPr was from simply reducing the battery from 99.5 Wh to 76Wh. I strongly dislike this change.

It still can on JS toolchains. There is multiprocess webpack (happypack) now, Flow threads really well, and the extra cores can even help when restarting a bunch of processes at once and live reloading. Shaving off even a second helps productivity when you do it dozens/hundreds of times a day.

This is just one of many vulnerabilities in Geth and other Ethereum clients due to unauthenticated JSON-RPC on localhost. You might recall this even hit Redis years ago.

There are many simple solutions (force auth, xsrf token) and it is mind-boggling that these mitigations are not considered standard-issue in the space.

That's not how converting relative Celsius to Fahrenheit works. If I say "it's 10 degrees Celsius colder today than yesterday", that's the same as saying "it's 18 degress Fahrenheit today".

That doesn't mean it can't be adapted and tuned for mobile. The average smartwatch has more processing power than the average server did at the time the ZFS project was launched (2001).

Some parens would at least make that more readable:

    const foo = {
      ...(bar && {bar}),
    };

FWIW, I tried that DoS idea on a little digitalocean machine. It capped the number of open file descriptors for the SSH daemon at 1024. Only about 3000 file descriptors were in use after it stopped allocating channels, and file-heavy operations like apt-get still succeeded.

For this reason, we don't use SSR for pages that change often, and turn it off completely for authenticated users. Some performance analysis showed it was actually slower in the average case than shipping the JS and having the client render it themselves, especially with a hot cache.

This still provides what we wanted anyway; the ability for pages to easily be viewable without JS and easily indexed by search engines.

The new S3 console/flow sets to private by default - so some progress there, all jokes aside.

It appears the specific issue is with an NLB in one subnet referencing a C5 in another subnet. It's useful to put the targets in a private subnet and the NLB in a public subnet, so this breaks usage for us.