curveship

it's an emothickon

Check out the local TV interview of "Eric Ramen" :D : http://marc.merlins.org/linux/refundday/videos/abc.mpg

That's definitely 1999-era HTML and layout, except for the "This is an archived page" header, which is the only CSS on the page. The rest is all well-known tricks from the time: tables, image maps, a few embedded images. Heh, it even has the blockquote trick to pad the margins. Brings back some pretty horrid memories.

The term I've heard for this phenomenon is "mathwashing."

Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ...

... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.

So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.

I did get a $1k security bounty from Google, though, so that was cool.

Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736

Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.

From twitter user @XMPPwocky:

- each precinct got a PIN to report their results

- the PINs were printed on the paper result worksheets sent to precinct captains

- multiple precincts and participants posted pictures of their worksheets to Twitter, with the PINS clearly visible

- hence multiple PINs were compromised

https://twitter.com/XMPPwocky/status/1224563396873351169

Thanks for your perspective, very interesting.

I'm really surprised that all it takes to be declared qualified is the signature of someone else who's qualified. That leaves lots of room for slippage and social pressure, like the dip you mention. It also leaves no one specifically responsible for the crew's level of qualification. A cynic might say that was the point of the system: we know this is going to fail, so make sure no one is directly in the line of fire when the shit cannon goes off.

By "majority" he may have meant majority of Linux distributions, not majority of Linux users. There are a ton of distributions derived from Debian: https://wiki.debian.org/Derivatives/Census . All of them would have to update their distros to respond to Meltdown.

I really wanted Bourdain to become a salty, profligate old man, throwing barbs from behind a stiff drink and an ever-craggier face.

Sad news.

Here we go. We'll now have the first traffic fatality trial where it's not drivers-trying-drivers but people-trying-a-megacorp.

