Hacker News Reader

Comment by eatonphil | Hacker News Reader

> The end result is that if you switch your Linux build process to use cosmocc instead of cc then the programs you build, e.g. Bash and Emacs, will just work on the command prompts of totally different platforms like Windows and MacOS, and when you run your programs there, it'll feel like you're on Linux. However portability isn't the only selling point. Cosmo Libc will make your software faster and use less memory too. For example, when I build Emacs using the cosmocc toolchain, Emacs thinks it's building for Linux. Then, when I run it on Windows:

> It actually goes 2x faster than the native WIN32 port that the Emacs authors wrote on their own. Cosmo Emacs loads my dotfiles in 1.2 seconds whereas GNU Emacs on Windows loads them in 2.3 seconds.

Impressive stuff.

View on HN

This is all super impressive especially for such a small team.

But we should keep in mind that this project is what POSIX should have been, this is a big patch to make things right, as they should have been more than 20 years ago.

It seems magical because of the failure of numerous other teams and people who never managed to tackle the portability issue with the right mindset and skills.

I think this could be said about pretty much any good invention. The physical world doesn't change much, so the only barrier to invention is human. And I suspect most inventions have someone imagining it long before some other person actually builds it.

I disagree.

Most new development in tech, including software, have some dependencies on something that was not available before.

If that is so, how was is possible to develop the dependency? By definition it was not available before, so it must be a new development. So by that reasoning it is impossible to ever see something new.

Since you write "Most" there seem to be fewer 'new developments' which do not follow this pattern. So all you really say, is that rare new developments, which do not depend some other innovation, enable many followup innovations.

After all, your argument is not in conflict with the previous argument. You say, that new developments (aka implementations) have dependencies that have to be available before they can be made a reality, while the previous post just said, that long before something can be implemented, someone had imagined/dreamt about it already.

Is it the job of linux OS people to provide multi-platform executable compatibility with every other OS? That seems like a stretch considering that no OS has ever done that.

You have it backwards on two counts. First count is the point of POSIX is any OS vendor doesn’t need to worry about any other OS compatibility. Just implement POSIX interfaces. Second count is that is OP’s exact point: it never has been done before, because too many OS vendors give POSIX very little thought. This helps realize the original vision of POSIX.

> First count is the point of POSIX is any OS vendor doesn’t need to worry about any other OS compatibility. Just implement POSIX interfaces.

I must be missing something. How are you getting from "just implement POSIX interfaces" to "compile once run everywhere"?

Wouldn't the former just promise that you could compile the same source on any POSIX-compliant OSs and get a binary that runs on that OS, on that architecture?

It's because cosmos implements POSIX in a portable way

POSIX was never about binary portability.

The binary portability is, in practice, not the most difficult feature, as long as the CPU arch is the same. It is also kind of a hack and IMO a nice-to-have feature but not as vital as true portability.

POSIX was not limited to the Unix world, the goal was for it to be implemented by all OS vendors, and it was partially done.

Doesn't matter. POSIX is "write once, compile everywhere," while this is "compile once, run everywhere." It could be that POSIX is easier to write than for Cosmo bins, shifting the balance between them! I see them as just different endpoints of development.

Well said. In reality, it has been more about supporting common system level APIs (think read, write, fork, etc).

Ah, yes, let's just keep on going without trying to make things better for anyone instead. That's sure to make things better!

Improvement doesn't come from passiveness. Someone, somewhere, will have to start first.

That was the most interesting part of the article for me. I don't understand how it can be faster, given that there's syscall translation going on. Is this more of a commentary on the quality of the `libc` available on Windows? Or on the quality of the GNU Emacs Windows port?

IIUC there is no syscall translation, it's more like there are separate libc implementations and the correct one gets selected at program start based on the OS.

So like in-process WINE?

Yes, this seems fairly accurate. In fact I think Wine supports this mode where you link Wine into a "windows program" at build time to produce a "native" Linux executable. So basically the difference is that you target a POSIX API rather than Win32 and the backend implementation is selected at runtime rather than build time. But both projects have the same idea that they will implement a particular API on multiple platforms.

Could be like the improvements seen when running applications using DXVK. My understanding is that sometimes these translation layers can use newer and more efficient methods than the path that a native implement for the time would use. I'm not a subject matter expert though, and could be completely off base.

Reply on news.ycombinator.com