• 12 Posts
  • 192 Comments
Joined 1 year ago
cake
Cake day: August 10th, 2023

help-circle





  • Maybe not some obscure ones, but here are some lesser known ones:

    Talos Linux. It’s an immutable operating system designed specifically to deploy kubernetes.

    OpenSuse Harvester Think Proxmox, but instead of VM’s and LXC containers, it’s VM’s and Kubernetes.

    XCP-NG is a RHEL based distro designed for managing Linux virtual machines using the xen hypervisor, as opposed to KVM. Think Proxmox, but RHEL and Xen (also no LXC). However, it does not come with a web ui out of the box, you have to deploy it yourself. Technically, XCP is a Xen distribution, since Xen is a kernel with nothing but a hypervisor that runs under the main distro, but the primary management virtual machine is RHEL based, and uses Linux.

    Speaking of Proxmox, Proxmox is technically a Linux distro.

    SnowflakeOS is a project that aims to bring a GUI focused experience to NixOS.

    TurnkeyLinux (site is loading very, very slowly for me right now) is not a single distribution, but rather a set of debian based distributions that are designed to be turnkey appliance virtual machines that contain and host a specific app. To deploy the app, all you have to do is set up the virtual machine.

    Now, here are some not-linux, but interesting distros:

    SmartOS. They ported KVM to unix, and also can use Linux syscall translation (similar to wine) to run apps in containers as well. There is also Bhyve. It’s a very interesting hypervisor platform.

    OmniOS is similar. Bhyve, KVM, and Linux syscall translation in containers.




  • Some software is so complex and difficult that Debian does not maintain it on their own, and instead follows the upstream release cycle.

    Browsers are one such example, and as you’ve discovered for me, Thunderbird is probably another.

    Also, please do not recommend testing for daily usage. It does not receive critical security updates in a timely manner, including for things that would effect desktop users. Use stable, Sid, or another distro. Testing is for testing Debian ONLY, and by using Debian Testing, you are losing the advantage of immediate security fixes that come from literally any other distro.



  • 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.












  • Why is SSPL not considered FOSS while other restrictive licenses like AGPL and GPL v3 are?

    So I have an answer for this. Basically all of the entities listed that relicensed their projects to the SSPL, also relicensed their projects using the dual licensing scheme, including one proprietary license. That’s important later.

    The SSPL’s intent is probably that the deployment framework used to open source this software must be open sourced. I like this intent, and I would consider it Free/Libre Software, but it should be noted that another license, the open watcom license, which requires you to open source software if you simply deploy it, is not considered Free Software by the FSF. I don’t really understand this decision. I don’t count “must share source code used” as a restriction on usage cases. It seems that the FSF only cares about user freedom, whoever is using the software, and views being forced to open source code only used privately as a restriction.

    Now, IANAL… but the SSPL’s lettering is problematic. What is part of the deployment system? If I deploy software on Windows, am I forced to open source windows? If I deploy it on a server with intel management engine, am I forced to open source that? Due to the way it is worded, the SSPL is unusable.

    And a dual license, one proprietary and one unusable means only one license — proprietary. There’s actually a possibility that this is intentional, and that the intent of the SSPL was never to be usable, but rather so that these companies could pretend they are still Open Source while going fully proprietary.

    But, for the sake of discussion, let’s assume the SSPL’s intent was benevolent but misguided, and that it’s intent was not to be unusable, but rather to force companies to open source deployment platforms.

    Of course, the OSI went and wrote an article about how the SSPL is not an open source license but that’s all BS. All you need to do is take a look at who sponsors the OSI (Amazon, Google, other big SAAS providers) to realize that the OSI is just protecting their corporate interests, who are terrified of an SSPL license that actually works, so they seek to misrepresent the intent of the SSPL license as too restrictive for Open Source — which is false. Being forced to open source your deployment platform still allows you to use the code in any way you desire — you just have to open source your deployment platform.

    Is there some hypothetical lesser version of SSPL that still captures the essence of it while still being more restrictive than AGPL that would prevent exploitation by SaaS providers?

    AGPL. There’s also Open Watcom, but it’s not considered a Free Software license by the FSF, meaning software written under that wouldn’t be included in any major Linux distros.

    I think in theory you could make an SSPL that works. But SSPL ain’t it.

    Of course, there are problems with designing an SSPL that works, of course. Like, if you make it so that you don’t have to open source proprietary code by other vendors, then what if companies split themselves up and one company makes and “sells” the proprietary programs to another.