max-privatevoid

Why call it "Cppnix"?

I wonder who's to blame for that.

> This is like saying "black is white".

Take a simpler example. If you have the freedom to imprison me for no reason, you can take away my (literal) freedom. Now you are free, but I am not. Because of this imbalance, the freedom to arbitrarily imprison people is an unreasonable one. Everyone should have as much freedom as possible, and everyone should have the same "amount" of freedom, if you will, so restricting others is out of scope. It's not just about your own freedom, don't be selfish! And besides, what ethically good person would want to lock people up for no reason?

When you are creating proprietary software, you are asking your users to let them be oppressed by you. You are asking them to give in to potential surveillance, planned obsolescence, manipulation, extortion and a variety of other injustices. And when you charge a price for your proprietary application, you are asking your users to pay for this mistreatment. What value does "the best product" really have, when you pay for it with your wallet and your freedom?

Your antique monetization scheme does not align with the values of Free Software. Should you restrict your users' freedom, or fix your monetization scheme?

In short, if you want to appear like a corporation who acts in bad faith, aims to abuse their contributors and only cares about FOSS for the free labor they get from the people who are gullible enough to contribute, a CLA is a great choice for your product!

Q: What's wrong in having a CLA? A: It allows you to re-license your project in future.

It gives the original author the right to relicense your contributions at a moment's notice, to a license you might not agree with. It effectively means that you cannot contribute to the project under fair terms.

A CLA is similar to a EULA in the sense that most people don't care about it and blindly click "Agree", and as such are unaware of the potential consequences. Look at what happened when HashiCorp relicensed its projects. People were outraged. They agreed to the CLA, so they must have known that this could happen. But did they really take the time to understand what they were signing?

As a contributor, you should never agree to a CLA. As the original author, requiring your contributors to sign a CLA sets an extremely bad precedent.

You're misinterpreting it. Integrating FOSS code into a proprietary product is what restricts the user's freedom. Copyleft licenses prevent this restriction. And yes, indeed, why bother working for freedom if it's easier to not have freedom?

See https://www.gnu.org/philosophy/why-copyleft.en.html

Maybe I should start insisting on the term "FOSS".

Pushover licenses ("truly open source") enable the exploitation of FOSS developers in the name of easy profit for the people building proprietary software around it, while Copyleft licenses ensure that this does not happen, granting each user the essential freedoms. The restrictions are not arbitrary, they exist precisely to ensure that these freedoms cannot be taken away from anyone. If this hinders widespread adoption by companies, it just means that those companies didn't plan on respecting the essential freedoms.

Do those companies really care about open-source, or just about code they can freely integrate into their proprietary products?

It's not possible to sell non-FOSS modifications to AGPL-licensed software. I think that's intended. It's not antithetical to Open Source, quite the opposite in fact.

The AGPL is probably the best option for a FOSS license. Why do you consider it "not truly open-source"?

Please do not use the AGPL as a marketing point when you have a CLA.

Spreading copyright among as many entities as possible to make relicensing more difficult is not a problem you should "solve". It's a feature of the license. A CLA ensures that contributors will be treated unfairly, and I hope it deters many potential contributors.

This is why you should look for software that calls itself "FOSS" or "Free Software" instead. Avoid CLAs at all costs as well. If the software is licensed under a GPL-like license without a CLA and has had significant contributions from multiple people, this relicensing rugpull is nearly impossible.

It's not Open Source, it's not open. Being "close" to Open Source is completely useless.

Source-available has a very misleading nature, and as such is commonly used for openwashing. You can read the source, but you can't really do anything with it. That's not how it usually is when you are given access to the source code. Companies such as Anytype market their source-available product as "Open Code" or similar. They are carefully avoiding the term "Open Source", but they still make many ambiguous claims of openness. Tuist is doing the same thing:

> As you might know, we aim to make Tuist a fully open project.

> So I think a fully open Tuist platform could unfold this way: [...]

The intention is clearly to NOT be fully open.

> We can only build the best in class productivity platform if we embrace openness.

They are not embracing openness. They are trying to reap the benefits that come with being open, such as code contributions and a higher level of trust, while not actually being open.

I think the idea that businesses can't use GPL- or AGPL-licensed code is absolutely ridiculous. This false premise seems to be omnipresent in every license discussion.

How is the AGPL unenforcable?

Perhaps one day we will have a way to monetize software development that works for true Free Software and doesn't require these bullshit openwashing licenses.

NixOS

But then you'd have to use YAML

Reproducible, you say.

> RUN apk update

