QtCS2024: Compile once, Run everywhere | Hacker News Reader

QtCS2024: Compile once, Run everywhere

wiki.qt.io

176 pointsmmphosis63 comments

Open articleView on HN

Made possible using Cosmopolitan Libc.

Justine writes some pretty cool software.

https://justine.lol/cosmopolitan/index.html

How does one get a job like this? Just writing absolutely wild and weird projects?

I do weird/fun stuff on my own time but I get paid to do mostly boring stuff.

> Funding for this project is crowdsourced using GitHub Sponsors and Patreon.

Based on the project github page, it seems that this is their version of weird/fun stuff, that is not done as a part of their job.

> How does one get a job like this? Just writing absolutely wild and weird projects?

Work for any huge corporation that has to pay huge salaries for people to work on soul-less projects for a couple of years, then retire and hack away. In the case of Justine, it seems the corporation was Google.

Just have enough money that you don't have to sell your soul to the devil for a job in webshit consultancy, where they're STILL busy reinventing the CRUD wheel for some reason. Probably because hell means an eternity of torture, and consultancy is hell.

So either be born rich, or slave away until you no longer have to worry about not eating. Then you can work on all your pet projects and feel fulfilled about your job and life. If you're not dead yet from all the accumulated stress, that is.

blinkenlights is amazing! The entire time I was learning programming I thought to myself "hmm I wish I could see what the memory and registers actually look like at any given step" and bam, blinkenlights. Its an amazing piece of work.

Run anywhere?

Nice try, I'm on nVidia Jetson and everything depends on a fixed version of libc, so if I want to use nVidia's gpu libraries, I better use their version of libc.

What's "Universal" about UTC anyways? Just works on Earth :rolleyes:

I wonder if cosmo libc supports targeting versions.

Cosmopolitan Libc software works fine on Jetson and is able to use GPU. See llamafile as an example.

I have a philosophical objection to this approach, while respecting the technical achievement. For me, the ideal distribution of software is always by source. The only reason I wouldn't want this is if compilation is prohibitively expensive. But I have found that usually this is only the case for truly massive projects like chrome or projects with heavy dependencies. Most c programs can be compiled in at most a few minutes but usually just a few seconds (luajit and sqlite come to mind as being in the seconds camp). The big problem is that culturally we have accepted too many dependencies in libraries and this has made building too slow and has made binary distribution feel necessary. It is actually much faster on my computer to build neovim from source than upgrading it from homebrew if the upgrade triggers a cascade of dependency updates (which basically seems to happen every time I update anything using homebrew).

I also can't envision a common scenario in which I would have a machine that doesn't have a c compiler but I would be able to run an APE executable. Even in that uncommon case, I still think I would be better off using software that I could compile with a standards compliant c compiler and ship the binary that _I_ built myself to the machine that lacked a c compiler.

> I also can't envision a common scenario in which I would have a machine that doesn't have a c compiler but I would be able to run an APE executable

99.99% of people who want to run executables on mac or windows don't have a C or C++ compiler installed and wouldn't have the knowledge to operate it if they did. And if you want to install the default one for these platforms (MSVC or XCode) it's at least 30 minutes of download + 30 minutes of installation. For me this really solves an actual problem I've had customers & team members ask me hundreds of time - "how can I compile a Qt app for Mac when I'm on Windows" (and the inverse)

For me, cargo is among the most reliable package managers these days. It is about as convenient as any other Linux package manager (and therefore much better than the feeble Windows or Mac alternatives), yet also compiles from source. I evidently don't fall into the 99.99% of Windows users without a C compiler, but I also never write Rust. Anyway, the point that I am making is that it is entirely possible to have a distribution chain that involves a compiler and a user that does not know how to operate that compiler. And how is that fundamentally different from JIT compilation in a JVM or JS runtime anyway?

Key point:

> running with the vnc QPA

The demo they have running has no native display or input support; it just serves the interface over a socket via VNC.

