I am sort of wondering whether it wouldn’t be possible to just ship a 32 bit x86 executable instead of amd64, then the 32 bit tricks could potentially be pulled. Since it doesn’t seem to need any libraries it wouldn’t incur any additional dependencies I think.
I thought he was using 32-bit already? On my system, __NR_pause is defined to be 29 (his number) in asm/unistd_32.h, and 34 in asm/unistd_64.h. He’s also using eax over rax… Perhaps using int 80h and not syscall uses the 32-bit abi?
It seems like these “X implemented in Y” and “Z in N bytes” types of posts/articles have become increasing common the past few years. These things can be great learning experiences I suppose, and the “wow” factor can vary. But it makes me wonder if it’s a symptom of something larger, like are people not doing (as much) original stuff now?
It’s interesting. There was certainly a lot of low hanging fruit to discover and invent in the early days of computing. That’s not to say it was easy, but as that low hanging fruit has fallen, the difficulty level has increased to creating something truly original and new. You can peel existing fruit in a new way (which so many people do), and you can combine multiple pieces in new ways, but it’s pretty hard to go beyond the lower branches, and most people don’t have the time, patience, or need to do so.
Keep in mind that PhD programs last years, and yet, very rarely do they surface with research that has a lasting effect on industry, or, it’s so cutting edge that it’s not practical for many years later.
So what’s an average person to do for fun? Well, you can reinvent stuff you already know! Maybe you rewrite it smaller, faster, stripped of “bloat,” or with new features. Maybe you apply the ideas of an existing tool like, say, AWK, to a new data type, say, JSON, and invent jq. Maybe, instead, you make JSON work with the tools you already know by writing an adapter to make it more greppable. All these things are just new peels, or new cuts of the low hanging fruit though.
And maybe, just maybe, you’re just up for a challenge that sounds ridiculous. “Is it even possible?” The average Docker image, even with the nesting (there’s a better term which I can’t think of), is still large. It’s an absurd, but challenging idea, to fit an entire docker image in a tweet (which hasn’t been done, mind you. But holy crap, how cool would that be?). But, if you manage to do it, and even if not, you’ve probably learned a new way to peel existing fruit, and that might be applied to a the construction of a reach extender that gets you closer to the top of the tree.
I’d also push back on the idea that such articles aren’t original/novel/innovative. There’s two distinct kinds of novelty here: getting something working that does something new, and packaging things up better so they can be used by everyone rather than just insiders. Both are equally important, and the latter is what it took to turn Roman-era cataphracts into medieval knights.
I’m not sure if you’re pushing back on me, or the OP that I responded to. I’m completely in favor of these types of experiments as I believe them to be fun, interesting, and useful in the generation of new places to explore.
We may have different ideas of what “new” is though, but that’s OK. :)
Bit of a counterpoint: I find the “Z in N bytes” stuff to be pretty informative about learning about Z
Loads of these tiny docker experiments have really helped to clarify (at least for me) what Docker is and what it isn’t (not a VM). Some valuable stuff to be learned in there I think.
X implemented in Y is a bit less of this, but it can also be helpful if someone understands Y more than X.
I am sort of wondering whether it wouldn’t be possible to just ship a 32 bit x86 executable instead of amd64, then the 32 bit tricks could potentially be pulled. Since it doesn’t seem to need any libraries it wouldn’t incur any additional dependencies I think.
I didn’t think of trying that…
I thought he was using 32-bit already? On my system,
__NR_pauseis defined to be 29 (his number) inasm/unistd_32.h, and 34 inasm/unistd_64.h. He’s also usingeaxoverrax… Perhaps usingint 80hand notsyscalluses the 32-bit abi?int 0x80is definitely the 32 bit Linux system call entry point.To be honest, my knowledge of assembler is minimal and even that is 20 years out of date…
It seems like these “X implemented in Y” and “Z in N bytes” types of posts/articles have become increasing common the past few years. These things can be great learning experiences I suppose, and the “wow” factor can vary. But it makes me wonder if it’s a symptom of something larger, like are people not doing (as much) original stuff now?
Also that we take bloat for granted in the tools we use.
It’s interesting. There was certainly a lot of low hanging fruit to discover and invent in the early days of computing. That’s not to say it was easy, but as that low hanging fruit has fallen, the difficulty level has increased to creating something truly original and new. You can peel existing fruit in a new way (which so many people do), and you can combine multiple pieces in new ways, but it’s pretty hard to go beyond the lower branches, and most people don’t have the time, patience, or need to do so.
Keep in mind that PhD programs last years, and yet, very rarely do they surface with research that has a lasting effect on industry, or, it’s so cutting edge that it’s not practical for many years later.
So what’s an average person to do for fun? Well, you can reinvent stuff you already know! Maybe you rewrite it smaller, faster, stripped of “bloat,” or with new features. Maybe you apply the ideas of an existing tool like, say, AWK, to a new data type, say, JSON, and invent
jq. Maybe, instead, you make JSON work with the tools you already know by writing an adapter to make it more greppable. All these things are just new peels, or new cuts of the low hanging fruit though.And maybe, just maybe, you’re just up for a challenge that sounds ridiculous. “Is it even possible?” The average Docker image, even with the nesting (there’s a better term which I can’t think of), is still large. It’s an absurd, but challenging idea, to fit an entire docker image in a tweet (which hasn’t been done, mind you. But holy crap, how cool would that be?). But, if you manage to do it, and even if not, you’ve probably learned a new way to peel existing fruit, and that might be applied to a the construction of a reach extender that gets you closer to the top of the tree.
I’d also push back on the idea that such articles aren’t original/novel/innovative. There’s two distinct kinds of novelty here: getting something working that does something new, and packaging things up better so they can be used by everyone rather than just insiders. Both are equally important, and the latter is what it took to turn Roman-era cataphracts into medieval knights.
See also Carlota Perez’s notions of installation and deployment phases for a new technology.
I’m not sure if you’re pushing back on me, or the OP that I responded to. I’m completely in favor of these types of experiments as I believe them to be fun, interesting, and useful in the generation of new places to explore.
We may have different ideas of what “new” is though, but that’s OK. :)
Yes, the ‘also’ was intended to convey that I thought we were mostly in agreement. What words we choose for the categories is less important.
I responded to you in hopes that both you and @markt would see my comment.
Thanks for the clarification. I thought that might be the case, but whether it’s exhaustion, or something else, I couldn’t tell for sure.
For my part, I’m often too terse when tapping out comments on my phone.
Bit of a counterpoint: I find the “Z in N bytes” stuff to be pretty informative about learning about Z
Loads of these tiny docker experiments have really helped to clarify (at least for me) what Docker is and what it isn’t (not a VM). Some valuable stuff to be learned in there I think.
X implemented in Y is a bit less of this, but it can also be helpful if someone understands Y more than X.
I got it a few bytes smaller by using Nix instead of Docker to build the image:
932 bytes, instead of 976.