8 ms·

I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I fou

I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don’t think I could really recommend to any of my peers. It’s too bad guix went full hardcore FOSS and refuses to support macs, because they seem to have better docs and using a language that I can use outside of my package manager makes a lot more sense to me.

40yearoldman 4y ago
I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so. Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware. If anything the Nix documentation is just as good as every other thing out there. What is different is there are more than one way to do many things in Nix. This to me I think is the core of complaints. Its a language, and thus the language has may expressions that result in the same outcome. The second bit I think people struggle with is it is functional. If you look at Nix complaints they appear to nearly be identical to that of Haskell.
- CapsAdmin 4y ago
  I also didn't notice that the documentation was especially bad. I'm thinking maybe it makes more sense for some programmers?
- kstenerud 4y ago
  Then you are a superhuman. I too went through weeks of pain and suffering to get my nixos hypervisor running, and if I were to lose my script and have to start from scratch again, I'd just install Debian instead. I would never recommend nixos to anyone. The concept is awesome, but the execution is terrible.
  - prox 4y ago
    What I often find is this “ought to know” treshold. Parent comment user is probably familiar with lingo you are not. Documentation often assumes a certain level and a writer does not imagine a less capable user.
    - pxc 4y ago
      Yes, the Nix community has great reference docs for people who already know how things work, for most things imo. At the same time, it isn't always obvious enough where to find a good introduction to terms and concepts used. But materials of that kind are increasingly available and general gaps are being filled with a lot of focus lately.
- laserlight 4y ago
  By documentation, I believe people mean tutorials. At least, lack of tutorials is my complaint. I've read all introductory material. I want to build a customized version of emacs on nix, yet I have no idea how to do it or where to start.
  - scoopertrooper 4y ago
    Why use a tutorial when ChatGPT has you covered? > How do I create a nix package that clones eMacs from GitHub and builds it from source? { pkgs ? import <nixpkgs> {}, fetchFromGitHub }: let emacsSrc = fetchFromGitHub { owner = "emacs-mirror"; repo = "emacs"; rev = "master"; sha256 = "0xabcd1234"; }; in pkgs.stdenv.mkDerivation { name = "emacs"; version = "27.1"; src = emacsSrc; buildInputs = [ pkgs.autoconf pkgs.make ]; configurePhase = '' autoconf ./configure --prefix=$out ''; buildPhase = "make"; installPhase = "make install"; }
    - delroth 4y ago
      As usual for ChatGPT this is full of mistakes and bad code. The buildPhase and installPhase it writes are completely unnecessary and worse than the default, the configurePhase might work in some cases but most likely won't, and it's unnecessary when instead autoreconfHook should be used, stdenv/autoconf should be taken as an argument for the function returning the derivation, autoconf should be a nativeBuildInput, make is already in stdenv, etc.
      - toastal 4y ago
        You're also supposed to call the pre and post hooks for these phases.
      - Rexogamer 4y ago
        More fundamentally, even if the code produced by ChatGPT worked and was high-quality, why should a new user have to rely on a chatbot instead of useful/up-to-date tutorials and guides?
    - 4y ago
- masklinn 4y ago
  > It's a language, and thus the language has may expressions that result in the same outcome. First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them. I just went to the nix website, clicked "first steps with nix" and I get https://nixos.org/guides/ad-hoc-developer-environments.html https://nixos.org/guides/ad-hoc-developer-environments.html Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Then there's listing of what's essentially a magical invocation out of nowhere: $ nix-shell -p 'python38.withPackages (packages: [ packages.django ])' I can understand that (or at least reach what I assume is an understanding), but there's no real explanation to give me knowledge to expand upon, if anything the explanations are worse than useless: > We create an ad hoc environment with $PYTHONPATH set and python available, along with the django package. thank you very much, that confirms I'd about interpreted the line correctly, but you've not told me what `withPackages` is or where `packages.django` comes out of so I'm not really helped. And apparently the next step is "declarative and reproducible developer environments", or possibly "towards reproducibility: pinning Nixpkgs"? Or even better, "To quickly setup a Nix project read through Getting started Nix template", I have no clue what a nix project is or why I'd want one. There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".
  - deleted 4y ago
    [deleted]
  - soraminazuki 4y ago
    > Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Why would you go to https://nixos.org/learn.html https://nixos.org/learn.html, click on an introductory example titled "Ad-hoc developer environments" and complain that it doesn't explain how to permanently install software? > but there's no real explanation to give me knowledge to expand upon Again, you're pointing to a page containing TLDR examples. That's not the right place for an in-depth explanation. > There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse". No surprise because you missed the entire manual.
