The author is less than enthusiastic about Apple and Microsoft pivoting to ARM. Considering the perf of the M1, this is virtually inevitable. And once most developer tool chains start supporting ARM as a first class citizen, I see no reason why we wouldn’t start running our applications on ARM in the cloud. A world with 2 architectures for mainstream use cases is the future, there’s no point fighting it.
(Unless you’re Intel/AMD in which case please fight it by giving us faster, more power-efficient chips for cheaper. Thanks!)
We achieved a near ubiquitous consensus with the x86 PC. Then APPLE said, Behold, the programmers are one, and they can build portable binaries with one machine language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do. Go to, let us go down, and there confound their machine code, that they may not run each other apps across platforms. So APPLE scattered them abroad with M1 processors from thence upon the face of all the Internet: and they left off to rebuild their open source.
Just because it's ubiquitous doesn't mean that it's good. Also, to be clear, x86 then became x86_64/amd64 which isn't the same architecture either. There will always be iterations and oddball architectures where something new can be learned and even reapplied to update x86. POWER, Sparc, etc. all taught new lessons.
Apple isn't scattering anything by running processors that run the same architecture as android and ios on phones. Most open source software can already be compiled for x86, arm, sparc, etc.
Except ARM CPUs have been vastly outselling x86 CPUs for a very long time, long before the M1 entered the scene. In just Q4 2020, 6.7 billion ARM-based devices shipped, while 275 million PCs shipped in all of 2020. Desktop PCs are only a small fraction of the total computing ecosystem.
The stuck-in-the-'90s "desktop is all there is" mindset is a weird holdover from the early growth of PCs in developed countries. If you look at emerging markets, mobile is completely dominant.
> A world with 2 architectures for mainstream use cases is the future
And the past, I mean PowerPC was a thing for a long time on both Apple desktop systems and servers.
Glad that the compiler toolchains make this transition a lot easier, and Apple has been a major contributor to that. It helped ease the transition from 32 bit ARM to 64 bit ARM, it enabled easy cross-platform apps (Mac Catalyst) and now from x86 to ARM for desktop apps.
And of course it's not particularly new; 25 years ago (ish) Java came out that promised the same thing, one codebase that runs on all architectures. Scripting languages, too.
PowerPC was also the dominant embedded platform for two decades (the rover that just landed on Mars is PPC). Point being, ARM's presence in highly vertical markets like embedded or phones means very little to desktops and servers outside of Apple.
Only 2 architectures? Hah! I remember when there was X86, Sparc, MIPS, PowerPC, M68K, and Alpha, all in relatively common use. There were a few Itanium, S390x, and other weird things floating around too. (MIPS, PowerPC, and S390x are still hanging around in niche applications today.)
Portability is not hard. If you write standard C/C++ that does not depend on undefined behavior (like wild-ass pointer casts, etc.) you will be fine 99% of the time. Use newer languages like Go and Rust or higher-level languages and you won't even notice.
The only hard areas where labor intensive porting is needed are hand rolled ASM or the use of CPU-specific extensions like vector code (e.g. __m128i and friends). That's a tiny fraction of code written and is generally confined to things like codecs, graphics engines, crypto, and math kernels.
The problem with C/C++ and "newer" languages is that programs need to be individually compiled or have an interpreter installed to execute them - the main problem the author is solving.
The author precisely realises that there used to be multiple architectures, just like you, but also notices that we have converges on x86-64 - what she terms the lingua franca.
I also completely follows her sentiment, that we should not switch ISA unless there is a very real computation per power unit benefit of doing so.
> Portability is not hard. If you write standard C/C++ that does not depend on undefined behavior (like wild-ass pointer casts, etc.) you will be fine 99% of the time.
This is not my area of expertise, so I'm not the one to write the rebuttal, but it seems that "---- is not hard" is never anything more than an invitation to someone who fully understands ---- to explain why it is hard.
Succinctly, serving 99% of the use cases with no effort mainly seems to be a recipe for making sure that, when one hits those 1% problems, one has no idea how to deal with them. I suspect that portability is one of those things where it's easy to do a mediocre job but hard to do a good/robust job.
> Or is it the specific Apple customizations tailored to their use case?
Apple's use case is "run applications". It's not like there's any magic or they have some sort of ultra specific workload they improved by 10x while the rest sat there.
Apple's customisations are largely "throw hardware at the problem", which I'm reasonably sure Intel would do if that worked for x86. So sounds like something you can do with ARM, which you can't with x86.
The more magical customisations are workload specific, but then they would only trigger for these workloads, both of which are pretty much opt-in: running emulated x64 code on ARM, and performing matrix computations (which AFAIK will only be used through the Accelerate framework).
Performance is agnostic of ISA. Apple's custom designed cores do indeed have a massive performance/Watt advantage over x86 based designs and happen to be using ARM. However, it's not impossible for an x86 CPU to be designed in a similar way. It does, however, get more difficult to do so due to x86's variable length instruction encoding, to which ARM does not have.
It currently has a performance per watt advantage because of a fundamental design difference (smaller, simpler, many cores) which works great for mobile and can be scaled up to desktop/server rather than trying to scale down x86.
It seems we are finally going back to the ecosystem of the 90's with multiple processors. This was the genesis of Java at the time and the promise of Write Once Run Anywhere was quite appealing to many developers at the time.
Back then IBM Mainframes still had as strong foothold in large corporate IT departments. Sun had a dominant position as well for most newer companies. If you wanted multiple CPU's with redundant fail over and gigs of RAM Sun was your huckleberry back in the day.
It seems like the current iteration is that modern build systems provide the “write once run anywhere” rather than virtual machines, which have their own compatibility and performance issues.
It’s trivial nowadays to write a program in Go or Rust and deploy it to whatever architecture you want, without any arcane knowledge of the build process
I very definitely read that tongue-in-cheek. Her project targets everything, so long as it's using AMD64, therefore anything _not_ AMD64 is useless, as it can't run her project.
> 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.
This got my upvote at "zip source file embedding could be a more socially conscious way of wasting resources in order to gain appeal with the non-classical software consumer".
Yep, there are usually a lot of "piggybacking" (This comment is not mean spirited, just stating a fact) in HN. I made a similar comment a while back [1]
You do know that it's the same person, right? They're both links to articles on her website. There is no "piggybacking", this is literally her writing about making these things.
"The most compelling use case for making x86-64-linux-gnu as tiny as possible, with the availability of full emulation, is that it enables normal simple native programs to run everywhere including web browsers by default....I think we need compatibility glue that just runs programs, ignores the systems, and treats x86_64-linux-gnu as a canonical software encoding."
I think it’s neat how this acknowledges the reality that the actual meat of the machine code is identical for every x86_64 target— all that's different is the OS interface. So unlike other "fat binary" schemes where there's a lot of duplication, this one has a single main program and then small shims to provide the Linux ABI on MacOS and Windows.
I don't think it has any benefit if you're installing software exclusively that you built yourself on your own targets, or from a distro package manager. But it's potentially a boon for a whole class of statically-linked rescue tools, installers, command-line utilities — basically anything where there's a website with a curl path/to/thing > local/bin/thing installation option.
It also makes manually downloaded software distribution easier. Rather than the user having to select which version of the software to download (which users often get wrong), or trying to guess based on browser user-agent, there's just the one download link that works on everything.
I don't think it's that big of a deal either, since compiling these days is fast enough you can do it 3 times without it being a problem.
Don't get me wrong, it's very impressive, I just don't think it makes that big of a difference in practice, especially since environmental differences will still require you to have 2 codebases in many scenarios (like accessing the filesystem for example)
I think heterogeneous computing is actually coming this time. Increasing binary size requirements wherever portability is required will be an intended sacrifice toward that aim (but for app store based distributions - the only place required to pay the binary size tax will be in the size of the bundle provided to the app store vendor).
I think the importance of ISAs will fade away generally in favor of specifications that enable coordination of higher level memory model semantics "across" compute resources -- the cpu/compute core becomes the thing that allows you to share reads and transfer write ownership of memory as efficiently as possible between heterogeneous components that operate on the compute graph -- and many of these compute components may require various binary forms of task specific instruction encoding ...
I don't understand how this provides a POSIX API on Windows.
There is a tcsetattr function in Cosmopolitan.
If I use that to obtain character-a-a-time input with no echo, and then run the portable executable Windows, will that have the right effect in the console window?
I needed a way to port program to Windows with accurate POSIX, like Cygwin, but without the Cygwin paths and virtual file system and other user-visible quirks.
In under twenty or so fairly simple commits to a fork of the Cygwin DLL, I got it:
Actually, I wonder why not every OS comes with a Posix shell and an Python interpreter nowadays. Posix shells should be super easy, because most systems have them onboard already anyways. However, since Posix shells are kinda broken, I think Python should be the next iteration.
Just to give some context, I am not a Python person, as I prefer Go. But given the popularity and the suited use-cases I think it is a good option.
My problem with shells is not just about the obscure syntax, but rather about the point, that it is next to impossible to write reliable and reusable scripts.
By default return codes of failed commands are silently ignored and `set -e` does not work under all circumstances. By default every variable is part of the global scope and the best you can do about it in a POSIX compliant way are sub-shells, which in turn have no way to change variables outside of their scope.
Not only is the intent of those snippets rather different, you've rather misunderstood the original to the extent that it's broken.
The bash version looks for the pattern `search` in every line of `test.txt`, the Python version treats `test.txt` as a file of patterns, and look for each of these patterns in the file `search`.
And of course you wouldn't implement the bash version in python that way as it's rather trivial to do it in Python:
out = [line for line in open('test.txt') if 'search' in line]
Maybe a POSIX shell, as the POSIX shell standard is small and more most purposes fixed. But you don't want to use the OS python, as it is inevitably old and outdated.
As a Greek, if you do this, I hate you. Why the hell do you have to make me read "actmally pdrtable execmtable"? At least this is one of the less offensive cases.
Author here. I wanted to honor Greece for the amazing cultural impact they've had, similar to how mathematics honors Greece. We got a lot of comments like this in the last thread. What dang said about it was really smart: https://news.ycombinator.com/item?id=24264514
Ah, I don't want to make a fuss about it (my comment was tongue-in-cheek), it's really not a big deal, but it is annoying to spend 2-3 seconds trying to figure out if you're having a stroke, and then some more trying to suss out what the sentence is actually trying to say.
If you want to honor Greece, use the letters as they're meant to be used! "Acτuaλλy πoρτabλe εxecuταbλe" would be much better (though I've intentionally tried to give English readers a stroke with this one :)!
It's actually not smart at all. Replacing the letters in the Roman alphabet with Greek letters based on superficial resemblance is not any different from replacing the "R" with "Я" when writing about anything Russian-related (you see it stupidly used in book covers, t-shirts, etc).
How does this do anything to honor the cultural legacy of Greece? Perhaps we could honor the legacy of 19th century mathematics by using Fraktur characters when they resemble Latin ones?
When people who can read Greek are telling you it's bad taste maybe take their word for it! Not dang.
What you're really saying is that the Greek alphabet (and by extension its language community) is so insignificant compared to Latin that the cost of potential misrecognition is so low that it can be disregarded. This is chauvinism, not "honoring Greek mathematics"!
Aren't the Greek symbols used in math void of implicit meaning? You're taking a meaningful English sentence and replacing its letters with Greek letters while making it extremely difficult for people with disability on screen readers, those two things are not the same.
I have to admit, every previous time I saw this linked I didn't bother clicking through, because from the title I thought it was a post mocking the concept of portable executables.
I know this is a loaded question, but are there any resources you can point to in learning the linux syscall stuff, or perhaps writing a C compiler from scratch? I thought I had a fairly good grasp of this stuff but after looking through cosmopolitan code, I realized Im not even close.
As a Russian speaker, I LOVE these things. Both ways (Russian letters abused to spell English words and vice versa.) In fact I miss old phones with just English keyboards where abuse to spell Russian words (eg CCCP) was an art form, for a brief period.
Omicron looks exactly the same as the English o (it's not visually distinguishable in most typefaces) so it doesn't matter much, but upsilon is an "ee" sound usually, not an "oo" like in "actually" and "executable", so it wouldnt' work exactly. It would read "actially execeetable".
EDIT: For completeness, the full transliteration (or as close to it) would be "άξουαλι πόρταμπολ εξεκιούταμπολ". The extra "o" in "portabol" and "execiutabol" is actually a schwa, I think, so it can be omitted.
Because it makes you look like you know what you're doing, not too different than obfuscating javascript for the sake of security, which does kind of work, at least on the lowest common denominator type of attacks, and this does kind of works too by having people think you're more of a genius than previously thought because you can turn boring English letters into something exotic which appeals to the ignorance of the masses [0].
I used to feel the same way, and this is indeed an annoying practice. Yet here it makes perfect sense, since this work is based on using certain symbols (e.g., header magic numbers in one executable file format) according to a non-intended interpretation based on casual and meaningless similarities (e.g., as machine instructions in another executable file format).
It doesn't make perfect sense. If the name is actually "Actually Portable Executable" then all users should be able to read it that way.
If it is only stylized as "αcτµαlly pδrταblε εxεcµταblε" a readable name should be available alongside the visual styling (using ARIA attributes, for example).
Since I think this is a study in compatibility and not meant to be paradigm changing new programming concept I think the author is having fun with all of it rather than being overly serious and not concerned about being bookish
The author is less than enthusiastic about Apple and Microsoft pivoting to ARM. Considering the perf of the M1, this is virtually inevitable. And once most developer tool chains start supporting ARM as a first class citizen, I see no reason why we wouldn’t start running our applications on ARM in the cloud. A world with 2 architectures for mainstream use cases is the future, there’s no point fighting it.
(Unless you’re Intel/AMD in which case please fight it by giving us faster, more power-efficient chips for cheaper. Thanks!)
We achieved a near ubiquitous consensus with the x86 PC. Then APPLE said, Behold, the programmers are one, and they can build portable binaries with one machine language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do. Go to, let us go down, and there confound their machine code, that they may not run each other apps across platforms. So APPLE scattered them abroad with M1 processors from thence upon the face of all the Internet: and they left off to rebuild their open source.
Just because it's ubiquitous doesn't mean that it's good. Also, to be clear, x86 then became x86_64/amd64 which isn't the same architecture either. There will always be iterations and oddball architectures where something new can be learned and even reapplied to update x86. POWER, Sparc, etc. all taught new lessons.
Apple isn't scattering anything by running processors that run the same architecture as android and ios on phones. Most open source software can already be compiled for x86, arm, sparc, etc.
Except ARM CPUs have been vastly outselling x86 CPUs for a very long time, long before the M1 entered the scene. In just Q4 2020, 6.7 billion ARM-based devices shipped, while 275 million PCs shipped in all of 2020. Desktop PCs are only a small fraction of the total computing ecosystem.
The stuck-in-the-'90s "desktop is all there is" mindset is a weird holdover from the early growth of PCs in developed countries. If you look at emerging markets, mobile is completely dominant.
8 replies →
Lol this made my morning
I read that in the voice of Cecil B. DeMille narrating in The Ten Commandments. Well done.
Near consensus on x86? But aren’t most computers in this world actually smartphones?
I'm not sure what you're saying, but I appreciate that you put more effort into saying it than ten other HN posts combined.
4 replies →
> A world with 2 architectures for mainstream use cases is the future
And the past, I mean PowerPC was a thing for a long time on both Apple desktop systems and servers.
Glad that the compiler toolchains make this transition a lot easier, and Apple has been a major contributor to that. It helped ease the transition from 32 bit ARM to 64 bit ARM, it enabled easy cross-platform apps (Mac Catalyst) and now from x86 to ARM for desktop apps.
And of course it's not particularly new; 25 years ago (ish) Java came out that promised the same thing, one codebase that runs on all architectures. Scripting languages, too.
PowerPC was also the dominant embedded platform for two decades (the rover that just landed on Mars is PPC). Point being, ARM's presence in highly vertical markets like embedded or phones means very little to desktops and servers outside of Apple.
Only 2 architectures? Hah! I remember when there was X86, Sparc, MIPS, PowerPC, M68K, and Alpha, all in relatively common use. There were a few Itanium, S390x, and other weird things floating around too. (MIPS, PowerPC, and S390x are still hanging around in niche applications today.)
Portability is not hard. If you write standard C/C++ that does not depend on undefined behavior (like wild-ass pointer casts, etc.) you will be fine 99% of the time. Use newer languages like Go and Rust or higher-level languages and you won't even notice.
The only hard areas where labor intensive porting is needed are hand rolled ASM or the use of CPU-specific extensions like vector code (e.g. __m128i and friends). That's a tiny fraction of code written and is generally confined to things like codecs, graphics engines, crypto, and math kernels.
The problem with C/C++ and "newer" languages is that programs need to be individually compiled or have an interpreter installed to execute them - the main problem the author is solving.
The author precisely realises that there used to be multiple architectures, just like you, but also notices that we have converges on x86-64 - what she terms the lingua franca.
I also completely follows her sentiment, that we should not switch ISA unless there is a very real computation per power unit benefit of doing so.
> Portability is not hard. If you write standard C/C++ that does not depend on undefined behavior (like wild-ass pointer casts, etc.) you will be fine 99% of the time.
This is not my area of expertise, so I'm not the one to write the rebuttal, but it seems that "---- is not hard" is never anything more than an invitation to someone who fully understands ---- to explain why it is hard.
Succinctly, serving 99% of the use cases with no effort mainly seems to be a recipe for making sure that, when one hits those 1% problems, one has no idea how to deal with them. I suspect that portability is one of those things where it's easy to do a mediocre job but hard to do a good/robust job.
Does ARM really have a performance advantage? Or is it the specific Apple customizations tailored to their use case?
Apple doesn't have to worry about 35 years of legacy architecture to support.
> Or is it the specific Apple customizations tailored to their use case?
Apple's use case is "run applications". It's not like there's any magic or they have some sort of ultra specific workload they improved by 10x while the rest sat there.
Apple's customisations are largely "throw hardware at the problem", which I'm reasonably sure Intel would do if that worked for x86. So sounds like something you can do with ARM, which you can't with x86.
The more magical customisations are workload specific, but then they would only trigger for these workloads, both of which are pretty much opt-in: running emulated x64 code on ARM, and performing matrix computations (which AFAIK will only be used through the Accelerate framework).
4 replies →
Performance is agnostic of ISA. Apple's custom designed cores do indeed have a massive performance/Watt advantage over x86 based designs and happen to be using ARM. However, it's not impossible for an x86 CPU to be designed in a similar way. It does, however, get more difficult to do so due to x86's variable length instruction encoding, to which ARM does not have.
19 replies →
It currently has a performance per watt advantage because of a fundamental design difference (smaller, simpler, many cores) which works great for mobile and can be scaled up to desktop/server rather than trying to scale down x86.
It seems we are finally going back to the ecosystem of the 90's with multiple processors. This was the genesis of Java at the time and the promise of Write Once Run Anywhere was quite appealing to many developers at the time.
Back then IBM Mainframes still had as strong foothold in large corporate IT departments. Sun had a dominant position as well for most newer companies. If you wanted multiple CPU's with redundant fail over and gigs of RAM Sun was your huckleberry back in the day.
It seems like the current iteration is that modern build systems provide the “write once run anywhere” rather than virtual machines, which have their own compatibility and performance issues.
It’s trivial nowadays to write a program in Go or Rust and deploy it to whatever architecture you want, without any arcane knowledge of the build process
4 replies →
I very definitely read that tongue-in-cheek. Her project targets everything, so long as it's using AMD64, therefore anything _not_ AMD64 is useless, as it can't run her project.
How many toolchains do not have Arm64 support? Cross-compiling is ancient and most tools predate x86 being useful.
Previously:
https://news.ycombinator.com/item?id=25556286
> 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.
Could've written a win32 program.
Could it disguise as a WinRT program?
It doesn't need to.
2 replies →
This got my upvote at "zip source file embedding could be a more socially conscious way of wasting resources in order to gain appeal with the non-classical software consumer".
This is a follow-up to
Show HN: Redbean – Single-file distributable web server - https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
There is no way to find the other thread using the site search though
the what now?
2 replies →
Closely related : this "Show HN" of an Actually Portable Executable for a web server, published earlier today by the author : https://news.ycombinator.com/item?id=26271117
Yep, there are usually a lot of "piggybacking" (This comment is not mean spirited, just stating a fact) in HN. I made a similar comment a while back [1]
https://news.ycombinator.com/item?id=25625703
You do know that it's the same person, right? They're both links to articles on her website. There is no "piggybacking", this is literally her writing about making these things.
3 replies →
"The most compelling use case for making x86-64-linux-gnu as tiny as possible, with the availability of full emulation, is that it enables normal simple native programs to run everywhere including web browsers by default....I think we need compatibility glue that just runs programs, ignores the systems, and treats x86_64-linux-gnu as a canonical software encoding."
:)
Just a smiley, no other words!
Very interesting, but every one of these executives I try on my fairly stock Ubuntu system returns 'run-detectors: unable to find an interpreter'.
I'm invoking them with 'bash -c'.
Author here. That error means you're using binfmt_misc. You can fix that by saying:
Then you're good to go!
Thanks!
https://news.ycombinator.com/item?id=26273058
Can someone explain the advantage over building an executable for each target system?
Not having to build an executable for each target system.
I think it’s neat how this acknowledges the reality that the actual meat of the machine code is identical for every x86_64 target— all that's different is the OS interface. So unlike other "fat binary" schemes where there's a lot of duplication, this one has a single main program and then small shims to provide the Linux ABI on MacOS and Windows.
I don't think it has any benefit if you're installing software exclusively that you built yourself on your own targets, or from a distro package manager. But it's potentially a boon for a whole class of statically-linked rescue tools, installers, command-line utilities — basically anything where there's a website with a curl path/to/thing > local/bin/thing installation option.
It also makes manually downloaded software distribution easier. Rather than the user having to select which version of the software to download (which users often get wrong), or trying to guess based on browser user-agent, there's just the one download link that works on everything.
And malware. I don't know why that popped into my mind as the first use-case for this and the web server. :|
This is slightly faster I guess?
I don't think it's that big of a deal either, since compiling these days is fast enough you can do it 3 times without it being a problem.
Don't get me wrong, it's very impressive, I just don't think it makes that big of a difference in practice, especially since environmental differences will still require you to have 2 codebases in many scenarios (like accessing the filesystem for example)
Every source-portable program has that anyway though, typically either with a bunch of ifdefs, or by linking to an abstraction like boost::filesystem.
The change here would basically be that all versions of it would have to be compiled into the same binary, with a runtime switch.
Nope much slower. And never worked for me.
It's cool.
It is very satisfying.
I think heterogeneous computing is actually coming this time. Increasing binary size requirements wherever portability is required will be an intended sacrifice toward that aim (but for app store based distributions - the only place required to pay the binary size tax will be in the size of the bundle provided to the app store vendor).
I think the importance of ISAs will fade away generally in favor of specifications that enable coordination of higher level memory model semantics "across" compute resources -- the cpu/compute core becomes the thing that allows you to share reads and transfer write ownership of memory as efficiently as possible between heterogeneous components that operate on the compute graph -- and many of these compute components may require various binary forms of task specific instruction encoding ...
I don't understand how this provides a POSIX API on Windows.
There is a tcsetattr function in Cosmopolitan.
If I use that to obtain character-a-a-time input with no echo, and then run the portable executable Windows, will that have the right effect in the console window?
Yup. See https://justine.lol/blinkenlights/blinkenlights-windows.png and https://github.com/jart/cosmopolitan/blob/fcfe7c108083962a3d... and https://github.com/jart/cosmopolitan/blob/fcfe7c108083962a3d... and https://github.com/jart/cosmopolitan/blob/fcfe7c108083962a3d... and https://github.com/jart/cosmopolitan/blob/fcfe7c108083962a3d... It's not perfect though. For example, right now Cosmopolitan won't do the really dirty hacks that Cygwin does to fully simulate POSIX like creating a virtual filesystem or spawning daemons and threads for handling signals. Cosmopolitan does however give you 90% the value at 10% the price. This has been great for my use case, since I'm mostly only concerned with greenfield development. I wanted the feel of POSIX but I didn't need to check off a box with a regulatory body that it conforms perfectly to POSIX. I'm also not trying to create a distro that leverages all the open source works written to date; Cygwin and MinGW are already doing a great job at that and I view Cosmopolitan as complementary.
I needed a way to port program to Windows with accurate POSIX, like Cygwin, but without the Cygwin paths and virtual file system and other user-visible quirks.
In under twenty or so fairly simple commits to a fork of the Cygwin DLL, I got it:
http://www.kylheku.com/cygnal/
This is another useful tool in this general arsenal.
A clever solution but still dependent on qemu.
I think it only uses qemu if you attempt to execute on non-x86 architectures. So it’s not a build-time dependency.
Right. I believe the long term vision is to JIT for other architectures.
Actually, I wonder why not every OS comes with a Posix shell and an Python interpreter nowadays. Posix shells should be super easy, because most systems have them onboard already anyways. However, since Posix shells are kinda broken, I think Python should be the next iteration.
Just to give some context, I am not a Python person, as I prefer Go. But given the popularity and the suited use-cases I think it is a good option.
The problem is bash et al are languages designed for the command line. Every line is a separate command.
Contrast:
With:[0]
While the first may use some “magic” symbols such as the pipe, it’s really concise in conveying what it’s doing.
I will give you this: bash variables and expansions can be confusing. Contrast with programming where this probably works:
[0]: https://stackoverflow.com/a/9018183/1350209
My problem with shells is not just about the obscure syntax, but rather about the point, that it is next to impossible to write reliable and reusable scripts.
By default return codes of failed commands are silently ignored and `set -e` does not work under all circumstances. By default every variable is part of the global scope and the best you can do about it in a POSIX compliant way are sub-shells, which in turn have no way to change variables outside of their scope.
It is just broken by design :-/
1 reply →
Not only is the intent of those snippets rather different, you've rather misunderstood the original to the extent that it's broken.
The bash version looks for the pattern `search` in every line of `test.txt`, the Python version treats `test.txt` as a file of patterns, and look for each of these patterns in the file `search`.
And of course you wouldn't implement the bash version in python that way as it's rather trivial to do it in Python:
or somesuch.
As somewhat of a Python developer these days, I have to point out that each 3.something release of Python potentially breaks backwards compatibility.
Second issue is that Python without any extra modules is still pretty limited, nearly every serious python project comes with some extra dependencies.
So have a Python interpreter available only gets you so far...
(For the record, the same could be said about pretty much all dynamic languages I'm familiar with).
Maybe a POSIX shell, as the POSIX shell standard is small and more most purposes fixed. But you don't want to use the OS python, as it is inevitably old and outdated.
> αcτµαlly pδrταblε εxεcµταblε
As a Greek, if you do this, I hate you. Why the hell do you have to make me read "actmally pdrtable execmtable"? At least this is one of the less offensive cases.
EDIT: Solidarity to our Cyrillic friends!
Author here. I wanted to honor Greece for the amazing cultural impact they've had, similar to how mathematics honors Greece. We got a lot of comments like this in the last thread. What dang said about it was really smart: https://news.ycombinator.com/item?id=24264514
Ah, I don't want to make a fuss about it (my comment was tongue-in-cheek), it's really not a big deal, but it is annoying to spend 2-3 seconds trying to figure out if you're having a stroke, and then some more trying to suss out what the sentence is actually trying to say.
If you want to honor Greece, use the letters as they're meant to be used! "Acτuaλλy πoρτabλe εxecuταbλe" would be much better (though I've intentionally tried to give English readers a stroke with this one :)!
3 replies →
It's actually not smart at all. Replacing the letters in the Roman alphabet with Greek letters based on superficial resemblance is not any different from replacing the "R" with "Я" when writing about anything Russian-related (you see it stupidly used in book covers, t-shirts, etc).
How does this do anything to honor the cultural legacy of Greece? Perhaps we could honor the legacy of 19th century mathematics by using Fraktur characters when they resemble Latin ones?
When people who can read Greek are telling you it's bad taste maybe take their word for it! Not dang.
What you're really saying is that the Greek alphabet (and by extension its language community) is so insignificant compared to Latin that the cost of potential misrecognition is so low that it can be disregarded. This is chauvinism, not "honoring Greek mathematics"!
1 reply →
Aren't the Greek symbols used in math void of implicit meaning? You're taking a meaningful English sentence and replacing its letters with Greek letters while making it extremely difficult for people with disability on screen readers, those two things are not the same.
I have to admit, every previous time I saw this linked I didn't bother clicking through, because from the title I thought it was a post mocking the concept of portable executables.
2 replies →
I appreciate the good intentions, but confusing Greek readers doesn't seem to me like a good way to honor the cultural impact of Greece.
I know this is a loaded question, but are there any resources you can point to in learning the linux syscall stuff, or perhaps writing a C compiler from scratch? I thought I had a fairly good grasp of this stuff but after looking through cosmopolitan code, I realized Im not even close.
7 replies →
> 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.
I agree with dang's feelings/thoughts about the issue.
Perhaps a solution would be to add the "normal" meaning between parenthesis, after the one in greek alphabet?
By the way, Justine: great work. Besides the obvious HN recognition, I wanted to tell you explicitly as well.
What are you going to work on in the near future? Curious to hear about it. If you don't want to post in public, $my_hn_username at gmail
What dang said about it was not smart.
> it's good for readers to have to work a little
Unless they're using assistive technologies. In that case it's a nightmare. Don't make your users work.
> it's not hard for any HN reader to do the bit of work to figure it out
Unless they're using assistive technologies. Or just want to read it without work.
Or, say searching for it. This post comes up. The one you linked to doesn't.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Respect to you for wanting to honor Greece. I think using the letters* correctly would honor them more. (thanks for the correction)
2 replies →
As a Russian speaker, I LOVE these things. Both ways (Russian letters abused to spell English words and vice versa.) In fact I miss old phones with just English keyboards where abuse to spell Russian words (eg CCCP) was an art form, for a brief period.
Especially since if you want to port the title to Greek lettering, you have upsilon and omicron for u and o:
αcτυαlly pοrταblε εxεcυταblε
Omicron looks exactly the same as the English o (it's not visually distinguishable in most typefaces) so it doesn't matter much, but upsilon is an "ee" sound usually, not an "oo" like in "actually" and "executable", so it wouldnt' work exactly. It would read "actially execeetable".
EDIT: For completeness, the full transliteration (or as close to it) would be "άξουαλι πόρταμπολ εξεκιούταμπολ". The extra "o" in "portabol" and "execiutabol" is actually a schwa, I think, so it can be omitted.
2 replies →
Deep breaths. Deep, slow breaths. You're going to be just fine.
Female white privilege
Because it makes you look like you know what you're doing, not too different than obfuscating javascript for the sake of security, which does kind of work, at least on the lowest common denominator type of attacks, and this does kind of works too by having people think you're more of a genius than previously thought because you can turn boring English letters into something exotic which appeals to the ignorance of the masses [0].
[0] https://en.wikipedia.org/wiki/Argument_from_ignorance
you might be overthinking this
Using completely wrong greek letters in the title is making me very uneasy for no good reason
I used to feel the same way, and this is indeed an annoying practice. Yet here it makes perfect sense, since this work is based on using certain symbols (e.g., header magic numbers in one executable file format) according to a non-intended interpretation based on casual and meaningless similarities (e.g., as machine instructions in another executable file format).
It doesn't make perfect sense. If the name is actually "Actually Portable Executable" then all users should be able to read it that way.
If it is only stylized as "αcτµαlly pδrταblε εxεcµταblε" a readable name should be available alongside the visual styling (using ARIA attributes, for example).
3 replies →
But the metaphor doesn't work. I understand the intent, but if anything, it's more appropriate for an error-correcting code.
okay well just fuck anyone using a screen reader then.
10 replies →
Now you reminded me of a book that my grand father has, where the title is something like:
Яцssiди Сдяs
And it’s just so horrible to make a title using Cyrillic characters according to what looks like Latin and not according to their actual sounds XD
> I chose the name because I like the idea of having the freedom to write software without restrictions that transcends traditional boundaries.
Actmallu pdrtable execmtable
Sorry to ruin the joke, but y is actually in Latin script.
1 reply →
As someone who reads and speaks (μόνο ενά λίγο - only a little) Greek, same.
There's a subreddit for parodying the phenomenon - http://reddit.com/r/grssk
Since I think this is a study in compatibility and not meant to be paradigm changing new programming concept I think the author is having fun with all of it rather than being overly serious and not concerned about being bookish
I mean, i keep reading it as the letters themselves; really the only two that bothered me were delta ~ d and not o, and mu is m and not u
I read your comment thinking you were being stodgy, but then I went to the site and had the same reaction.
Can't imagine that doing so is going over well for people using screen-readers.
Hello its good