It's the other way around. Nix sucks. (Guix sucks too.) However, every other build system I've used, as well as every other package manager and every other distro, sucks more.

You're doing fine. Slow down. Forget "installation"; it's not a concept Nix uses. If jumping directly to NixOS is overwhelming, it might be easier to go back to Arch, Ubuntu, or something else you know and are comfortable with, and use Nix from a familiar distro; build up idioms for working with your preferred tools, development environments, and configuration. When you're ready, you can try NixOS again, and hopefully it will make more sense.

nix-env must evaluate all of nixpkgs and the reference implementation of Nix is not very fast. It's not a big mystery, although it appears that a rewrite of Nix will be required to improve it.

Sarcasm needs to be humorous; you're merely rattling off insults. Anyway, it's pretty uncommon that somebody literally "can't contribute code;" anybody who can learn how to use a computer and post juvenile horseshit to Lemmy can learn how to write code. I'm a former professional musician; writing code is my backup career, taking less practice and effort than playing the piano. I encourage you to try putting in some effort; for the same time it takes to write around 500 comments/month on Lemmy, you could probably build a program that automates or simplifies some portion of your life.

And seriously, by doubling down on the idea that being Neanderthal is bad or deficient, you're spouting some nasty rhetoric. It doesn't matter whether you're serious or not; eventually, you'll forget that you were being ironic. "Those who play with the devil's toys will be brought by degrees to wield his sword" and all that.

As a hardware hacker, I've experienced Apple's anti-FLOSS behavior. I was there when Apple was trying to discourage iPodLinux. In contrast, when we wanted to upstream support for the Didj, LeapFrog gave us documentation and their kernel hackers joined our IRC channel. It's the same reason that people prefer ATI/AMD to nVidia, literally anybody to Broadcom, etc.

Your "entire fucking point" is obvious from the top-level comment you replied to; you've taken offense to somebody pointing out that writing FLOSS on Apple hardware is oxymoronic. And it's a bad point, given that such a FLOSS hacker is going to use Homebrew or Nix in order to get a decent userland that hasn't been nerfed repeatedly by an owner with a GPLv3 allergy and a fetish for controlling filesystem layouts. Darwin is a weird exception, not one of the easy-to-handle BSDs.

Also, what, are you not anti-Apple? Do you really think that a fashion company is going to reward you for being fake-angry on Lemmy?

At their most general, they are "data processors." In common parlance, they're often called "algorithms," although some folks insist that that is reserved for programs with trivial control flow. For disambiguation and comparison:

• A service is an API surface and a contract promising that the surface has certain behaviors; data processing may be part of how the API is implemented. In practice, a service is e.g. an HTTPS endpoint and an OpenAPI specification.
• A capability is a copyable token which simultaneously authorizes its holder to perform an action and designates the holder as having the authority to perform that action. This won't be part of your normal curriculum and training; see this post for an introduction, or this story for motivation.
• A controller is a modulator for a (distributed) system. Typically a controller is anything which is actuated by a control loop, although sometimes a controller can sit outside of the system. Common examples include MVC patterns, k8s components, and video-game controllers.

Steps 8, 9, and 11 assume that the filesystem is in a Linux-compatible state and Windows-compatible state simultaneously.

You're literally posting from the SDF's instance. If you're not going to support FLOSS, then consider migrating to a server which reflects your beliefs. (Also, go take an anthropology course so that you don't embarrass yourself by dehumanizing people online.)

Mattermost is the most obvious option; it's a clone of Slack. IRC is another good option, although I know a lot of people hate it because they prefer features to freedom. I cannot recommend Matrix; the UX is fine but the cryptography has a few issues, as documented by Soatok here.

The biggest barrier is writing lots of formatted data to disk without a pre-existing filesystem structure. Look at nixos-anywhere for an example; the first thing it does is ensure that it's booted into Linux, because otherwise it can't trust that the disks are laid out properly.

I gather that Sublinks is an ActivityPub service similar to Lemmy, intended for hosting communities of link-sharers and discussions. I also gather that this is the repo where work will happen.

I see that you're taking donations. How are those donations used? A short blurb about spending would improve transparency.

You're cheering for exploitation of a commons.

The flake exports look like outputs.nixosConfigurations.joker, each one matching a hostname. There's a poorly-documented feature of nixos-rebuild where you can point it at a flake with --flake and it will try to use the configuration matching the current hostname. So, I make the flake available on each machine and customize it using the hostname. One flake, a dozen machines. Works well enough for a homelab but would not work for a large cloud deployment.

Oh, right, monoids! Yes, you understand correctly.