- soraminazuki 4y ago
  Nix actually has far better than average documentation compared to other typical open source projects. I started using Nix years ago on Ubuntu to quickly install a package that wasn't present in Ubuntu's repository. Eventually, I began customizing packages using Nix expressions. Before I knew it, I migrated my existing systems over to NixOS. What I can say is it wasn't at all the uphill struggle that's associated with Nix in online discussions. Even though the documentation isn't perfect and going through active improvements, there's a considerable gap between Nix's reputation regarding documentation and my own actual experience. What surprises me is that people tout RPM/Chef as easier replacements to Nix/NixOS. The assumption about those being "replacements" of each other is questionable because they address different needs. What's even more questionable is the part about RPM or Chef being easy. I have dealt with those two for years as part of my day job, and they're both far from easy. I still have troubles with them to this day. Documentation is far more lacking than Nix, and it's not because things are obvious. If you encounter any trouble, you almost always have to dive into the source code. Navigating the source code of RPM or Chef is a nightmare because the code is scattered across countless different repositories and it's impossible to guess where to look for to begin with. Choice of programming languages doen't help here too. Chef is written in Ruby, which has a tendency of making code ungreppable due to its metaprogramming features. RPM has its own macro syntax which works similar to the C preprocessor. It's very terse and full of gotchas. Navigating around Nix code is much, much easier in comparison. Everything you need is in a single repo, https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs, and written in a JSON-like language. Many people also claim that Nix is hard because it requires a functional programming background. That too doesn't match my experience. Nix expressions are basically JSON with functions. Learning the syntax is a non-issue if you know JSON and some common programming language constructs like conditionals, functions, map, filter and reduce. The only functional programming exposure I had prior to Nix was LISP, in a university classroom. Yet I didn't experience problems learning the syntax. The hard part is learning how to actually utilize the language. The documentation and some grepping around of the Nixpkgs codebase helped a lot with this.
- tsuujin 4y ago
  My complaint is chiefly about practical implementation. “I want to use nix as a package manager across systems” is far too difficult for a new user. One document tells you to flakes, another tells you that it’s experimental and should be avoided. One document tells you that you should use Darwin modules and home manager, and then completely omits the fact that the linked home manager scripts don’t work with Darwin by design leading to “why the fuck isn’t this file they tell me should be auto generated not being created”. Because the official docs don’t seem to cover real world use cases, you end up relying on a labyrinth of out of date and conflicting user contributed tutorials and it is very frustrating. Once you know what to do nix is simple enough, but learning what to do is outright painful; if you don’t believe me look to the other replies to my comment.
Reventlov 4y ago
I agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort. At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican), without going full Guix. What I'm most impressed with Guix is the time machine and Software Heritage integration, but it still needs a lot of improvement for developers, for example allowing to specify environment variables in manifest.scm files.
- tsuujin 4y ago
  Nonguix is new to me. I may give it a look at some point but I’m already over the pain threshold on nix. Any idea if nonguix will allow an install on macOS? I really want a system like this that I can use on my work MacBook and remote Linux servers.
- sierkov 4y ago
  > for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
  - Reventlov 4y ago
    Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.
    - sierkov 4y ago
      Exactly my point. You can already do it with direnv, have guix shell once you cd into dir and then just do `jekyll build`.
