Personally, I am loving flux right now. I'm using it to set up my homelab right now, while I learn kubernetes.
I chose flux because it seemed lighter, without a web ui or any extra components I may not want. Using flux feels like getting the declarativity that nixos promised but couldn't really deliver on.
Also, I did note on another post, that Forgejo, who used to use imperative kubernetes for everything, is now switching to fluxcd.
Did you use flux 1, or flux 2?
Flux 2 is a complete rewrite, and is basically a different app.
Does forgejo really have an integrated CI/CD? I see this article, but it says it was put in beta, and no real notes after that. Although, it does look like the forgejo runner is a fork of https://github.com/nektos/act, which is a tool designed to be compatible with Github Actions, so that looks promising.
flux, Argo (better than flux)
Why Argo better than flux? The only real difference I know about is that argo has a web GUI built in, whereas flux does not.
Is there a specific android app you need?
https://gitlab.com/android_translation_layer/android_translation_layer/
And of course waydroid. Both these solutions let you run android app on Linux, but like wine, they won't work for every app.
Waydroid probably works for all apps not dependent on google though. But it's more difficult to set up than the android translation layer.
Debian already has docker packaged. That's more convenient.
Debian with the docker convenience script.
They seem to be moving away from this, and it's not longer the first option on their install page
On their debian page
Use a convenience script. Only recommended for testing and development environments
Also, it should be noted about the first option they recommend, Docker Desktop, that Docker Desktop is proprietary.
I recommend just getting the docker.io and docker-compose from debian's repositories.
Ubuntu in WSL comes with systemd enabled. Debian doesn't, and you have to enable it yourself.
That's why I chose to have people use Ubuntu in WSL, despite the other downsides. One less step to setup a Linux environment on Windows makes the process smoother.
Wish I could transcend into declarativity but the thread’s nix survivor ratio is grim
Yeah lol.
I will say, that for my server, I decided to use kubernetes + fluxcd for declaratively. My entire kubernetes "state" is declared in a git repo, and this is the popular, industry standard for things like this, called GitOps. It makes it very easy to add an app, since it's just adding a folder + some new config files. And unlike Nix, Kubernetes and Flux are very well documented with much tooling as well. Nix doesn't really have a working LSP or good code autocomplete, but with kubernetes, I can just start typing in a yaml file and then hit tab and it spits out the template for me. Code autocompletion with kubernetes feels much more similar to the tooling of other, more mature tooling
It's not as declarative as nix though. There are things missing, like OCI containers could theoretically shift if you don't rely on hashes and some other nitpicks. But declarativity is a spectrum, and I feel like, outside of scientific scenarios (think simulations where versioning, hardware, runtime etc being the same is very important), I think many non-nixos solutions are declarative enough.
Advice online seemed like i needed to basically create a nix flake for the app. I still havent gotten it installed because i have no idea what nix flakes are.
So, the problem is that flakes are technically an "experimental" feature, and thus are not allowed to be included as a primary solution in the official documentation. But, basically everybody uses flakes, so it leads to this crazy documentation split, and is a big part of why documentation on Nix is so bad.
Some stuff can only be done with flakes, some stuff only with non-flakes and you have to figure out which is which on your own, while also dealing with the poor documentation for either.
The advice you received was wrong. You could also use a combination of a default.nix file and a shell.nix file to create a package and development environment for your app. But, the documentation is so poor that it's unlikely you will learn this, and figuring out how to do this on your own, is again, a massive time sink.
So, I use Arch, but I don't use the AUR at all. Instead, I use nixpkgs to get stuff (admittedly only like 3 packages) not in the Arch repos.
The main reason for this is the quality of AUR packages. Although I don't really fear a malicious package, I do remember hearing about a package that moved a users /bin to /opt during the install phase.
Something like that is literally impossible with Nix, due to the way that applications aren't really installed to the system. But, nixpkgs also requires some level of vetting the package quality, which is also nice.
I also use nix for managing all my development environments. For example, my blog github repo, has a few nix files at it's root, and you should just be able to type nix-shell in folder, and then you will get an identical environment to me.
declarative rollbackable immutability sounds really freakin’ AWESOME
I have BTRFS snapshots set up, and with grub-btrfs, I can even boot from them and revert to an older kernel (my /boot is stored on BTRFS).
However, I have given up on NixOS, for many reasons. The documentation is very poor, and it's more complexity than it's worth, to make my whole OS reproducible, rather than just my development environments. In addition to that, their are also issues with running certain apps that expect to see a normal FIlesystem Hierarchy, which nix does not provide. Although you can work around this with stuff like steam-run or creating a fake FHS using nix, I would rather not play that game.
But, considering I installed some stuff in an Ubuntu 22 distrobox recently, because that was what VScode and Unity official provide repos for, maybe this doesn't really matter. You can probably use distrobox on Nixos, but I've seen issues about GPU acceleration with distrobox (and other non-nix apps) as well.
EDIT: I lied, I use the chaotic aur for some things.
OP seems to be trying to install older projects, rather than creating a new project.
No. Apple claims updates aren't forced. With proprietary software, we have no way to verify if they have some way of forcing an update through.
No. Apple claims that only the user can enable automatic updates. With proprietary software, we have no way to verify if Apple can enable them remotely.
Also, are you really going tell users to not update?
No. Apple claims that updates cannot affect user data. Again, with proprietary software, there is no way to truly verify.
Oh...so updates are good now, and we should update, even if it puts us at risk of something malicious?
You are taking Apple's claims as truth and pretending they are good. They probably aren't.
But, as someone else mentioned in the thread: The US government can force companies to spy for them. Even if Apple was as good as they market themselves to be, they cannot outrun the government.
Now, it's not realistic to force everybody to switch away from iPhones. But, we should stop treating proprietary software as truly trustworthy with our data.