Ah, I was wondering how they did the window system integration.

> The size of the Cosmopolitan Qt Creator binary is around 230 megabytes

While it's kind of expected it'd be big... that's really large. :(

At some point it's going to be easier to ship a fat binary of a compiler or bytecode interpreter along with a single representation of your application.

And then the cycle begins anew.

What is the reference size? It is hard to compare.

For many applications the size of "assets" like images, localization data and other stuff will vastly outweight the code.

I expect that's a statically linked executable which includes all dependencies for ARM and x86. If you add up the size of dynamic link libraries of a regular Qt Creator installation on macOS you get about 400 MBytes (those are universal binaries which contain both ARM and x86 code).

APE binaries usually come with an option to "assimilate": once downloaded, you can choose to only keep the stuff relevant to the platform you're currently using. Best of both worlds.

The title: "Compile once" The transcript: "Cosmopolitan applications are compiled twice"

Interesting approach, but the results seem as rough as they usually are regarding cross-platform UX.

For instance, check out the demo on slide 10: now you can have janky sliders that don't match the platform's version on every platform!

The codereview of the WIP patches are a nice read. They do a good job of showing how quirky Cosmopolitan Libc is. To be clear I think it is awesome, just don't expect porting to it to be pain-free.

https://codereview.qt-project.org/c/qt/qtbase/+/581112

Harsh reviewer IMO

I respect this a lot as an impressive hack, but it's really sad that in 2024 we are headed toward a "statically link the entire universe" approach to software distribution because OSes have failed to provide good consistency, stability, or portability.

WASM could solve all this, but that would mean all OSes would need WASM runtimes that supported a consistent set of standards and APIs. Have fun getting that to happen.

> WASM could solve all this, but that would mean all OSes would need WASM runtimes that supported a consistent set of standards and APIs. Have fun getting that to happen.

I mean if that's your solution to the problem, then Java already solved it.

I agree in principle with your assertion, with a small asterisk that what you said would be true if the JVM was baked into the OS

As it stands now, because the JVM is merely an application, it needs tomfoolery to JNI out to anything interesting. One can see this in effect with Eclipse's SWT which to the best of my knowledge uses JNI for all its UI trickery (e.g. https://github.com/eclipse-platform/eclipse.platform.swt/tre... )

Pour one out, I guess: https://en.wikipedia.org/wiki/JavaOS although it's a fascinating thought experiment to invert that problem where JavaOS actually uses JNI to run Proton/Wine :-D

The web platform is the best set of standards and APIs we have.

Should there be a link to some video or podcast somewhere there? I can only see a link to a pdf file.

This is a neat idea.

Generally, though, third party libraries are the biggest problem I've had building Qt apps on different platforms. Qt itself "just works," but getting arbitrary open source libraries building on OSX and Windows can be a pain.

That’s why I use everything that I possibly can from qt libraries even if there are open source libraries that might be easier to use or more performant than qt versions.

> Qt QPA VNC platform.

I've not heard of this before. Who is using it and for what? And how?

Also, who / what is .Adam?

Why? To make it simpler to distribute binaries? What is the use case share for portable binaries across platforms? The platform check is to be run at every single run, not just once, if I am not mistaken. I thought we were aiming at efficiency.

It is an interesting and intriguing technology, but pretty useless if not even dangerous, IMHO.

Seems pretty damn useful to me. You can throw a bunch of programs on a flash drive and use them on any computer you happen to be in front of.

The programs mutate themselves at first use, or at least they did originally, meaning the drive needs to keep copies of the original on it and copy them before running to later work usefully at a second machine.

This is when the dangers come in. Removable media with binaries roaming among different systems. The perfect vector for viruses and Trojans.

It literally says in the first sentence that deployment on many platforms can be challenging. Checking the platform is trivial, presumably, and a necessary part of what is being done here.