bollos 4y ago
This sadly also sums up my short-lived stay with NixOS. Tried on multiple occasions to get a working system to no avail and ultimately made me go back to Fedora where I remain until this day.
prox 4y ago
It’s typical of certain areas in tech (like here) to not document, to not care about up to date information, and only as a last resort. You need people who can manage that and create a culture of documenting.
abathur 4y ago
I have been starting to suspect that a big part of the gap may be a sort of field guide to real-world patterns with context on what's new/old, where they are used/useful, and so on.
cwp 4y ago
There's an element of truth to the "poor documentation" complaint, because there are tutorials etc out there that are out of date, incomplete etc. But the official nix project has excellent documentation. I think the problem is that nix is just hard to learn. It's really different from most package managers, but people expect to look at a few examples and just pick it up intuitively. It's a whole different paradigm, with a custom programming language that also has a different paradigm. (Though Haskell folks eat it right up... no surprise there.) It's gonna take time and effort to learn it, and there's just no way around it.
- masklinn 4y ago
  > But the official nix project has excellent documentation. If it does, it's really well hidden. Because the nix manual certainly is not that. > I think the problem is that nix is just hard to learn. No, the problem is that nix offers no guidance or real help along that path. You go to https://nixos.org/learn.html https://nixos.org/learn.html and you've got essentially nothing helpful beyond the installation (which is easy enough). And it gets really bad when you get there from https://nixos.org/explore.html https://nixos.org/explore.html with no prior knowledge. > Though Haskell folks eat it right up... no surprise there. They're used to having to power through absent documentation?
rekado 4y ago
> It’s too bad guix went full hardcore FOSS and refuses to support macs, This is either a misunderstanding or misrepresentation of the issue. We don't refuse to support Macs. Consider this: - the value of Guix is in building up a package graph all the way from the very bottom (a tiny binary seed without parallel in other distros); this uses glibc. - glibc doesn't support Darwin - the only way to build software on a mac is to sign an EULA and use proprietary software (Xcode and the SDK). It's easier to build software for Windows than for a Mac. If it was about "full hardcore FOSS" (what a weirdly judgmental term!) then we wouldn't support building for WSL or cross-compilation to mingw64, but we do. Personally, I have no interest in working my ass off to get a subpar implementation of the package graph grafted on top of a huge binary blob (Xcode and the SDK) just to elevate a highly restrictive proprietary platform. Until Apple commissions this kind of work it is still preferable to just use Guix in a virtualized GNU system.
- tsuujin 4y ago
  > … just to elevate a highly restrictive proprietary platform. This is the attitude I’m referring to when I say “hardcore FOSS”. You can choose to see it as a judgement if you want, but I view it as an implementation detail precluding my use of Guix. “It’s hard and it’s not worth my time” is totally fine, I don’t expect projects to cater to my needs; but it’s worth calling out that it really seems like your chief complaint is that Apple is not FOSS (aka: proprietary).
  - rekado 4y ago
    I can't build any software for macos without signing a contract and buying their hardware. The fact that it is proprietary is the obstacle here.

40yearoldman 4y ago

I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so. Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware. If anything the Nix documentation is just as good as every other thing out there. What is different is there are more than one way to do many things in Nix. This to me I think is the core of complaints. Its a language, and thus the language has may expressions that result in the same outcome. The second bit I think people struggle with is it is functional. If you look at Nix complaints they appear to nearly be identical to that of Haskell.

CapsAdmin 4y ago
I also didn't notice that the documentation was especially bad. I'm thinking maybe it makes more sense for some programmers?
kstenerud 4y ago
Then you are a superhuman. I too went through weeks of pain and suffering to get my nixos hypervisor running, and if I were to lose my script and have to start from scratch again, I'd just install Debian instead. I would never recommend nixos to anyone. The concept is awesome, but the execution is terrible.
- prox 4y ago
  What I often find is this “ought to know” treshold. Parent comment user is probably familiar with lingo you are not. Documentation often assumes a certain level and a writer does not imagine a less capable user.
  - pxc 4y ago
    Yes, the Nix community has great reference docs for people who already know how things work, for most things imo. At the same time, it isn't always obvious enough where to find a good introduction to terms and concepts used. But materials of that kind are increasingly available and general gaps are being filled with a lot of focus lately.