The problems that Nix gives you are much nicer to have than the problems of tbe FHS absurdity.

Just use Nix

Nix with dynamic derivations (RFC92) could potentially beat this curse.

https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dyn...

I decided to participate in your challenge and cleaned up your Nix code a little bit. It seems like the main task of the challenge is building a really small JRE.

I've switched to using a headless OpenJDK build from Nixpkgs as a baseline instead of Zulu, to remove all the unnecessary dependencies on GUI libraries. Then I've used pkgs.jre_minimal to produce a custom minimal JRE with jlink.

The image size now comes out to 161MB, which is slightly larger than the demo_jlink image. This is because it actually includes all the modules required to run the application, resulting in a ~90MB JRE. The jdeps invocation in Dockerfile_jlink fails to detect all the modules, so that JRE is only built with java.base. Building my minimal JRE with only java.base brings the JRE size down to about 50MB, the resulting (broken) container image is 117MB according to Podman.

I've also removed the erroneous copyToRoot from your call to dockerTools.buildImage, which resulted in copying the app into the image a second time while the use of string context in config.Cmd would have already sufficed.

I've also switched to dockerTools.buildLayeredImage, which puts each individual store path into its own image layer, which is great for space scalability due to dependency sharing between multiple container images, but won't have an impact for this single-image experiment.

This is mostly a JRE size optimization challenge. The full list of dependencies and their respective size is as follows:

  /nix/store/v27dxnsw0cb7f4l1i3s44knc7y9sw688-zlib-1.3                            125.6K
  /nix/store/j6n6ky7pidajcc3aaisd5qpni1w1rmya-xgcc-12.3.0-libgcc                  139.1K
  /nix/store/l0ydz31lwa97zickpsxj2vmprcigh1m4-gcc-12.3.0-libgcc                   139.1K
  /nix/store/a3n1vq6fxkpk5jv4wmqa1kpd3jzqhml9-libidn2-2.3.4                       350.4K
  /nix/store/s5ka5vdlp4izan3nfny194yzqw3y4d1z-lcms2-2.15                          445.3K
  /nix/store/a5l3w6hiprvsz7c46jv938iij41v57k6-libjpeg-turbo-2.1.5.1                 1.6M
  /nix/store/r9h133c9m8f6jnlsqzwf89zg9w0w78s8-bash-5.2-p15                          1.6M
  /nix/store/3dfyf6lyg6rvlslvik5116pnjbv57sn0-libunistring-1.1                      1.8M
  /nix/store/a3zlvnswi1p8cg7i9w4lpnvaankc7dxx-gcc-12.3.0-lib                        7.5M
  /nix/store/657b81mfpbdz09m4sk4r9i1c86pm0i8f-app-1.0.0                            19.0M
  /nix/store/1zy01hjzwvvia6h9dq5xar88v77fgh9x-glibc-2.38-44                        28.8M
  /nix/store/b1fhkmscb0vff63xl8ypp4nsc7sd96np-openjdk-headless-minimal-jre-21+35   91.4M

There's not much else that can be done here. glibc is the next largest dependency at ~30MB. This large size seems to be because Nixpkgs configures glibc to be built with support for many locales and character encodings. I don't know if it would be possible or practical to split these files out into separate derivations or outputs and make them optional that way. If you're using multiple images built by dockerTools.buildLayeredImage, glibc (and everything else) will be shared across all of them anyway (given you're using roughly the same Nixpkgs commit).

https://github.com/max-privatevoid/hackernews-docker-challen...

Absolute, immutable store paths are the main reason why Nix is so good in the first place. The key assertion is that FHS sucks. Using complicated and brittle namespace tricks to construct virtual FHS's everywhere is nothing more than shoving the problem under the carpet. It severely limits the places where Nix can be useful. You usually can't create nested namespaces inside a Docker container, so you couldn't use "Namespace-Nix" programs there. You're also destroying the ability to compose packages and environments. Using multiple versions of the same package within one environment - another goal of Nix - becomes impossible. Implementing NixOS in such a paradigm would be a nightmare, and the result would be very limited compared to what NixOS can do now.

Yes, having to clean up RPATH after compiling a program sucks. Yes, having to implement workarounds to make build tools that desperately cling to their FHS traditions work sucks. These are effectively bugs and/or design errors in those tools. Packages are supposed to be installable into various different prefixes, Nix or not. That's why ./configure --prefix= exists.

The wheel needed to be reinvented because the old one was square.

A small PSA about nix-env and its issues as well as what alternatives to use.