[HN Gopher] QtCS2024: Compile once, Run everywhere
___________________________________________________________________
QtCS2024: Compile once, Run everywhere
Author : mmphosis
Score : 160 points
Date : 2024-09-06 23:55 UTC (23 hours ago)
(HTM) web link (wiki.qt.io)
(TXT) w3m dump (wiki.qt.io)
| comex wrote:
| 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.
| modeless wrote:
| Ah, I was wondering how they did the window system integration.
| CrendKing wrote:
| 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.
| axitanull wrote:
| 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?
| TimSchumann wrote:
| Made possible using Cosmopolitan Libc.
|
| Justine writes some pretty cool software.
|
| https://justine.lol/cosmopolitan/index.html
| wvenable wrote:
| 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.
| axitanull wrote:
| > 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.
| diggan wrote:
| > 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.
| Vampiero wrote:
| 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.
| sweeter wrote:
| 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.
| amelius wrote:
| 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.
| diggan wrote:
| What's "Universal" about UTC anyways? Just works on Earth
| :rolleyes:
| SebaSeba wrote:
| Should there be a link to some video or podcast somewhere there?
| I can only see a link to a pdf file.
| mseepgood wrote:
| The title: "Compile once" The transcript: "Cosmopolitan
| applications are compiled twice"
| notorandit wrote:
| 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.
| autoexec wrote:
| 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.
| JonChesterfield wrote:
| 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.
| notorandit wrote:
| This is when the dangers come in. Removable media with
| binaries roaming among different systems. The perfect vector
| for viruses and Trojans.
| wakawaka28 wrote:
| 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.
| exe34 wrote:
| how many milliseconds do you think wasting at the start is too
| much?
| ranger_danger wrote:
| ebassi moment
| GreenWatermelon wrote:
| 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.
| jenadine wrote:
| What makes electron easier to distribute? Electron is also
| made out of binaries which needs to be provided for each
| platform
| GreenWatermelon wrote:
| 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.
| jonathanstrange wrote:
| 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.
| notorandit wrote:
| 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.
| EasyMark wrote:
| 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
| esjeon wrote:
| 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.
| speed_spread wrote:
| 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!"
| flohofwoe wrote:
| It has no downside for the user, but simplifies automated
| builds and tests dramatically, because you don't need a 'build
| matrix'.
| notorandit wrote:
| Ever heard about autoconf/automake?
| flohofwoe wrote:
| 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...)
| bluGill wrote:
| 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.
| speed_spread wrote:
| Yes, only bad things.
| drowsspa wrote:
| There are billions of dollars in investment basically just
| to avoid dealing with those
| justinclift wrote:
| > 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.
| :(
| Y_Y wrote:
| 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.
| kevincox wrote:
| 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.
| flohofwoe wrote:
| 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).
| simjnd wrote:
| 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.
| jenadine wrote:
| Why not wasm?
| paldepind2 wrote:
| 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.
| api wrote:
| 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.
| diath wrote:
| > 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.
| mdaniel wrote:
| 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
| mwcampbell wrote:
| The web platform is the best set of standards and APIs we have.
| al2o3cr wrote:
| 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!
| zorgmonkey wrote:
| 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
| slekker wrote:
| Harsh reviewer IMO
| jlarocco wrote:
| 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.
| EasyMark wrote:
| 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.
| norir wrote:
| 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.
| jcelerier wrote:
| > 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)
| loglog wrote:
| 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?
___________________________________________________________________
(page generated 2024-09-07 23:01 UTC)