(Disclaimer: I'm a bike advocate, so I may have a different perspective on some of this than most.)

Our car-based transportation system is far and away the most dangerous thing any of us accept doing on a daily basis. 40,000 die a year.

But when cases come to court, everyone on the jury has in the back of their mind "that could have been me if I lost concentration at the wrong moment, or made one bad judgement, etc etc."

So penalties are comparatively light for traffic fatalities. Big punishments are only meted out if the case is so egregious -- repeated drug use, flagrantly reckless behavior -- that the jury can be convinced that the driver is different from them.

In other words, drivers don't get punished for doing something dangerous, because everybody on the road is doing something dangerous. They get punished for doing something more dangerous than the norm.

In this case, there's no question that the "driver" is different than the jury -- it's a computer. Now the symmetry that made jurors compare themselves to the accused is broken.

The result, and what self-driving car advocates don't get, is that self-driving cars don't just have to be safer than human drivers to be free of liability, they need to be safe period. In a trial, they don't benefit from the default "could have been me" defense.

That's a HUGE requirement. In fact, it's probably impossible with our current road system. It won't just take better self-driving cars, but better roads and a major cultural change in our attitudes about driving.

As a bike advocate, I welcome this shift, but I also see how deluded many of the current self-driving projects are. Software moves fast, but asphalt and mentalities move slow. We're not years away from a self-driving transportation system, we're decades.

And this trial is just the beginning of that long story.

Perl 6 feels like what happens when your answer to all bike-shedding questions is "both!" and your answer to the follow-up question "how will we tell them apart?" is "we'll add a secret codeword."

Still, I have to love the fun some Perl coders feel in their language.

That's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.

.find() and .findIndex() are new in es6, but the others are all es5.

Just throwing my side project, Surplus, out there as another example of this strategy (https://github.com/adamhaile/surplus). Surplus compiles JSX into optimized code that produces real DOM elements. The combination of an ahead-of-time compiler plus no virtual DOM layer means that the runtime code only has to do the minimal, truly dynamic work.

As a result, Surplus is the fastest framework in Stefan Krauss's latest js-framework-benchmark (http://www.stefankrause.net/wp/?p=431).

DSLs are powerful, compiler support can make them fast.

US divorce rate is lower than it's been for 40 years.

>> much, much faster to load

> I would love to see some data backing it up.

In Stefan Krause' js-framework-benchmark, the vue implementation starts in 55ms vs 89-113ms for the various react implementations. See the 'startup time' row here: https://rawgit.com/krausest/js-framework-benchmark/master/we...

I haven't profiled vue and react on this particular benchmark, but I have done so for some of the other implementations. Baring anything exotic during startup, the 'startup time' benchmark comes down to package size. It takes time to fetch, parse, compile and load javascript. React is just a bigger package.

All disclaimers about benchmarks, microbenchmarks, n=1, YMMV, etc apply.

Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are no out of bounds indices (which, as you say, could be wrong). The second will require you to always check the result of array dereferences to see if they're undefined before you reference the object.

  var foos1 = [] as Foo[],
      foos2 = [] as (Foo | undefined)[];
  
  // ... later
  
  var foo1 = foos1[i],
      foo2 = foos2[i];

  foo1.bar(); // types fine, TS assumes non-undefined
  foo2.bar(); // TS type error, as you haven't checked undef
  if (foo2) foo2.bar(); // types fine, undef excluded

The TypeScript team's philosophy* is that they want to incorporate features that have either ~0% or ~100% chance of making it into ES. Types they put in the 0% bucket. Once a feature is near 100%, they'll include it. But if it's only at, say, 60%, it doesn't make the cut, for fear that it will change before standardization, leaving TypeScript in the "annoyingly different" situation you describe.

* - [edit: found the source] "We'd really like to hit features that have either a ~0% chance of making it into ES7+ (e.g. type annotations), or have a ~100% chance of making it in with easily-defined semantics (e.g. where fat arrow was two years ago). New operators are likely to fall in the awkward middle." [https://github.com/Microsoft/TypeScript/issues/16]

BTW if you're curious, browser DOM operations have advanced now to the point that doing work in dom fragments is often slower than just doing it right in the main tree. See, for instance, one of the recent optimizations to the vanillajs implementation of js-framework-benchmark: https://github.com/krausest/js-framework-benchmark/commit/2e...

If I understand what Glimmer is proposing, they want to slice a long update process into a set of batches, so that they can pause in the middle to let the browser render a frame. My points were that a) they don't know how long it will take the browser to render that frame, so it's hard to say when to cut off the batch, and b) rendering intermediate states might increase the overall work, sort of a classic throughput vs latency tradeoff.

Paint and composite are usually fast, but calculate styles, layout and hit test may not be. It totally depends on the complexity of the DOM and CSS, of course, but as an extreme example, the js-framework-benchmark tasks are often 90+% time in render. That's why the results converge on 1.00: 0.95 of that is time spent in the browser rendering the DOM, and the time spent in javascript between a framework at 1.00 and one at 1.05 may be 2x difference (0.05 vs 0.10).

Yeah, I was just looking at the Glimmer opcodes format. I'm a bit surprised it's an array of arrays, rather than a flattened array. It looks like it goes `[[1,"id","bar"],[2,<other param>],...]` rather than `[1,"id","bar",2,<other param>,...]`. Wonder why? Monomorphism, or faster dispatch by not having to pass a pc index around? Interesting.

The `a(e,"id","bar")` format is what other frameworks produce. It sounds like in Glimmer it would be `[1,"id","bar"]`. So that's only a single char savings.

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute.

There's really not much noise in that expression, just the "(,,)", so maybe 4 chars that an opcode could save.

As for 3), is that really possible? If you profile most modern frameworks, they're already fast enough that most of the time is spent in rendering, not in javascript DOM manipulation. So even if you cut short your js before 16ms (60fps), you have no idea how long the browser is going to take to render your changes. Plus, the browser will be doing extra work, since it needs to render all the frames in which you've only done part of your updates.

Ah, my bad. Are you aware of any benchmarks comparing v8 to LuaJIT? Looks like LuaJIT got removed from the alioth site (?).

There's a branch of node, vee-eight-lkgr, running the new v8 5.8 compiler chain. You can read about how to try it out (and help test it) here: https://medium.com/@bmeurer/help-us-test-the-future-of-node-...

> multiple times faster

You sure about that? In the alioth benchmarks, v8 wipes the floor with lua: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

I can see how this proves that 20 is possible, but not that 20 is the largest possible, which is what the question asks. How would that be proven?

The difference is that cheap Dutch bikes are super simple: no gears and a coaster brake. The Walmart bikes aren't. They've often got 21 speeds, shocks, etc etc, all of which is pure crap and fails after minimal use.

There's also the infrastructure to consider. If your bike fails in NL, you curse and coast to a stop on the bikeway. If it fails in the US, you may be in the middle of trying to cross a 6 lane road with no bike infrastructure whatsoever, putting your life in danger. I rode a crappy bike in NL (3 month stay in Rotterdam), but I wouldn't want to ride that same bike here in the US.

I can't seem to find any info online about $MapObj<>? I searched the docs, google ... nuthin'. Am I just missing something?

It's not much, but the code redirects the user to a 'member.php' page after 2 seconds. So whatever the target was, it probably had a member.php page.

Just FYI (not flaming Firefox), it's a standard setting in Chrome.