Live data from Hacker News

Show HN: dockerc – Docker image to static executable "compiler"

github.com

51–60 of 150 posts

Re: Show HN: dockerc – Docker image to static executable "compiler"

#51

Awesome use of that rant pic. Next rant pic- When I RUN a F*ING EXE it should open a Window with the application in it you smelly nerds!!!!

I know it feels like being pedantic and missing the joke, but "just give me the EXE" is a terrible bug, not a feature request. Distributing unauthenticated, untraced OS-level binaries is just dangerous in the modern world. Safe app distribution requires either elaborate sandboxed runtimes (browsers) or carefully curated and maintained lists of known-safe binaries (app stores, distro package repositories).

We can't be doing this "GIVE ME THE .EXE" anymore. Those days are gone.

Even building from source is questionable, but at least there it requires that the installer be part of (or at least adjacent to) a community of developers who can be expected to have the expertise to notice and recognize bad actors pushing code.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#52
post #46

I think this is a cute side project but as an actual piece of a company’s stack this just screams antipattern

Care to elaborate?

Sure. If you’re going through the trouble of containerizing your program and then compiling it into an executable, then you might as well just compile your program to an executable directly to begin with. Also, a system-specific executable is literally the antithesis of containerization. I know that over the years the programming landscape has evolved to the point that Docker has become yet another commonplace tool that newer devs don’t think much about and just see as a means of distributing code, and to be fair not a lot of people really groked it in the early days either, but this is truly unnecessary.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#55
post #52

Earlier quoted context omitted.

Care to elaborate?

Sure. If you’re going through the trouble of containerizing your program and then compiling it into an executable, then you might as well just compile your program to an executable directly to begin with. Also, a system-specific executable is literally the antithesis of containerization. I know that over the years the programming landscape has evolved to the point that Docker has become yet another commonplace tool t…

It's much nicer targeting Linux only from a developer standpoint than all 3 popular operating systems and all of the security vulnerabilities and toolchains and quirks for each. If you have the luxury of having a robust build pipeline for all of your targets with absolute confidence you're convering all of your bases then I applaud you. But from a developer and an end user point of view, if all I need to pursue is one download, regardless of platform, and that executable bootstraps itself and works, we would all be happier.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#56
post #51

Awesome use of that rant pic. Next rant pic- When I RUN a F*ING EXE it should open a Window with the application in it you smelly nerds!!!!

I know it feels like being pedantic and missing the joke, but "just give me the EXE" is a terrible bug, not a feature request. Distributing unauthenticated, untraced OS-level binaries is just dangerous in the modern world. Safe app distribution requires either elaborate sandboxed runtimes (browsers) or carefully curated and maintained lists of known-safe binaries (app stores, distro package repositories). We can't be…

I wish we could have something like exes with permissions. Similar to browsers. So I could run an arbitrary executable, but the OS level APIs would be blocked unless the user allowed the given permission.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#57
post #54

This sounds really cool, but, doesn't work for me, on version 0.2.1: $ ./dockerc --image docker://docker.io/pivotalrabbitmq/perf-test --output yourmom $ ./yourmom 2024-03-07T03:10:54.145333Z: chown `/dev/pts/0`: Invalid argument

Yep, this is a known issue. It also existed in the past with normal docker. https://github.com/NilsIrl/dockerc/issues/6

Re: Show HN: dockerc – Docker image to static executable "compiler"

#58
post #39

This is incredibly cool! Currently using docker as a way to easily distribute and run an open project[1], this would be great to use on top of docker Will this run ok on a Mac? (I see the feature is pending, any tests done yet?) [1] https://github.com/nicobrenner/commandjobs

Thanks!

> Will this run ok on a Mac?

I've managed to make it work but unfortunately not in a way that produces portable binaries. I just need to figure out how to selectively statically link some of the QEMU dependencies or write a runtime that uses Apple's VirtualizationFramework.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#59
post #6

Curious about the choice of Zig, any specific reason for using it?

The main reason Zig was chosen is because the project was started at a hackathon[0] at which there was a prize for "best use of Zig". Beyond that there were also other reasons: 1. I have been wanting to try out Zig 2. It fit the requirement of being a so called "systems language".

However having written it in Zig I have a few retroactive reasons for why Zig was a good choice (if not the best choice):

* The build system allows to make the runtime a dependency of the "compiler". I don't think any other language has that.

* The interoperability with C/systems calls is amazing (in comparison to anything but C/C++)

* The ability to embed files

* Makes it incredibly easy to make static binaries

[0]: https://treehacks.com/

[1]: https://github.com/NilsIrl/dockerc/blob/68b0e6dc40e76c77ad0c...

Re: Show HN: dockerc – Docker image to static executable "compiler"

#60
post #56
post #51

Earlier quoted context omitted.

I know it feels like being pedantic and missing the joke, but "just give me the EXE" is a terrible bug, not a feature request. Distributing unauthenticated, untraced OS-level binaries is just dangerous in the modern world. Safe app distribution requires either elaborate sandboxed runtimes (browsers) or carefully curated and maintained lists of known-safe binaries (app stores, distro package repositories). We can't be…

I wish we could have something like exes with permissions. Similar to browsers. So I could run an arbitrary executable, but the OS level APIs would be blocked unless the user allowed the given permission.

That would mostly be a browser, though. Changing the language used for the API to C (or whatever) from Javascript is mostly cosmetic, existing interpreter/JIT engines are extremely optimized, you can target basically anything to wasm, etc...

The problem isn't the technical hurdle, it's that sandboxed apps really aren't what we want in a lot of cases. There remain a lot of use cases for native apps the interact directly with the hardware in ways that are hard to abstract safely. Games need the whole GPU, backend middleware needs the raw network stack, you want to set up routing tables or a custom NAS, etc...

Those requirements don't go away even when "most" stuff can be done in a browser-equivalent sandbox. And... you need to rely on your Linux distro for those things still, or at least compile from an active github project. You can't just get raw binaries from whoever and expect to be safe.

Post reply on HN