31–40 of 309 posts
Interesting point about the x86-64 patents expiring and the possibility of third parties making chips for that instruction set. Is it just so big and clunky that the energy is with ARM / RISC-V?
Finally, you can produce a single cross-platform executable in C. > we've basically reconfigured the stock compiler on Linux so it outputs binaries that'll run on MacOS, Windows, FreeBSD, OpenBSD too. They also boot on bare metal
Is hosting web URLs at storage.googleapis.com a thing? After finding a persistent phishing campaign using it, I ended up restricting it from being loaded in the web browser in my environment. (Embedded images from it, like on blog.google, still work.) This is the first time I've seen a legitimate website with one of these URLs.
> I believe the best chance we have of doing that, is by gluing together the binary interfaces that've already achieved a decades-long consensus, and ignoring the APIs. Yeah, this isn't going to fly for OpenBSD, which doesn't have ABI stability, programs are expected to use libc. Program for the API, not the ABI. The author is clever, but misguided.
> Bell System Five is the umbrella term we use to describe Linux, FreeBSD, OpenBSD, and Mac OS X which all have nearly-identical application binary interfaces that stood the test of time, having definitions nearly the same as those of AT&T back in the 1980's.
However, only Linux guarantees stability at this level so I too am very sceptical that this will "stand the test of time". And of course this completely excludes Windows.
"Need cred or accessibility? Nerd cred! Screw you if your eyes don't work!"
Incase anyone searches on hn.aloglia in future!
Back when all you had was minicom dialing a BBS, there was a chicken and egg problem where you needed uudecode to decode any executable you downloaded. If you did not have uudecode you were stuck. If you are unfamiliar, unencoding a file allows you to send binary data through text transmission. Then a clever version of a DOS .COM file was posted which implemented uudecode, but it only used x86 instructions that were…
That was a somewhat common approach back then. It's hard to find references to that technique now, but here's something I did find: https://news.ycombinator.com/item?id=16312562
Back when all you had was minicom dialing a BBS, there was a chicken and egg problem where you needed uudecode to decode any executable you downloaded. If you did not have uudecode you were stuck. If you are unfamiliar, unencoding a file allows you to send binary data through text transmission. Then a clever version of a DOS .COM file was posted which implemented uudecode, but it only used x86 instructions that were…
I believe that scripts without a shebang line cannot be executed by execve. They will only run if the shell sees them before the kernel does. It's an annoying limitation of this approach and it wasn't clear to me whether this technique includes a workaround for this. Also the push for code signing everywhere is going to make this harder in the future as well. (I heard a rumor that the workaround to run unsigned execu…
It's a great idea but that part is a big ask for any Windows user who doesn't develop desktop applications.