A monoid is a collection of objects that has some sort of addition and zero. (Depending on your maths background, it might equivalently have some sort of multiplication and unit.) Addition must be associative, and addition with zero must not have any effect. Monoids let us think of a system as built from a sequence of operations; each operation adds to the system, preparing its state incrementally.

Sometimes monoids are commutative, which means that the order of additions is irrelevant to the result. Commutative monoids let us think of a system as built from a collection of operations without worrying about the order in which those operations are applied.

NixOS modules (and HM modules, etc.) are commutative monoids. The zero is {}. The module system lets options declare their own monoids which ride along, like my example of allowedTCPPorts. Because we can combine sets of port numbers (with set union) and get more sets, we can factor a set of ports into many smaller subsets and put each one in their own file. Here's my shortest module, for an internal Docker registry, docker-registry.nix:

{
  networking.firewall.allowedTCPPorts = [ 5000 ];
  services.dockerRegistry = {
    enable = true;
    enableGarbageCollect = true;
  };
}

I'm adding some code snippets from my homelab's flake. Minor details are changed. Note how I have a core.nix and also separate files for adding Avahi (zeroconf) and SSH, and for fixing bufferbloat. I could have them as one file, but it's easier to come back to them after several years this way. (bufferbloat.nix was last changed in December 2021, for example.)

I know that some of this code style probably seems weird. Think of it as heavily inspired by Puppet, Chef, Ansible, HCL, etc.; when we are configuring a system, it is very very nice to be able to comment out a single line at a time.

    commonModules = {
      imports = [
        nixpkgs.nixosModules.notDetected
        ./avahi.nix
        ./bufferbloat.nix
        ./core.nix
        ./ssh.nix
      ];
      nix.registry.nixpkgs.flake = self.inputs.nixpkgs;
      nixpkgs.config.packageOverrides = pkgs: {
        mumble = pkgs.mumble.override {
          pulseSupport = true;
        };
      };
      users.users.corbin = {
        isNormalUser = true;
        extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
      };
    };

      joker = nixpkgs.lib.nixosSystem {
        inherit system;
        modules = [
          commonModules
          ./joker/configuration.nix
          ./gl.nix
          ./sound.nix
          ./wifi.nix
          ./xserver.nix
        ];
      };

And for anybody thinking of implementing M-expressions, look at Wolfram Mathematica, which is the only popular M-expression-oriented language. It turns out that high-level graph-rewriting semantics are difficult to make efficient! (If you want to try, you might also want to look at GHC or other efficient graph-rewriters to see what the state of the art is like outside Planet Wolfram.)

At scale, you'll appreciate explicitly spelling out your imports. I currently have 23 importable files, of which two are mutually incompatible (headless vs. Xorg). I don't want a glob over these files because no machine can have all of them; indeed, most machines only have like five imports from the list.

What might be more interesting to you is a common collection of modules which must be imported everywhere. To achieve this, I explicitly declare a commonModules at the top of my flake and reuse it in each machine definition. Another approach might be a common.nix module which recursively contains the common modules as its own imports.

Finally, it doesn't "defeat[] the point of separating" expressions into multiple files to avoid globbing over them. Because NixOS/HM modules are monoidal, they often factor nicely. When you have a dozen different services, you could stuff all of them into one file with one networking.firewall.allowedTCPPorts if you wanted, or you could put each service into its own file and let each module bring its own port to the combined configuration. The latter is easier at scale; I have nine modules declaring TCP ports and five machine-specific TCP ports as well, and it would be a pain to put all of them in one location.

I remember seeing this when it first came out; since then, I've developed an object-oriented actor-based language and also a data-driven function-based language. I disagree with different things now! I mostly agree, actually, but:

Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs.

I don't understand what this is complaining about; it seems too pejorative to be actionable. Generously, he might be complaining about Sufficiently Smart Compilers, and that lines up with later slides; cynically, he might be complaining about garbage collection, a well-worn dead hobby-horse of game developers. It could also be a dig at the unintuitive evaluation order of languages like Haskell or OCaml.

Ah, no worries. There should be an introduction-to-literature course in your native language, covering the classics and important works of your native culture. I still stand by the rest of the recommendations. By "bachelor of arts" and "bachelor of sciences" I mean how your college/university accredits degrees; computer science and engineering are usually "science" degrees but many universities have an alternative "art" version that you can choose.

The article is hilariously ill-researched, to the point where it might well be a marketing post. GCC used to have Java support; it was discontinued due to a lack of interest and usage. There is no fundamental barrier to implementing AOT Java. Java's designers intentionally were making a statically-typed first-order Smalltalk that could be efficiently JIT'd; the language is designed for JIT instead of AOT.