It feels like most of the Founder-type people are taking a break from what they usually do at work -- which probably includes checking hacker news. So it's left room for the more interesting things to surface over the "What happened to <javascript framework>" or "How to raise your yearly gains by five dollars" or whatever.
edit: Interesting is a personal taste, and while I have noticed articles on hacker news becoming more repetitive lately, it's probably not fair to put it entirely down to "Founder-type people".
We had a new hire who was huge into HN a while back. Was very hard to rein him in from suggestions of haskell, random frameworks, etc. I've dealt with the "shiny things" mentality many a time, but this was something else. Made the "academic do it right" approach look liberal in terms of risk.
Haskell is cool, but yeah sorry keep that out of my prod stack.
TBH, if I recall correctly, something similar happened already in the past just by pure coincidence. I'm pretty sure somebody somewhere already experiments with self-porting AI malware.
The only instance somewhat like this that I am aware of is that two malware samples sort of 'recombined' accidentally.
One was a worm that packaged itself up and sent itself around, the other did some sort of injection or binary patching and happened to piggyback onto the worm.
It refers to things like software that reads documentation, reverse engineers code running on the target system, works backwards from the target CPU manual and compiler toolchain to make object code that runs on the CPU, and generally does what a human does when porting code to run on another system possibly without a compiler and take advantage of flaws on the target.
I think we're half way there already, because of the number of tools for decompiling and code scanning for security vectors these days, the increasing use of fuzzers to discover unintended or undocumented features, including hardware features like undocumented instructions, and increasingly clever and subtle side-channel attacks for finding device state that is not supposed to be visible to software.
Also, if it can happen by accident then I don't really think it should be called "porting". You don't find that a linux-centric malware has "accidentally" "ported" itself to windows, likewise Intel bytecode doesn't suddenly execute on ARM chips.
The difference between "porting" and "modifying" has (at least in everything I've read in "hacker" culture) always been that porting is rarely a trivial act.
I suppose in theory malware that targets dev tools and source to infect compiled code could end up getting ported along with it’s target. More hitching a ride than porting itself though.
I realize you’re joking, but it’s possible. Learning compilation targets is an active area of compiler research with some promising results in the past year or two.
It's absolutely framebuffer here. Games that draw directly to the framebuffer. I assume they meant sprite-based games that don't require 3D drivers, for example.
Are the Linux tests deterministic, and the tests for this change will not run unless something directly affects it? If not, then I’m not a huge fan of these commits, which seem more about vanity.
> Most importantly, because I can.
Good. All I can say is at least it is something different to what I keep seeing on HN. (React, Rust, Kubernetes, JAMstack, JavaScript, etc.)
Probably present this somewhere in a conference (CCC, FOSDEM, etc). Who knows who could be looking at this.