laserlight 4y ago
By documentation, I believe people mean tutorials. At least, lack of tutorials is my complaint. I've read all introductory material. I want to build a customized version of emacs on nix, yet I have no idea how to do it or where to start.
- scoopertrooper 4y ago
  Why use a tutorial when ChatGPT has you covered? > How do I create a nix package that clones eMacs from GitHub and builds it from source? { pkgs ? import <nixpkgs> {}, fetchFromGitHub }: let emacsSrc = fetchFromGitHub { owner = "emacs-mirror"; repo = "emacs"; rev = "master"; sha256 = "0xabcd1234"; }; in pkgs.stdenv.mkDerivation { name = "emacs"; version = "27.1"; src = emacsSrc; buildInputs = [ pkgs.autoconf pkgs.make ]; configurePhase = '' autoconf ./configure --prefix=$out ''; buildPhase = "make"; installPhase = "make install"; }
  - delroth 4y ago
    As usual for ChatGPT this is full of mistakes and bad code. The buildPhase and installPhase it writes are completely unnecessary and worse than the default, the configurePhase might work in some cases but most likely won't, and it's unnecessary when instead autoreconfHook should be used, stdenv/autoconf should be taken as an argument for the function returning the derivation, autoconf should be a nativeBuildInput, make is already in stdenv, etc.
    - toastal 4y ago
      You're also supposed to call the pre and post hooks for these phases.
    - Rexogamer 4y ago
      More fundamentally, even if the code produced by ChatGPT worked and was high-quality, why should a new user have to rely on a chatbot instead of useful/up-to-date tutorials and guides?
  - 4y ago
masklinn 4y ago
> It's a language, and thus the language has may expressions that result in the same outcome. First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them. I just went to the nix website, clicked "first steps with nix" and I get https://nixos.org/guides/ad-hoc-developer-environments.html https://nixos.org/guides/ad-hoc-developer-environments.html Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Then there's listing of what's essentially a magical invocation out of nowhere: $ nix-shell -p 'python38.withPackages (packages: [ packages.django ])' I can understand that (or at least reach what I assume is an understanding), but there's no real explanation to give me knowledge to expand upon, if anything the explanations are worse than useless: > We create an ad hoc environment with $PYTHONPATH set and python available, along with the django package. thank you very much, that confirms I'd about interpreted the line correctly, but you've not told me what `withPackages` is or where `packages.django` comes out of so I'm not really helped. And apparently the next step is "declarative and reproducible developer environments", or possibly "towards reproducibility: pinning Nixpkgs"? Or even better, "To quickly setup a Nix project read through Getting started Nix template", I have no clue what a nix project is or why I'd want one. There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".
- deleted 4y ago
  [deleted]
- soraminazuki 4y ago
  > Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Why would you go to https://nixos.org/learn.html https://nixos.org/learn.html, click on an introductory example titled "Ad-hoc developer environments" and complain that it doesn't explain how to permanently install software? > but there's no real explanation to give me knowledge to expand upon Again, you're pointing to a page containing TLDR examples. That's not the right place for an in-depth explanation. > There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse". No surprise because you missed the entire manual.
soraminazuki 4y ago
Nix actually has far better than average documentation compared to other typical open source projects. I started using Nix years ago on Ubuntu to quickly install a package that wasn't present in Ubuntu's repository. Eventually, I began customizing packages using Nix expressions. Before I knew it, I migrated my existing systems over to NixOS. What I can say is it wasn't at all the uphill struggle that's associated with Nix in online discussions. Even though the documentation isn't perfect and going through active improvements, there's a considerable gap between Nix's reputation regarding documentation and my own actual experience. What surprises me is that people tout RPM/Chef as easier replacements to Nix/NixOS. The assumption about those being "replacements" of each other is questionable because they address different needs. What's even more questionable is the part about RPM or Chef being easy. I have dealt with those two for years as part of my day job, and they're both far from easy. I still have troubles with them to this day. Documentation is far more lacking than Nix, and it's not because things are obvious. If you encounter any trouble, you almost always have to dive into the source code. Navigating the source code of RPM or Chef is a nightmare because the code is scattered across countless different repositories and it's impossible to guess where to look for to begin with. Choice of programming languages doen't help here too. Chef is written in Ruby, which has a tendency of making code ungreppable due to its metaprogramming features. RPM has its own macro syntax which works similar to the C preprocessor. It's very terse and full of gotchas. Navigating around Nix code is much, much easier in comparison. Everything you need is in a single repo, https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs, and written in a JSON-like language. Many people also claim that Nix is hard because it requires a functional programming background. That too doesn't match my experience. Nix expressions are basically JSON with functions. Learning the syntax is a non-issue if you know JSON and some common programming language constructs like conditionals, functions, map, filter and reduce. The only functional programming exposure I had prior to Nix was LISP, in a university classroom. Yet I didn't experience problems learning the syntax. The hard part is learning how to actually utilize the language. The documentation and some grepping around of the Nixpkgs codebase helped a lot with this.
tsuujin 4y ago
My complaint is chiefly about practical implementation. “I want to use nix as a package manager across systems” is far too difficult for a new user. One document tells you to flakes, another tells you that it’s experimental and should be avoided. One document tells you that you should use Darwin modules and home manager, and then completely omits the fact that the linked home manager scripts don’t work with Darwin by design leading to “why the fuck isn’t this file they tell me should be auto generated not being created”. Because the official docs don’t seem to cover real world use cases, you end up relying on a labyrinth of out of date and conflicting user contributed tutorials and it is very frustrating. Once you know what to do nix is simple enough, but learning what to do is outright painful; if you don’t believe me look to the other replies to my comment.

