(I might be partially wrong because I've studied Greek many years ago and my memory is not good)
> 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐩𝐨𝐫𝐭𝐚𝐛𝐥𝐞 𝐞𝐱𝐞𝐜𝐮𝐭𝐚𝐛𝐥𝐞
I'd rather see submissions stand out for their content.
The quality of this post is so high that it doesn't feel right to override any aspect of what the author created, including quirks like the title. There may be a superficial similarity to garden-variety title pimping, but as someone who bathes in spam every day I can tell you how rarely such gimmicks come attached to first-class feats of hacking prowess. Respect for content requires looking closely enough to detect truly unusual cases, pick them out of the mud, and give them a special place.
Another principle applies here too: it's good for readers to have to work a little (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...). If a title like that appears at #1 on HN, there are two possibilities: (1) this is dreck that somehow managed to evade all of the standard moderation; or (2) something's happening here and you don't know what it is. Actually, either possibility is rather interesting, and it's not hard for any HN reader to do the bit of work to figure it out. Even if it takes 20 seconds.
Hm. Not a bad idea.
Files away as an Unethical LifeHack
You can expect a bold, Cyrillic, ZALGO!͇̺̫̞̤͇̼͋̆̂-fied post about my next paper shortly.
Therefore the title of the article written in multiple language letters and somewhat readable in one language despite that is a good introduction.
It would help people focus more on the content of the article, make the submission more accessible for non-English & blind readers, and feel less spammy and exploitative, all at the same time.
I doubt the author of this article or the submitter wants this to be the top thing people are discussing about their article anyway. And that is the title -- if you go to the library source code[0], its graphical banner is using the normal English letters. The unicode weirdness here is only being used typographically, the author isn't claiming that their title should be pronounced differently or something.
[0]: https://raw.githubusercontent.com/jart/cosmopolitan/46750430...
The only boundary this transcends is readability and is ironically not portable at all.
edit for readability:
тхе онлу боундары тхис трансцендс ис реадабилиты анд ис ироницаллы нот портабле ат алл.
I wish this wasn’t the top voted comment.
Things that are subversive, clever, mind bending, tongue in cheek ... tend to get criticized around these parts for not being simple, plain, and literal.
There are a couple of users who email us regularly when they see things like that. This is one of the highest-leverage contributions anybody can make to HN, so we'd certainly appreciate hearing from more such users. Actually I only found out about this subthread because of such an email.
Supercilious complaints, on the other hand, just make the thread even worse. Please don't do that. The thing where some HN commenters use HN to posture over the rest of HN is tedious, and in poor taste. Let's just work together to make it better, to the extent possible.
I think it's fair to point out when a good article makes itself inaccessible due to a trivially correctable problem.
I'm not even saying that the author can't make the joke they're trying to make, but even a small title change like "αcτµαlly pδrταblε εxεcµταblε (actually portable executable)" would basically solve the entire problem without sacrificing any of the meaning behind what the author wants to convey with their misuse of Unicode.
It is a good article, which is why the pointless pushback over accessibility is so frustrating. There would be no engineering effort or large compromise required to make the title of the submission readable. It wouldn't suddenly make the article bad, or not worth reading. It feels like it's being exclusionary just for the sake of being exclusionary.
4 = ch
6 = sh
And some people keep on doing it. I can understand it when you have to switch between scripts every 2 seconds but most commonly that isn't the case and you are either having a conversation with someone or leaving it for later when you have time or when you feel like it...
There are people whose native languages are in those alphabets.
Quick: How would you pronounce СССР?
Hint: It would be completely wrong, because it's not English.
HN’s title should probably be changed.
2) αcτµαlly pδrταblε εxεcµταblε
What is easier to comprehend?
Case in point I guess.
(Russian is my native language)
The things that bother some people.
For me, it always takes some time to see it as face and still hard to understand what emotion this face presents.
My approach was slightly different; I created a polyglot script header you can paste at the beginning of a C source file to make it essentially a C script which is just-in-time compiled when it is executed. Works on Windows, Linux, and Mac as long as a C compiler is installed. https://gist.github.com/jdarpinian/6860ddfd92b5b458a20ab6055...
Also note that the execve() shebang thing is a one-time cost. The printf statement in the header will overwrite the first 64-bytes of the executable, the first time it's invoked, so it becomes a canonical ELF or Mach-O executable for subsequent invocations. The one-time cost is also cheap. The shell script only needs three system calls (open, write, and execve) to patch the binary appropriately. The generation of this header is also abstracted by the GNU ld script, which made it easy for me to encode the ELF header relocations as octal printf codes!
Every single one of those programs you listed is FOSS licensed.
Autotools was originally developed as a compatibility layer to compile code on proprietary UNIXes.
This is cool but also a problem for subsequent sharing of the executable. I thought about doing this as well but decided against having the file mutate into a version that wouldn't work on other systems.
Again, super cool project! I love this kind of thing.
What's the issue specifically? I've never had a good Autotools experience (granted, I wouldn't reach for Bazel or CMake either--the whole build tool ecosystem is in desperate need of innovation IMO and probably the nicest things are Nix or Guix).
Is this a problem for anti-virus/other security measures? My understanding is, executables that manipulate themselves is something any security software will look for.
Though perhaps the answer is "don't rely upon security software to police your system; do it yourself"
Could you provide a link to learn more? This seems bad.
It's a great idea but that part is a big ask for any Windows user who doesn't develop desktop applications.
Was there ever a workaround for this? I thought you just ran them…
This was once true on old systems, but current ones (including Linux) have native support for scripts starting with #!. See fs/binfmt_script.c in Linux, which has existed for several decades.
I've never seen anyone mention this before. Is this really in the cards? Or are all the extensions patented as well, so that a hypothetical Apple (or whoever else takes it on) x86 wouldn't be able to use x86 without licensing it?
Author has clearly not heard about NexGen! They implemented a RISC architecture that code morphed x86 i586 design. They were then bought out by AMD who shortly thereafter adopted the design for their own architecture. Then Intel had no choice but to adopt NexGen architecture as well lool. We all use NexGen Architecture now. The most famous microprocessor no one's heard of. I only know because NexGen was based in Milpitas and that's where I live, so Milpitas Architecture is like hometown pride.
As for patents, Xed is tiny (only ~4kb) and it allows us to distinguish the which instructions belong to which microarchitectures, e.g. k8, sse3, sse4, avx. That gives us a clear accurate picture of the intellectual property rolloff, thereby enabling a fabless chip or emulator to simply ignore the encumbered parts of the encoding space. The tradeoff is you can't patent troll Intel (due to Xed being licensed Apache 2.0) and I think that's fair.
I think the sibling comment is more accurate: while the core of the ISA might effectively be public domain soon, there are plenty of extensions in common use that aren't. If you implement a custom x86 design without those a lot of software won't be able to run or it will run with significantly worse performance.
Yes. So, if you want to reimplement a CPU from 1999, you will probably be fine without any kind of license. If you want to add features or use new methods, however, you may run into infringement issues.
Then a clever version of a DOS .COM file was posted which implemented uudecode, but it only used x86 instructions that were also ASCII characters. You could copy/paste between the --cut here-- lines into a file, save it as uudecode.com, and then get your other binaries like pkzip.
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
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
It is a com executable that prints EICAR-STANDARD-ANTIVIRUS-TEST-FILE! It recognized by most virus scanners.
Truly magical days.
I had to undergo the same chicken egg situation with uudecode
>So I think it's really the best of times to be optimistic about systems engineering. We agree more on sharing things in common than we ever have. There are still outliers like the plans coming out of Apple and Microsoft we hear about in the news, where they've sought to pivot PCs towards ARM.
[...]
>If a microprocessor architecture consensus finally exists, then I believe we should be focusing on building better tools that help software developers benefit from it
Considering ARM an outlier in a world were smartphones outnumber desktop PCs and where the x86 stronghold is under attack from several sides seems like a strange take to me.
Also, there's more to portability than managing to run a hello world from the same binary on Windows and Linux. I used to use FreeBSD a lot on the desktop, which usually involved using Linux binary compatibility to run Linux closed source binaries that weren't available on FreeBSD. It worked generally pretty well, but it wasn't without friction at times even though it was coded by very smart people and between two systems that were overall very similar.
These "compatibility" applications often end up as 2nd class citizen that don't integrate well with native applications, or at least not as easily. See Wine for instance, managing to run Windows applications on un*x is a huge undertaking.
>One of the reasons why I love working with a lot of these old unsexy technologies, is that I want any software work I'm involved in to stand the test of time with minimal toil. Similar to how the Super Mario Bros ROM has managed to survive all these years without needing a GitHub issue tracker.
I love emulation, so I definitely understand where this is coming from, but I don't really see what that has to do with the rest. In particular if you're willing to go down the emulation route, why do you care about everybody running x86? Super Mario Bros was not written to run on a Celeron. Besides CPU emulation for something like a NES video game is only a tiny part of the story, you also have to emulate the GPU, sound chip etc...
I feel like there's a mishmash of interesting ideas in there, but it's a bit confusing to understand.
Before I built Actually Portable Executable, PCs behaved de facto similar to mobile development restrictions, where for example if you want to build for Apple you download XCode, and if you want to build for Windows you have to download MSVC. But it thankfully has never been a hard requirement for creating first class native programs. It simply required the will to ignore official tooling and encode binaries the hard way that directly talk to canonical stock kernel abis, so that we don't need things like jenkins to compile release binaries n times for the same microprocessor architecture.
I had enough free time to do it. I've also shared a tool that makes it easier for everyone else to do it too. Enjoy!
That's not actually true. Fortnite has an APK download many users download straight from the internet and run on their Android phones for example. There's no requirement to run Google authorized software as long as you are willing to check a checkbox in the phone settings.
I guess the people I could see myself sharing binaries with are either too clueless to use the command line or savvy enough that installing a compiler/interpreter is not an issue.
> I couldn't resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps.
> Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil.
My understanding was that people are using web-apps and electron precisely to provide cross-platform GUIs. I feel like this is really missing the forest for the mountains...
> I started a project which called Cosmopolitan which implements the αcτµαlly pδrταblε εxεcµταblε format. I chose the name because I like the idea of having the freedom to write software without restrictions that transcends traditional boundaries.
My eyesight is terrible and my recollection of Greek is lousy, but I was going "Aren't those Ms?? Isn't that a D?"
Thank you for that.
I guess there's also syscall emulation stubs for Windows but since he only supports "stdio and sockets" maybe not.
https://en.wikipedia.org/wiki/Polyglot_(computing)
Apparently people on Stack Exchange have been working together on a single polyglot program for four years and have gotten a single codebase up to validity in nearly 300 languages.
https://codegolf.stackexchange.com/questions/102370/add-a-la...
Edit: also, Yusuke Endoh is a master at this art form
https://github.com/mame/quine-relay
and has even written a book about it
http://uguu.org/words/2015_10_01.html
which I would still love to have available in English!
A quine that prints itself as scrolling text in an AVI file: https://www.youtube.com/watch?v=rMlJy5He-Tk
A self-similar quine that behaves like a fractal zooming out infinitely: https://www.youtube.com/watch?v=6J7u2G52scc
A quine with source code that contains sheet music to a Bach song in comments and plays it: https://www.youtube.com/watch?v=OryXKUgRVOg
Wow, what a link. I submitted it just now as a separate HN post using your phrasing:
PoC||GTFO International Journal of Proof-of-Concept or ... https://www.alchemistowl.org/pocorgtfo/
Corkami: https://github.com/corkami
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.
This is the first time I've seen a legitimate website with one of these URLs.
- License is GPL2
- If you want to be able to distribute binaries in binary only form, then please send $1,000 to Justine Tunney jtunney@gmail.com on PayPal, for a license lasting 1 year.
If the goal of this project is to have something similar to cross platform web development this is the wrong way to go about it imo.
I don't think that's a good goal to have. Without competing architectures we'll enter a microprocessor dark age. Although the glory days of Alpha and IA64 are over, plenty of that experience was used to bolster today's instruction sets. Diversity is a good thing.
Meanwhile attempts at creating new ISAs over the past couple of decades has been met with relatively little success, or only in very specific niches. Itanium being an obvious example. People talk about RISC V a lot but in practice it's not really making a dent into the ARM market share yet.
These days competition appears to come mostly from companies reimplementing and extending existing ISAs with better performance.
Just my opinion, but SiFive has been a huge driving force in even giving RISC-V a shot at breaking into server space. Most other companies (Google, Nvidia, Western Digital) have invested in RISC-V with the apparent intent of focusing on building microcontrollers/embedded processors. AFAIK, there's only one player who is investing in building RISC-V server-class CPUs and that's SiFive.
Please correct me if I'm mistaken! I've been following RISC-V pretty closely for the last year or so and there's quite a lot to catch up on.
1 = https://github.com/riscv/riscv-v-spec 2 = https://github.com/riscv/riscv-plic-spec
They think that's cool. This style was called brain damaged style. https://zhidao.baidu.com/question/63502990
什庅bai湜焱暒妏？举些瑺鼡哋唎ふ。du 什庅湜悩残軆？举些瑺鼡哋唎ふ。 什庅湜zhi悱炷蓅？举些瑺鼡哋唎ふ。 莓兲想埝祢巳宬儰⒈种漝惯
Incase anyone searches on hn.aloglia in future!
$ ./program.com
-bash: ./program.com: cannot execute binary file: Exec format error
$ sh ./program.com
./program.com: ./program.com: cannot execute binary file
It's incompatible with modern debuggers.
It's incompatible with shared libraries.
It's limited to a feature-poor "unified" API (that might as well be seen as a crippled VM).
It's complex in both interface and implementation. The bad aspects of Unix made even worse.
The justifications make no sense whatsoever. It wants to do future-proofing but invents an adhoc "VM" with hardcoded OS interfaces that are meant to be treated as private. For macOS, I doubt binaries will work in the next release or two, nevermind 10 years.
It's a fun toy or troll, but if you're looking at this for serious work I suggest you steer well clear.
Any debugger that can't debug this binary is broken and should be treated as such.
From issue 2:
"A careful reader may have noticed that a bootable OS image was hidden in the last issue of PoC‖GTFO,as one of the files in its dual PDF/ZIP structure (if you haven’t, download and extract it now!). This time, though, let’s hide it in plain sight. You will find by running ‘qemu-system-i386 -fda pocorgtfo02.pdf’ that the PDF file you are reading is also a bootable disk image."
> 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
https://github.com/cyrus-and/gdb-dashboard
Though any debugger should be able to give the same information (including just plain gdb).
"Need cred or accessibility? Nerd cred! Screw you if your eyes don't work!"
Earlier this year, I somehow managed to successfully compile an x86_64-linux-gnu toolchain under MinGW. Using that, pretty much 90% of the Cosmopolitan built fine under Windows without needing a Linux VM (which actually goes faster than native WIN32 due to how Make+GCC assumes processes work). I've tried and failed several times to compile GCC from source on Mac.
But I think compiling GCC is just so hard, that I'd probably rather embed the GNU/Linux compiler binaries in the PKZIP embedded file structure of EMULATOR.COM, since that should create a GPL boundary that's kosher per the GPLv3 and GCC RTEv3 terms.
> here’s how simple it is: (two lines of arcane gcc invocation)
I just don’t see how you can call that simple.
Well yeah, but that might be more a function of it existing before git and github.
https://www.mariowiki.com/List_of_Super_Mario_Bros._glitches
So I read this like: actmally pthrtable execmtable.
"
Please note that zsh has a minor backwards compatibility glitch with Thompson Shell so try sh hello.com rather than ./hello.com.
"