curveship · HackerTrans

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.

curveship

6 年前議論

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

curveship

6 年前議論

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.

curveship

6 年前議論

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

curveship

8 年前議論

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.

curveship

8 年前議論

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.

curveship

8 年前議論

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.

curveship

8 年前議論

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.

curveship

9 年前議論

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.

curveship

9 年前議論

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.

curveship

9 年前議論

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

curveship

9 年前議論

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.

curveship

9 年前議論

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

curveship

9 年前議論

>> 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.

curveship

9 年前議論

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

curveship

9 年前議論

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]

curveship

9 年前議論

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...

curveship

9 年前議論

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).

コメント