peterwaller
Joined 14 years ago
Karma
494
Submissions
150
Member since
Jun 25
Recent submissions
Comment · 4 years ago
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.
Comment · 6 years ago
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
Comment · 7 years ago
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)
Comment · 7 years ago
Thanks for pointing this out, I fixed it.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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?
Comment · 7 years ago
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
Comment · 8 years ago
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.
Comment · 8 years ago
> 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? :)
Comment · 8 years ago
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".
Comment · 8 years ago
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.
Comment · 8 years ago
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
[email protected]