Reventlov 4y ago

I agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort. At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican), without going full Guix. What I'm most impressed with Guix is the time machine and Software Heritage integration, but it still needs a lot of improvement for developers, for example allowing to specify environment variables in manifest.scm files.

tsuujin 4y ago
Nonguix is new to me. I may give it a look at some point but I’m already over the pain threshold on nix. Any idea if nonguix will allow an install on macOS? I really want a system like this that I can use on my work MacBook and remote Linux servers.
sierkov 4y ago
> for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
- Reventlov 4y ago
  Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.
  - sierkov 4y ago
    Exactly my point. You can already do it with direnv, have guix shell once you cd into dir and then just do `jekyll build`.

bollos 4y ago

This sadly also sums up my short-lived stay with NixOS. Tried on multiple occasions to get a working system to no avail and ultimately made me go back to Fedora where I remain until this day.

prox 4y ago

It’s typical of certain areas in tech (like here) to not document, to not care about up to date information, and only as a last resort. You need people who can manage that and create a culture of documenting.

abathur 4y ago

I have been starting to suspect that a big part of the gap may be a sort of field guide to real-world patterns with context on what's new/old, where they are used/useful, and so on.

cwp 4y ago

There's an element of truth to the "poor documentation" complaint, because there are tutorials etc out there that are out of date, incomplete etc. But the official nix project has excellent documentation. I think the problem is that nix is just hard to learn. It's really different from most package managers, but people expect to look at a few examples and just pick it up intuitively. It's a whole different paradigm, with a custom programming language that also has a different paradigm. (Though Haskell folks eat it right up... no surprise there.) It's gonna take time and effort to learn it, and there's just no way around it.

masklinn 4y ago
> But the official nix project has excellent documentation. If it does, it's really well hidden. Because the nix manual certainly is not that. > I think the problem is that nix is just hard to learn. No, the problem is that nix offers no guidance or real help along that path. You go to https://nixos.org/learn.html https://nixos.org/learn.html and you've got essentially nothing helpful beyond the installation (which is easy enough). And it gets really bad when you get there from https://nixos.org/explore.html https://nixos.org/explore.html with no prior knowledge. > Though Haskell folks eat it right up... no surprise there. They're used to having to power through absent documentation?

rekado 4y ago

> It’s too bad guix went full hardcore FOSS and refuses to support macs, This is either a misunderstanding or misrepresentation of the issue. We don't refuse to support Macs. Consider this: - the value of Guix is in building up a package graph all the way from the very bottom (a tiny binary seed without parallel in other distros); this uses glibc. - glibc doesn't support Darwin - the only way to build software on a mac is to sign an EULA and use proprietary software (Xcode and the SDK). It's easier to build software for Windows than for a Mac. If it was about "full hardcore FOSS" (what a weirdly judgmental term!) then we wouldn't support building for WSL or cross-compilation to mingw64, but we do. Personally, I have no interest in working my ass off to get a subpar implementation of the package graph grafted on top of a huge binary blob (Xcode and the SDK) just to elevate a highly restrictive proprietary platform. Until Apple commissions this kind of work it is still preferable to just use Guix in a virtualized GNU system.

tsuujin 4y ago
> … just to elevate a highly restrictive proprietary platform. This is the attitude I’m referring to when I say “hardcore FOSS”. You can choose to see it as a judgement if you want, but I view it as an implementation detail precluding my use of Guix. “It’s hard and it’s not worth my time” is totally fine, I don’t expect projects to cater to my needs; but it’s worth calling out that it really seems like your chief complaint is that Apple is not FOSS (aka: proprietary).
- rekado 4y ago
  I can't build any software for macos without signing a contract and buying their hardware. The fact that it is proprietary is the obstacle here.