peterwaller

It lets the hacker take over the machine because there are strings which are interpreted as (IIUC, I am not a java engineer) variables within a class, and you can express a remote URL to load a class from, apparently (through something like (jndi://... ldap... URL), resulting in fetching code from somewhere and running it, in the service of writing a log message. This is apparently being exploited in the minecraft ecosystem by simply writing chat messages containing the full exploit, which gets executed by both servers and clients.

Nice hint, thanks :)

According to the manpage, -color can be shortened to -c and link shortened to `l`, as `addr` can be shortened to `a`. -br stands for -brief, which knowing makes it easier to remember.

  ip -br -c a
  ip -br -c l

Now I need the aliases less.

I agree with nhooyr's analysis. The interface{} will anyway transparently "contain" a pointer-to-the-[]byte, in other words, the []byte value itself will be heap allocated.

(Note for anyone new to this that the "[]byte-value" - we say "the byte slice" - is a distinct thing from the "values stored-in-the-byte-slice", which is a heap allocated backing array)

Thanks for pointing this out, I fixed it.

Unfortunately there isn't a recording, sorry!

What you're seeing is the LLVM IR for the program being printed. As another commenter noted, you can compile the program with make, which just runs `clang` on that IR.

Indeed, I had to take certain liberties in order to cram the talk into 20 minutes! I hope one of the takeaways was that you don't need to implement a parser to get started playing with this sort of thing.

I suppose I was musing more along the lines of "why isn't this a solved problem". Clearly, it isn't an easy one or compilers would already take this into account and then the statistical variance would be reduced.

Great, we can control for layout of code, heap, stack and other effects which mess with a performance measurement. However, why do those things have a (statistically significant?) impact in the first place? I guess that hints that with some engineering you could in principle get a speed boost by specifying the layout. "Worst case", you sample randomly and then pick the fastest arrangement, where it is statistically significant.

It could be that the problem arises when trying to measure very small speed increases (small relative differences => noise matters more). But in that case the fact that such a small speed increase is wiped out by random layout effects surely means that time would be better invested in finding a more performant layout?

Mutation testing is a neat idea I'd not heard of. Wonder how well it works in practice.

Someone's implemented a package for doing it with Go which looks good: https://github.com/zimmski/go-mutesting

Just discovered this tool while doing a messy rebase, and can't believe it has had very little discussion I can find.

https://github.com/mhagger/git-imerge

No previous commentary on it so far on HN:

https://hn.algolia.com/?query=git%20imerge&dateRange=all

So, can anyone find any interesting discussion about this tool?

If you'd prefer reading rather than listening to the talk, here's an article which covers some of the same concepts:

https://wilsonmar.github.io/git-imerge/

The crux of it is that the tool does an efficient pairwise merge of all commits from the donor branch onto master. It can also be configured to run the test suite to detect conflicts.

Then you resolve conflicts in pairs of commits, which is only a small amount of work. The histories of your individual resolutions are preserved, so you can pause and resume the task.

> you write code (like in the example here [1]) that is bound to be slow, just from a glance at it > [1] https://git.embl.de/costea/metaSNV/blob/master/metaSNV_post.....

Given his code you referenced, could you elaborate on what makes it look slow at a glance, and how you might speed it up? :)

At this point in that video, some minutes after the loss of signal, you can hear on the countdown net https://youtu.be/-B_tWbjFIGI?t=42m21s - it's garbled but sounds like "Suspected loss of signal".

Agree it is strange. I love their "How Not to Land an Orbital Rocket Booster" film. https://www.youtube.com/watch?v=bvim4rsNHkQ

Watching the countdown net it seemed plausible that they didn't know whether it had successfully landed either.

Of the centre core, these are the last few moments before it is lost from the feed. Smoke can be seen...

https://youtu.be/wbSwFU6tY1c?t=38m20s

... and then back to the presenters. As someone said to me, "That's their lying face!" :)

Can't fault them for wanting to dwell on the positives though, was an amazing moment to watch.

Edit: You can switch cameras on the above youtube video to the countdown net; you can clearly hear them saying "We lost the centre core" at 38m30s - not sure if that means "lost signal of" or otherwise. The people in the control room appear to become more muted at that point, though they still seem composed. It's really not clear.

Edit: On the countdown net you can hear some minutes later "suspected loss of signal": https://youtu.be/-B_tWbjFIGI?t=42m21s

He's a maintainer of bcache, not of block layer, where the problematic patchset was introduced.

I'm amused by "Please contact administrator for more information".

... "But I _am_ administrator!?"

Your posting here says "REMOTE", but the job posting says "Requirements: ... Work in San Francisco".

I'm confused what the connection is with Chernobyl.

But 2M deaths in the last 30 years is not likely correct - this interesting WHO report on the matter suggests the final toll from the radiation would be more like "up to 4k":

http://www.who.int/mediacentre/news/releases/2005/pr38/en/

http://www.who.int/ionizing_radiation/chernobyl/chernobyl_di...

> The main causes of death in the Chernobyl-affected region are the same as those nationwide — cardiovascular diseases, injuries and poisonings — rather than any radiation-related illnesses

> I thought the USA had a civil war to end the kind of thinking you are representing

I think you're over-reading the phrase "How do you reach this conclusion?". The author didn't suggest that it was necessary, only that they were interested in seeing your reasoning. The world is a complicated place, so it can be reasonable to assume a default position that either thing is possible.

I just see a black screen. Icon in top left, no text other than "Login" and "Sign up". Chrome 58, Linux. No errors in the dev console.

> Oddly, sea level will probably go down this far north. Earth is spinning, drawing water to the equator. More mass, more gravity pulling water to the equator, along with less mass at the poles to offset.

Can you provide a reference or show some workings which demonstrate that statement to be true? I've not heard this before, and it's not obvious that it should be true.

Interesting video of Moller himself talking about it (while sitting in one of these cars):

https://www.youtube.com/watch?v=gOR_SzLW2Ns

There's some grainy test flight footage at the end, too.

While I agree readability is key, you may find people who disagree about what constitutes "readable". I think the Go community in particular may be partially inspired by the philosophy outlined under "Variable names" in Rob Pike's "Notes on Programming in C":

https://www.lysator.liu.se/c/pikestyle.html

Quoting:

"Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn't be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it's harder to see what's going on."

I don't agree with everything written therein, and it was written circa 1989. But in practice single letter variable names are used diligently and frequently in Go, they're convenient and don't break readability if you understand the (simple) convention.

He's referring to it as a type qualifier, I would assume.

https://en.wikipedia.org/wiki/Const_(computer_programming)

SPF has another problem. I sent an email to someone recently @theirdomain.com. I subsequently saw by chance that the email was rejected because they were hosting @theirdomain.com with a random ISP but they had configured the mail to be forwarded to a mailbox in @gmail.com.

Gmail sees the email coming from @theirdomain.com's servers, rather than my server. Gmail checks the SPF record which doesn't match, and it rejects it.

I understand that this style of forwarding is anyway bad because gmail see's all email the user receives @theirdomain.com as coming from those servers, not their true origin. If @theirdomain.com receives (and forwards) any spam, it looks like a spammer to gmail.

Reminds me of the turing complete interpreter lurking in libc's printf.

https://github.com/HexHive/printbf

This is a work of art. :)

You might have to wait a while on the encoding side. It's taking a minute a frame to encode here! :)

I did this a couple of months ago and got a >5x speedup. It's at the expense of dropping quoting though, so no commas or newlines can be in the input data.

https://github.com/pwaller/usv

My emojis look weird and not in keeping with the style of emojis elsewhere on the site http://imgur.com/rB9BdEr