I agree that this might be a dangerous thing to use, but it's not unprecedented. This has a lot in common with using cross-compiling process. If performance is good, it could potentially replace something like AppImage I guess. However, making all your dependencies compile with this thing and then debugging the result may end up being harder than maintaining however many separate builds. It sounds amazing to me that they got Qt to work with this tool. I don't see myself using this but I might take a closer look one day for the hell of it.

how many milliseconds do you think wasting at the start is too much?

ebassi moment

Ease of distribution is what made Electron so dominant (in addition to being familiar to web devs), leading application providers literally bundling an entire web browser just to display a single website.

Here's your use-case: providing a saner alternative to Electron. The Qt solution is more performant than the current solution.

What makes electron easier to distribute? Electron is also made out of binaries which needs to be provided for each platform

While that has to be done, it doesn't have to be the developer.

Electron provide a solution for that https://www.electronforge.io/

So you whip up a web app, throw it into the forge, and bam you got your binaries.

It's insanely cool and not dangerous at all. Why would it be dangerous?

But I'm sure the platform owners, notably Apple and Microsoft, will find ways to prevent the widespread use of such technology. You have to buy certificates, notarize, sign, get reviewed, etc., so they can make extra money off developers and keep total control of their users in the name of some fake security theater. That's why everybody is writing web apps instead.

It'd be dangerous to bring portable binaries among systems on removable media.

Again, platform checks are run at every binary run instead just once at compilation time.

That’s a rather specific case, why not have the apps on a company server that permitted people can fetch? Installers from the web? One app that works across Mac, Linux, PC is quite nice with only one code base to maintain. That’s just one way this is useful and shouldn’t be characterized as dangerous

I'm also curious about the actual usecases. This seems very highly niche.

This can also lead to security issues, as it encourages the use of shared folders or USB drives for carrying around executables. You should never reuse executables from other systems - always download one from the first party.

What is it with USB drives that bothers you people so much? It's just storage. Apps could also come from a cloud drive, which would be no more dangerous.

All I hear is "ewww, physical media!"

It's not about USB. It's about executables, and syncing-over-cloud is equally dangerous w/ executables. Perhaps, syncing is worse than USB, because it will write executables right into your home directory, which isn't mounted with NOEXEC flag, where USB would be mounted with it by default (depending on the policy).

Security-wise, copying executables b/w systems amplifies the risk of escalating partial write access on one system to full system access on many other systems. This would be an easy building block for "Advanced Persistent Threat"[1] attacks.

[1]: https://en.wikipedia.org/wiki/Advanced_persistent_threat

It has no downside for the user, but simplifies automated builds and tests dramatically, because you don't need a 'build matrix'.

Ever heard about autoconf/automake?

Yeah, it's outdated crap and doesn't work on Windows with MSVC, better use an actual cross-platform build tool from the current century ;)

Proper build tooling still doesn't change the fact that you need to stamp out one binary per OS and CPU architecture, potentially using different compilers. This is always brittle (I would know: https://github.com/floooh/sokol-tools/actions/runs/107248810...)

I have yet to find an autotools project that crosscompiles out of the box there is always some detail that doesn't work. Autotools always provides the ability to do it but it isn't by default.

Yes, only bad things.

There are billions of dollars in investment basically just to avoid dealing with those

The page 8 ("Building") of the slides has the badger picture to the right. His right hand has some weird "nails". Another example of AI-generated image.

And the file served is of pdf file. The font used is Titillium Web. The color of my bike shed is that of brown wood color.

Did I also contribute to the discussion of the tool?

All the honey badger (mascot of cosmopolitan libc) images were generated using FLUX.1-schnell on my MacBook Pro M1 Max.

I've blogged about all the AI usage at https://www.qt.io/blog/examples-of-local-llm-usage

Why not wasm?

The description on cosmopolitans webpage states:

> Cosmopolitan Libc makes C a build-anywhere run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine.

WebAssembly would not achieve the same thing as it's in the same category as Java bytecode where you need some interpreter/VM/JIT/compiler to actually run it.

Reply on news.ycombinator.com