I firmly believe that Nix (and/or Guix) are the future. I am going to use Nix as the keyword below, but Guix and Nix are so very similar that everything is also true for Guix.
Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.
Every time I see a package being distributed as a Snap, I wonder why. These containered solutions are very complex, trying very hard to emulate FHS with mount namespaces, binding mounting tons of sockets around, and almost always end up mounting all of /home in the container. The don't provide much security, and quite difficult to deal with, and require a daemon.
Nix on the other hand has zero containerization requirements. It simply works by ensuring the programs are looking in the right place for the libraries they need. It would be great if more vendors just shipped a Nix derivation (or store path) that was their application stack. It would end version incompatibilities for ever, in a way that isn't a burden for the user.
Nix + bubblewrap add all the benefits of snap and flatpak as well. But again, there is no benefit to bubblewrap is if you are just going to blanket allow read-write everywhere anyway. At least with raw bubblewrap you can make these policies actually protect something.
Similarly, Nix is easily installed on any existing system. So you can use nix packages on Debian, Ubuntu, Centos, Fedora, DSL, or any other linux distribution because it runs entirely out of /nix. I use nix packages on Archlinux at home, and Debian systems as work.
Cross distro development works 100% of the time because Nix doesn't use anything from the distro.
Nix (and Guix) are really what the Linux community should be moving towards IMHO. I personally prefer Nix's syntax, but the underlying technologies are so similar I consider them the same. Guix started as a fork of Nix, and one day I hope they decide to end up becoming compatible with each other again.
This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Guix: the nix-daemon. Everything else but the daemon (and that's a lot) is a completely independent implementation of the same principles that were first demonstrated in Nix: functional package management.
Why reuse the daemon? Because it could be done. The daemon takes very low level build instructions ("derivations") and arranges for them to be executed in an isolated environment. In Guix derivations are generated through compilation of higher level concepts that as such have no correspondence in Nix.
The common ground is the format of the derivation, which has only been modified occasionally to better suit our differing needs.
My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward.
That currently isn't possible, but would be nice.
I imagine it could only work for packages, not for system configuration. But that still would be a huge win.
System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building.
This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features.
It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now.
So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.
System configuration is just another store item, but symlinked, copied, or referenced by other places outside the store as well. Such as systemd services.
You're likely right though that compatibility between the two projects will continue diverge. My true dream was that vendors wouldn't have to build for Snap, Flatpak, Guix, and Nix. They could just use either Guix or Nix and have something usable by either user base. In the end the outputs are just writing stuff to the store.
But the fact that the store paths are already different would make it a huge migration for that path to change in the future, and unlikely to ever happen. Still, I can dream.
Nix and Guix have too steep of a learning curve. Maybe someday I'll be willing to invest the time to understand what's going on, but the CLI and docs just aren't good enough to go from "I know nothing" to "ah, I can install the latest <firefox,inkscape,chromium,etc.>".
It really isn't clear to me how to switch a running system's package manager to either or even if either is fit to be the system's main package manager.
I watched a video of a seasoned linux user trying to install nix and abandoning the procedure because of the lack of docs. I even downloaded a virtualbox image of NixOS and tried to update everything to the latest version: 30 minutes later only firefox was installed but it wasn't in PATH thus couldn't be executed. Never found out how to install the KDE desktop.
Guix was another beast that I tried installing as a non-root user (insisted on using `curl | bash`, which I loathe). It was never up to date and I couldn't find the package I wanted to install (so fancy new chromium wrapper.. next-browser or something).
Maybe now things are better, but back then (1-2 years ago), neither were anywhere close to modern GUI distros.
Until they make it easy to use, it's going to stay niche.
Guix has never insisted on 'curl | bash'. At first there were no instructions on how to use the shell installer script (perhaps you translated to 'curl | bash'?), but now the manual explicitly recommends to wget and chmod it:
I found the documentation to be plentiful compared to other projects, though it's not as comprehensive as the Arch Wiki. The docs definitely mention how to install KDE [1] and firefox [2].
To learn more about Nix, I'd recommend grepping the nixpkgs [3] repository once you grasp the basics of the Nix language (Nix Pills [4] would be a good start for that). Since everything in the Nix official repository belongs in nixpkgs, it's easy to search for the information I want. I just wish CentOS and Debian had a way of searching across the entire codebase this easily when I couldn't figure out something from the docs.
I found reading code from Nixpkgs to be very valuable as well, and can't recommend it enough. I managed to get by using NixOS without writing my own derivations for several months until I inevitably ran into a need to package something new. Even then, Nix Pills isn't a super useful reference, it's sort of like learning Git by understanding blobs, too focused on details.
Another pain point is looking for documentation of Nix library functions, I've solved this by using Manix[0]
I find nix pills hard to digest since they use the repl, and for a newbie it's hard to see how they apply to real-world packing of something like a python application.
This video helped me a lot though, but unfortunately there are a few minutes of broken audio in the middle
https://youtu.be/2mG0zM_wtYs
I filed a PR in the nix pills repo like eight months ago that never got touched; they're effectively abandoned and contain hard errors. One more snare trap in the mine field that is nix documentation.
To anyone that wanders by this, if you value your time at all, don't bother with nix unless you have someone you can corner and directly get answers from.
> don't bother with nix unless you have someone you can corner and directly get answers from.
Just because your single PR slipped through the maintainers attention? Wow, you must have to avoid a lot of high profile open source projects.
Furthermore, the official page very clearly states how you could reach the community for help, although I highly recommend you to lower your tone before doing so:
I realize that you just cited two particular issues as examples for a deeper problem. But still: The command `nix-shell -p firefox` spawns a subshell in which Firefox is in the PATH. (In case Firefox has not been downloaded before, it will by this command.) Others shells are unaffected by this command, and in fact, it is possible to have different versions of Firefox available in other subshells. This feature might be especially useful to web developers interested in gauging compatibility of their sites with different versions of browsers.
To enable KDE, you put this into your configuration.nix:
I've been using NixOS since 2017 and don't ever want to look back. I agree that NixOS is not anywhere close to modern GUI distros, but do like the documentation, and the friendliness and speed of the community.
The problem with nix is that it defeats the purpose of shared libraries. Normally, when you upgrade a shared library, all consumers of it get fixed for free.
With nix every package is siloed into its own separate dependency graph and so you can have many versions of a shared library coexisting on the system but each version may be used only by one consumer. That means upgrading one will not affect all the others.
So then the only way to get consumers of a shared library to upgrade is to upgrade the consumers as well. Well then why not switch to static linking and be done with it? It would be much simpler that way.
This is not actually a problem in practice. I had this misconception too before I started using it, though. I'll explain for Nix, since I've used it, but I assume Guix works similarly:
Packages as defined in nixpkgs don't depend on specific versions of shared libraries. They depend on the library by name, just as they do in any other OS. So a single update in nixpkgs addresses all packages on the system "for free", including ones defined outside of nixpkgs, because they're almost certainly going to depend on nixpkgs for those libraries (I mean, they could duplicate the definitions, but why would they?).
Built packages depend on specific versions. So you just have to be sure to update all your built packages. How does that happen? Well, packages are installed because they're requested by name somewhere, either NixOS system packages, or from home-manager, or from a dev environment. Those names point to packages in nixpkgs. So when you update your nixpkgs version (using nix-channel or flake update or however you're doing it), and then rebuild NixOS or update home-manager, you get updated versions of everything.
If you're using a nix-based dev environment with pinned nixpkgs (with niv or a flake or whatever), you'll have to update that pin as well, for each project. I suppose you could claim that this makes it easy to use old dependencies. Perhaps, but the entire point of pinning the nixpkgs version is to make everything 100% reproducible, bugs and all, all the way down your dependency stack. So you have to make a deliberate choice between trade-offs there, which seems fair.
As far as static linking, nix is essentially static linking, except that you still get the benefits of shared disk space and shared memory for .so files. "True" static linking might be simpler if your dependencies happen to be .so files that also have .a files, but many things aren't, e.g. dependencies among python modules, depending on other binaries to exec, data files, etc. Nix lets you "statically link" all of those too.
IIUC, it’s more nuanced than that. The shared library would be specified as a dependency to the packages that rely on it. Pushing a fix to the library would trigger a rebuild of all the downstream packages during the next upgrade. This also means updates to a popular dependency will cause long upgrades.
The unholy basis of all modern Linux systems named glibc does not like being statically linked. It would break slightly and sometimes seriously if you do so.
From a security point of view, the Debian for example, seems to be much more reliable. It does not leave you at the mercy of libraries with security holes.
This CLI difference is in part due to the underlying design, which is not just about syntax (parens vs. braces) but more about abstractions and composition.
For example, the Nix language doesn't have the ability to define new data types, and it doesn't have a "package" or an "operating system" data type. That means that all the entries in Nixpkgs look alike, which in turn prevents building a "package-aware" or "OS-aware" user interface.
The Guix CLI "knows" about packages and versions, and package transformation options are an example of how the CLI can take advantage of that abstraction.
Likewise, the "guix system" command knows about services, which gives it convenient introspection capabilities such as "guix system extension-graph" and "guix system shepherd-graph".
I think it's somewhat unfair to use number of packages vs Nix as an argument against Guix.
Nixpkgs has the biggest package repository of all the distributions, and a much larger community.
If you compare Guix against Arch for example, Guix comes out more favorably (15k packages) vs Arch's 12k.
Guix packages tend to be very well integrated too, usually running upstream test suites, leading to fewer run-time problems. I think only Debian and Fedora matches Guix on this practice.
I don't understand some details about Nix when people talk about it. Forgive me for being ignorant.
* Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language).
* How is disk space usage? Is there any kind of deduplication?
* How are security updates to shared libraries handled?
* Transactional upgrades look great. But how is the user experience around Transactional upgrades of running GUI applications?
* Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..
Nix also defaults new build commands to the equivalent of `./configure && make && make install` so it works out of the box with a lot of packages, as long as you declare the build inputs that it may need.
As for disk size, beyond garbage collection, you can also ask Nix to sweep its store and hardlink identical files together in order to save space if you suspect significant file duplication (and if your FS doesn't already deduplicate blocks).
Note: these points concern Nix, the situation may be different on Guix
> * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language).
Yes. To make Nix really work it has to be pervasive and this sometimes means porting packages again, however there's a lot of automation around this, see[0] for ones that leverage existing build systems in other languages. Autoconf and cmake packages are already accounted for by the default builder, and usually only the dependencies have to be specified.
> * How is disk space usage? Is there any kind of deduplication?
The Nix store can be intensive on memory, as once a dependency such as glibc is updated, all the reverse dependencies (i.e. the set X such that X depends on glibc directly or transitively) have to be rebuilt as well. There is an option to optimise the store, but I don't know how much it helps in practice, see[1]. Garbage collection can be invoked manually or automatically to free up unused store entries.
> * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..
By startup time you might be referring to NixOS. It's very good on my Late 2013 13-inch MacBook Pro, around 20 seconds to go from cold boot to login screen.
I was referring to application startup which is an issue for snap & flatpak. I'd like to know how it (Nix + sandboxing solution like bubblewrap) compares to flatpak.
Nix doesn’t sandbox applications, it is basically only patches the ELF header so that it links to nix store entries instead of /usr/lib when it comes to shared libs.
So While I don’t have benchmarks, it is basically in the same ballpark as Arch programs.
> Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with.
Uh... what? You're comparing these things against Guix and Nix, which require you to learn a new language to use. Not to mention that AppImage, at least, is only complex because it kinda has to be in order to be portable, single-file, directly-executable application. Which is to say, it is only complex in its implementation so that it can be much less painful to interact with [0].
> Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.
Which AppImage can do without you having to learn a new language, and as a bonus will even let you store those applications on entirely different media without recompilation or anything.
> Similarly, Nix is easily installed on any existing system.
AppImages work on most Linux systems, which is about as well as anyone can do with something that requires no pre-installed runtime.
I think the package managers themselves, with unprivileged operation, immutable profiles, atomic upgrades and rollbacks, "guix pack", etc are the main value propositions.
It is only required because /nix is hardcoded (but only to make using binary caches possible). Later on, writing to this store is done by a nix user, and install can be issued by a normal user.
Maybe I'm misunderstanding, but isn't part of the point that the packages themselves are declarative and you're not beholden to some maintainer to get stuff? Wouldn't that mean writing your own... whatever it is your write to get software installed?
To install stuff with Guix you simply type "guix install foo".
From an end-user perspective, the main difference from other package managers is that you don't need root privileges (and that each user have their own "collections" of packages).
Both. You get to use packages others have written the same way as you do on arch. And you can also decleratively specify your build environkent, or override some attributes like apply a custom patch in a package someone else wrote. But you are just as not required to learn nix, as you don’t need to know how to write a .deb package to use ubuntu
I don't know what you think is needed for nix/guix that has not existed the past 20 years.
All the other technologies I mentioned require fairly recent kernels to work, namely for all the namespace shenanigans they employ. Nix can run on perfectly fine on at least Linux 3.2 (stock wheezy), so far as I tested.
I never implied nix needed anything quite the opposite, it was somehow from-scratch thinking, on the other systems were more inspired by new linux features to solve a slightly similar issue.
Nix feels pretty close to "right thing to do", but if the other solutions are more successful, it's a case of "worse is better".
I think the important part is usability compared to what's already there. It's much easier to write a Dockerfile than to write something with Nix. You can get much stronger benefits from Nix than from a Dockerfile.. but, most of which you don't really need all the time.
My impression is the other solutions are quick-ish hacks to solve problems that come from (and building upon) the complexities of systems built using quick-ish hacks. Nix feels like a more elegant solution, but it's also different enough that it's got a steep learning curve for anything harder than "install foo".
For the use case of "I need a Docker image with some programs", this command seems pretty neat. Nixery is a similar with Nix, where an image can be constructed ad-hoc by specifying the dependencies of an image's path.
That's cool. And I can imagine cases where it's useful.
Stuff like Nixery isn't itself enough to claim "nix is better than Docker", though. -- The questions I'd want to think about are "what happens when I run into a problem? how hard is it to fix this?". I feel like Nix does solve some problems that I've had with Dockerfiles. But there are also problems I've run into with Nix that I wouldn't've had with Nix.
I like nix well enough. But I've also used it enough that I'm not surprised if people have difficulties with it, and are more comfortable with other solutions.
One thing that flatpak has over nix is the set of common bases. If I was going to distribute something shifted from nix, I'd essentially need to move every single dependency (which needs to be compiled/configured right). It's not a huge problem for a cli tool in golang, but something that requires qt, GL, input method support, etc.? I'm glad there's a flatpak base for those that not only "just works", and it's going to be maintained/distributed even of the app isn't.
I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems).
You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.
Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)
Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it?
Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".
And it depends on your use case - whether you want to guarantee exactly the same behaviour and ship all the dependency updates yourself; or do you want to have less maintenance burden and trust the base layer to not change behaviour.
In a tightly controlled environment inside a company where the update mechanisms are preconfigured / enforced, I'd go with nix model. When distributing an app to people on the internet, I'd choose flatpak model.
But you simply don’t have to worry about it. You test it on the next LTS release of nixpkgs and that’s it. Your user may download a bit more data, but I found that nix is lightyears faster then fedora’s build tool, and on par with arch, while not polluting the whole filesystem with random files. I don’t see where would you need more maintainance.
Nixpkgs already packages all of the things you've mentioned (qt, GL, input method support). So to package your own software with Nix, all you have to do is specify them as dependencies. There's no need to "move every single dependency" at all.
Guix makes me feel good. Even in case there is package version conflict because I tried various version, I can stay calm and feel safe. Just run `guix upgrade` on the affected packages solves the problem well. An a rollback is also not far away if everything fails. Any package conflict on my old grown Debian system has made me sweat with fear after years of piled up apt packages intermixed with /usr/local installations.
Not completely related but I decided on my latest GNU/Linux distro install that I much prefer the macOS model with slow updates for the major stuff with optional use of Homebrew and other updating mechanisms for the add-ons. One of the things that I got tired of was having to run updates on Fedora, Ubuntu, etc. So I decided to install Debian Stable with the Nix package manager as a sort of Homebrew replacement. This way I don't have to worry about my distro breaking, while I can get new stuff that is atomic and easy to remove when I want. I am curious if any Guix users do something similar.
I've been using it on all my personal devices for ~6 months and also for some bare metal sever deployments.
A (mostly) immutable system configured with a single config file is an absolute killer feature.
The ability to roll back to a previous config in the bootloader or the terminal is brilliant.
And home-manager [1] provides the same experience for your user environment.
I also looked into Guix, but the community and package repository seem much smaller.
They also don't accept proprietary software in the official package repo. Which is a respectable ideological choice, but really reduces usability a lot compared to nixpkgs.
I’m on NixOS and had the same feeling when first debated which to use.
If I was running some security sensitive app or scientific computing I would probably choose guix and they tend to be pretty rigid about reproducible building from source and signing changes to to the OS. But my day to day OS I use NixOS as I get tons of packages and basically all the same features with the trade-off of expecting some weird behavior on edge-cases and reproducibility (which I have yet to run into but know I will eventually)
> I tried to install NIX, but the graphical installer wouldn't boot.
I've had the same issue. Nix uses KDE Plasma by default, which uses a compositor that struggles with some video drivers.
Fortunately, installing from command line is practically the same, especially if you do your partitioning beforehand.
> Then when I tried the text-based install, it couldn't see my NVME disk.
That's a more unique problem. I'm not sure what to do about it either. Did /dev/nvme0n1 just never populate? My best guess is that you booted emulated BIOS instead of UEFI.
I gave NixOS a serious try... the reason I gave it up was that pretty much all build systems for my own projects were broken and it was a pain to "nixify" them.
I definitely do. It takes some reading the docs and perhaps asking people how to do it, but you can have some environment defining files a folder of any project and use GNU Guix to enter a reproducible environment. I cannot yet do that for all the things, where I would like to do it, because I often miss a package or get an error when trying to import it from other package repositories like PyPI and am not able to solve these without help from the mailing list. People on the mailing list are very helpful though.
Sometimes a good way to do something on the command line is missing, but the stuff that is there has a great CLI interface, in my opinion. One of my favorites is the time machine.
I have several machines running NixOS and one running Guix.
In Nix you have several channels that push package updates. The stable one moves very slowly, and because Hydra tests packages, it's really rare to experience broken things.
You can also mix them and e.g. install some packages from unstable, and keep others from stable.
Additionally Nix and Guix provide easy total and partial rollbacks, so you should not be afraid of breaking anything.
They are both quite different as its an internal DSL vs an external one. Just give them a try.
A major difference at the minute might be package availability. Nix has more packages but some are broken, e.g. Julia. Guix has very clean and reproducible packages, and a slightly better CLI interface.
While reading this discussion, I was thinking exactly the same thing. Normally I use /testing/ distribution of Debian GNU/Linux. But with Guix, I can just install bare-minimum Debian /stable/ and work with Guix for the rest.
This way we'll also get security updates. Debian is committed to providing security updates for the /stable/ distribution. Not sure about /testing/ and /sid/.
When a Guix system upgrade breaks something important, you can simply boot up the previous "generation" of the system and get back to work until the blocker bug you encountered has been fixed, at which point you can attempt the upgrade again.
I actually ended up using testing rather than stable for ... reasons but I think if I did it again, I’d stick with stable. Of course, I always think that.
I know the "cool thing" these days is homebrew, but there's also MacPorts [1] which I would say it and aligns better with the "use a stable base + compile the latest things" approach.
MacPorts does not use the base system to compile the latest things on top. Instead, it creates a "parallel system" where everything is installed from MacPorts (and hence you all dependencies are continuously updated) for the "latest stuff" you install through MacPorts, while not touching the system stuff at all.
I haven't tried it so I don't have an informed opinion.
All I can say in is that MacPorts has served me well for over 10 years at this point, with remarkably few issues (even after updating to newer MacOS releases).
A couple years ago I wanted to install restic, which had homebrew instructions but not a MacPorts package. I don't remember the details, but the installation through Homebrew failed. In the end, I got rid of Homebrew entirely and created a MacPorts package, which took me around 2 hours with no previous knowledge on MacPorts packaging. It was accepted upstream too :)
Since then it just hasn't seemed necessary to try out other package managers. MacPorts fills that need for me and I prefer to spend my time elsewhere.
I like Gentoo for this reason. I can leave core elements and stuff I don't care about on "stable" while selectively choosing "unstable" for things I use every day. Unstable is pretty stable for the most part. The nice thing is the stable core is still rolling so no major updates.
I used Gentoo exclusively for 5+ years (around 2002-2007) and after the umpteenth update which broke printing, I switched to Debian stable, and will probably use it for the rest of my life. Being able to get stuff done without having to worry about random stuff breaking was a very positive life change. Back then most Gentoo ebuild authors updated versions of all dependencies of a package, as well as the package itself, which
Things are so much better now. I used to use Arch Linux around that time while I was at university. During my coursework I was procrastinating and decided to upgrade my entire system. It broke. With only hours left until the deadline I chucked in one of those free Ubuntu CDs I have lying around and was back up and running within an hour.
I stayed on Ubuntu for years after that. But now I've gone back to Gentoo and it's very impressive. Everything just works. I'm sure it's partly due to my extra experience but I really don't have a problem with stuff breaking. Things are so much better now.
Gentoo was too hard for me to install (command-line partitioning is just too risky) so I ended up using Redcore, which has a nice GUI installer, and is Gentoo-based.
You can always boot any Linux rescue system (Knoppix) and use gparted to figure out the partitioning, then continue their cli install. I do agree that partitioning by commandline is scary biz. A good TUI (think weechat, htop, tmux quality) would do great for this purpose.
That is, if the machine is a pet and not cattle.
Repartitioning from another distro (Elementary in my case, due to WiFi and trackpad support) is what I did for most of the installs. I still wasn't fully sure how to run the CLI commands for a particular partition, rather than a full disk. In the end, Redcore just gave a better installation process for the same backend kernel.
Speaking of Knoppix, though, it worked great for USB boot, but I couldn't for the life of me manage to get Knoppix booting from an internal partition. Flashing the ISO makes 3 partitions from USB, and if I copy those to internal partitions with cp -Lr, and set the boot flags, they're still not detected. Eventually I just used Kanotix.
So partitioning a device is less risky with a GUI? That doesn't make sense.
EDIT: I should be more constructive:
I know that the command line scares some people, but that's just like computers in general scare most people, it's just something you have to get over with.
Another "scary" thing is the choice that exists between multiple available partitioning tools, I know it took me some time before I decided that the good old fdisk was my choice, but really, it probably doesn't matter, any should be OK. You probably won't actually do it directly from the command line anyway, e.g. fdisk is dialog driven instead.
Lastly, I doubt that it isn't possible to fire up Xorg from the Gentoo install media and then partition from a GUI tool, if that's what you want.
I personally find it easier to see the gui layout of my disk before I press play. Gparted can queue and execute a lot of changes to get to your desired state. Very intuitive for people like myself who doesn't deal with partition layouts and filesystems on a daily basis.
Don't get me wrong, seeing the layout is great if you don't mind the requirement for a GUI, but the fdisk UI is actually pretty good, too. It also queues and executes a lot of changes to get to your desired state, and it can show all the sizes and offsets that define the partition layout. It's not actually a command line tool, but dialog-driven (you give it commands on-line, get built-in help, etc.).
Using a command-line partitioning utility like parted or fdisk is more risky to interface with, at least for the layman.
Am I using GPT tables? How many blocks for this partition again? What partition type am I marking this? Am I using a capital G to denote gigabyte? A plus sign before or after the number? What is the current state? What is the planned state?
These aren't particularly difficult questions, but they are more easily answered when using a GUI tool like GParted than they are when using fdisk or parted.
GParted is an excellent GUI. I personally haven't seen a more reliable and usable partition utility. It's my first and last recommendation, no matter what the user's background, and it will likely continue to be for a very long time.
I did try to run startx from the Gentoo installer, but it isn't available.
Command-line partitioning isn't the problem, per se, it's the lack of manual config options. Zenwalk (Slackware) has a command-line installer, and that detected my existing partitions correctly and let me install.
As a user of both Nix and Guix, Guix really needs to do a thousand papercuts campaign because there's so much low-hanging fruit here.
The Nix shell script installer is a one-time that you can rerun without it reinstalling Nix (it will just skip if it detects an already existent Nix). Guix reinstalls (and take forever doing it). The Nix installer is much faster. You also need to make sure you import keys when installing Guix because security.
Doing any package related thing will tell you about a failure to install locale. This is straight out of the box Guix if you've installed it on, say, Ubuntu. This is not a good out of the box experience. It blows. If you Google this error you are told to install glibc-utf 8-locales but on my Ubuntu base system this doesn't actually solve the error.
If you the user can clamber over these two landmines well it's an awesome Emacs package repository. This is actually where Guix wins over its cousin and as an ardent Emacs user its fantastic to have all the most esoteric packages and weird builds of Emacs like emacs-pgtk-native-comp I source from a Guix user channel and install declaratively from a manifest.scm file.
Guix should lean into this one major strength and put out an Emacs-centered heavily opinionated installer image that uses EXWM for its window manager.
> Guix should lean into this one major strength and put out an Emacs-centered heavily opinionated installer image that uses EXWM for its window manager.
Wat?
While I live in Emacs I find it a terrible disservice to Guix to focus on this tiny niche. I'm probably biased, but one of the major strengths of Guix is its wealth of R packages that are all built reproducibly.
Ask different people about what they think is Guix's major strength and you'll get different answers, because Guix is pretty great in a lot of areas.
The installer script has seen some recent improvements and the interactive system installer as well. The annoying locales thing has also seen an unusual solution recently, so we're approaching a state where the initial impression lives up to the amazing day to day performance of Guix for package, environment, and system management.
> The Nix shell script installer is a one-time that you can rerun without it reinstalling Nix (it will just skip if it detects an already existent Nix). Guix reinstalls (and take forever doing it).
Wait, what? The Guix installer script also stops if it detects an existing installation, and has done so since the initial commit:
> You also need to make sure you import keys when installing Guix because security.
If you are complaining that the installer verifies the GPG signature of a file it downloaded from the internet, I don't know what to say. :-)
> Doing any package related thing will tell you about a failure to install locale.
This can happen when your installed locales are from a different glibc than what the guix-daemon was built with. Upgrading and restarting the daemon will solve it.
That said, I think the daemon recently got smarter about it.
> Guix should lean into this one major strength and put out an Emacs-centered heavily opinionated installer image that uses EXWM for its window manager.
The system installer disk image does give you an option to create an EXWM system (as well as GNOME, Xfce, etc).
> Wait, what? The Guix installer script also stops if it detects an existing installation, and has done so since the initial commit:
You're right about this, apologies. What I intended to convey was that Guix hard bails on an install so can't be scripted as part of a "dotfiles up" on a new system. Nix gracefully bails and can therefore be scripted.
> This can happen when your installed locales are from a different glibc than what the guix-daemon was built with. Upgrading and restarting the daemon will solve it.
This is from 5 minutes ago. I have both glibc-locales and glibc-utf8-locales installed:
> If you are complaining that the installer verifies the GPG signature of a file it downloaded from the internet, I don't know what to say. :-)
Speaking strictly from the perspective of a desktop end-user, this should probably be rolled into the one-liner.
And, as I'm testing, I also notice that even for operations which require no changes, a guix pull takes 5 or more minutes over the equivalent nix operation. Why am I building guix-system for 5 minutes with nothing to be done?
I urge you to take all of this as friendly advice from someone who fits into the market category of Guix's next million users. How you capture them is by removing the barriers to entry, streamlining the package management process, and massaging over papercuts that a brand-new user won't have the patience for.
> The system installer disk image does give you an option to create an EXWM system (as well as GNOME, Xfce, etc).
Right. The problem here is that you haven't updated the guix-daemon since you installed Guix. To get the fix rekado mentioned, you need to 'guix pull && guix upgrade' as root and restart the daemon.
(I can tell because you're using bash 5.0.7 from 1+ year ago)
You can also change the systemd service to use guix-daemon from your users Guix instead of 'root'. Arguably the installer could ask whether to do this, although users probably won't understand the security implications.
> And, as I'm testing, I also notice that even for operations which require no changes, a guix pull takes 5 or more minutes over the equivalent nix operation. Why am I building guix-system for 5 minutes with nothing to be done?
That happens when there are no substitutes available for 'guix pull'. Work is ongoing in improving the compiler performance, but this is mostly "bad luck" (because you pulled a commit not yet built by the CI).
Wrt scriptability of the installer, IIUC the problem is that it returns "1" when a previous installation was detected? You can easily account for that in your "dotfiles up" script, no? Similarly, if you add the GPG key to your dotfiles you no longer have to download it every time.
I love Guix in theory, but I have a lot of issues with performance. Literally orders of magnitude slower other package managers. Downloading is slow, even if the total download size is small. Recently, it took two hours to upgrade Julia because, I guess, it wasn't available on the substitute server.
When you think of Guix as a source distribution first and a binary distribution second this makes sense. The build farm is just another user that builds everything from source. If it didn't catch up with the builds because someone just changed a package definition then you might be requesting a binary that hasn't yet been built.
Slow download appears to depend a lot on location to an extent that we suspect peering problems. The main build farm's head node is connected to the internet from a well-connected research campus with dual 10G. Multiple tests have concluded that the configuration from server-side software, to network hardware of the server, down to networking in the data centre is sane.
Maybe we'll have to bite the bullet and (again) use a CDN to better serve users that inexplicably experience slow connections.
There was early work on using IPFS as a substitute distribution mechanism, but the API changed and nobody has picked up the existing work yet. But I agree that this would be a great feature and I hope someone will feel motivated to pick up and assemble the pieces.
The implementation requires that you have at least one authorized substitute server advertising the same hash.
In simplified terms, if ci.guix.gnu.org advertises a substitute for /gnu/store/abc123-foo, with the checksum "xyz789" (and the cryptographic signature of that advertisement checks out), your daemon can safely download that file over P2P.
Ah, I think I'm misunderstanding the intent here. Clearly P2P distribution of checksummed binaries can be safe, I was just wondering if there were a solution to the build farm being behind. It seems like you can't really trust the first build of any artifact unless it comes from a central source.
There have been discussions of an "N of P" distribution, i.e. if 80% of available peers (or substitute servers) advertise the same build result, then treat it as safe.
I expect that both will be implemented, and the choice left up to the user.
With regards to downloading speeds, the issue seems to be downloading many packaging as opposed to large packages. Each package incurs some noticeable overhead, which is painful when upgrades consist of dozens or hundreds of upgraded packages.
I tried installing GUIX on my 2013 MacBook Air 11" on Sunday night.
The installer insists on erasing the entire disk, not sharing with other partitions.
I removed the SSD for safety, and plugged in a second USB stick.
The installer took from 21:20 to 7:30 am the next day. It needed to be connected to wired Thunderbolt Ethernet, which in my case means in the laundry.
Downloading packages took a long time (about 2 hours). "grafting" took longer. Finally it failed to set up the bootloader. No big deal, try GRUB or rEFIt, right? But they didn't detect it.
There is an "EFI Boot" option in the startup menu (holding option). That just boots to a black screen.
I'm sorry, but issues like this mean that I think GUIX is not desktop-ready for bare metal. It'll be relegated to a virtual machine (along with OpenIndiana, PureOS, Haiku, Hello, etc).
Are you aware that Apple hardware pre-2015 was much more open than it is today? I agree with your sentiment for modern Macs, and that's why I'm trying to find a suitable OS for switching.
When there's a limited scope of what drivers are required, it should be easier, not harder, to support certain hardware. Being unable to read NVME drives (which have been around since 2011) is no longer acceptable for an OS in 2020.
AFAIK Guix stays very true to the GNU values of ONLY shipping free software, including drivers. A couple years back I had a similar issue where I couldn't get my WiFi card to work because I'd have to recompile the kernel while including nonfree libraries... which is pretty hard to do if you know nothing about Guix!
Maybe I'll try it again in a while. Not sure if it's available for raspberry pi, but it would be great to try it there and eventually switch to it on my laptop (once JJ change WiFi card!)
I used to have a 2011 macbook pro. I couldn't boot USB media at all. It's not a new problem. After my optical drive died, I had to resort to creating my own installation media on a hard disk partition..
Guix rejects non-free software in their repos, so I would be unsurprised to hear that no contributors use Apple hardware.
I agree that what you are trying to accomplish should be doable and even non-trivial. This is definitely a disadvantage of having a more automated installation procedure.
(you can also install Chromium extensions with Guix)
> 3. Is there an escape hatch if I'd rather just download an Electron binary for my package dependency rather than properly package Electron?
Kind of. You can define an environment with the relevant dependencies on LD_LIBRARY_PATH (or use "patchelf"). But expect to experiment a bit to make it work.
I give Guix folks a lot of credit for sticking with a pure language but after using Nix expressions for a bit favor how pragmatic it is for day to day stuff.
Though I should note: I trust Guix more than nix. I use nix for convenience but really admire what Guix has done in terms of taking the concept of a functional package manager to be as pure as they can. The security stuff they’ve incorporated is very admirable and a compelling reason for me to switch over https://guix.gnu.org/blog/2020/securing-updates/
Scheme/lisp might be weird for some. But Guix packages are written in a highly declarative style. Very little control flow. It looks kind-of like JSON.
Not OP, but it's a declarative configuration system, so an existing declarative language like Prolog would seem to fit naturally. Declare the relations between packages, the constraints that must be satisfied, and let the compiler perform unification to get the resulting configuration.
FWIW the Guix community is, too. The person you replied to doesn't like that the Guix project has used their platform to distance themselves from RMS when he did something that reflected poorly on all of the GNU project.
Why wouldn't Guix just leave the RMS's GNU Project then?
GNU is a collaboration of free software projects that was started and is lead by Richard Stallman. Remove the leader, and what's left is just a collection of projects sharing the GNU brand. And it looks to me that this is what the Guix maintainers are trying to do: reduce the GNU project to a mere formality (participation in it would mean no more than a simple declaration of support for Free software), keep the GNU brand, position Guix as THE GNU operating system.
It's true that RMS founded GNU and was the key leader for decades, and is basically its mascot. To many, RMS and GNU are the same. One cannot overstate his impact on the ideals and values of GNU.
I disagree with the suggestion that the group of people under discussion — who aim to distance themselves from RMS — want to "reduce the GNU project to a mere formality".
I think it's the opposite: that those people want to embolden GNU and strengthen the bonds between the various GNU softwares to create a first-class operating system made of free software, the GNU way. They ended their association with Stallman but continued with GNU because they believe in its goals. One could even say they did it because they believe that GNU is important.
It's been a very long time since RMS was able to marshall a group of people to work toward that goal. The maintainers of Guix and the other signatories of the statement against Stallman's leadership are doing that very thing.
The proof is in the pudding: the latest Guix release had 201 contributors. I think that's a lot.
GNU is internally managed on a private mailing list. Guix and other GNU maintainers coming out against Stallman may have been surprising to those who aren't privy to that list, but for the rest of us, it has been a long time coming.
For a long time, key GNU projects have either effectively quit GNU or, with great effort, wrested authority away from RMS because what goes on "behind the scenes" in GNU is not good. The only change is that now they are doing it in public.
> The only change is that now they are doing it in public.
They very conveniently started to do it in public when Stallman's reputation was severely damaged by the media spreading lies about him, when he lost his home, when he most needed support. And they started by publishing a vague defamatory statement against him, and they used the GNU projects website for that. And they continued to defame him on the mailing lists.
Could there really be any excuse for their actions? Was it acceptable even if they believe that they were doing it for the good of the GNU project?
> was the key leader for decades, and is basically its mascot.
RMS was and still is the GNU project leader.
> It's been a very long time since RMS was able to marshall a group of people to work toward that goal.
He gives talks all around the world, trying to warn people about proprietary software and getting them involved in Free Software.
> GNU is internally managed on a private mailing list.
But this little kerfluffle was on a public mailing list, as was requested by the various maintainers who wanted to oust RMS. It was open for anyone to follow along on the gnu-misc-discuss list from 2019-10 and forward. The discussion doesn't really support your "it has been a long time coming" assertion.
> For a long time, key GNU projects have either effectively quit GNU
If you mean Gnome, it still has a lot of those who support GNU, or aren't even aware Gnome is not GNU. There are enough of them the Gnome leadership only raises issues when it allows them to raise their own profile and public visibility, like what happened during the MIT debacle.
> The only change is that now they are doing it in public.
Thankfully, so everyone can read for themselves how claims that what is going on in GNU is "not good" is very subjective and more of a "not how I personally would like it to be".
GNU is bigger than RMS. Consider the fact that he’s getting on in his years - do you think that GNU will just fold when he’s no longer with us? Of course not, he’s the founder but it doesn’t stand and fall on his name. You’re suggesting the equivalent of “if you don’t like it just fork it” - which is usually to splinter and fade into obscurity. Many in the GNU community felt the same as the Guix maintainers.
Even RMS never suggested they leave the GNU Project (to my knowledge) - and why would he? Guix and Guile are two of the most vital projects in GNU, and the maintainers, both in their capacity as individuals and maintainers of a GNU project, are entitled to espouse their own views. So, if RMS himself didn’t even think they should pack up and leave, taking a crucial aspect of a GNU operating system with them (besides Debian which isn’t part of the GNU projects, how many other GNU operating systems run Linux-libre or Hurd natively?), what makes you think it’s a good idea?
> do you think that GNU will just fold when he’s no longer with us?
Either fold, have new leadership, or become a formal declaration of endorsing some values (not really a project). Maybe it will eventually center around one subproject and become mostly associated with it (Guix as THE GNU OS).
The problem is that the Guix maintainers want to remove Stallman from his own project while he is alive and active, and they pursue their intention with methods that are unethical, disrespectful and destructive to the community.
> Even RMS never suggested they leave the GNU Project (to my knowledge) <...> what makes you think it’s a good idea?
I don't really want Guix to leave GNU, I'm questioning the motivation of the maintainers.
RMS does not own the GNU Project. Period. Many have said that this action is about removing him from his own project - it is not, it is a statement that he should not lead a collective project which he founded. He is a founder and a leader, not a king. He’s not even a BDFL. It is not disrespectful or unethical to espouse this view. I don’t think it’s necessarily disrespectful or unethical to oppose this view either, but it is disrespectful to the child victims of sex crimes to accuse the signatories of the statement of acting unethically or underhandedly.
It’s good that you don’t want them to leave GNU, but then asking ‘Why wouldn't Guix just leave the RMS's GNU Project then?’ seems strange - why would they indeed? I think it’s not unreasonable to take them at face value: they made a statement about their belief that the personal conduct of RMS made him unfit to lead the GNU Project.
For what it’s worth, RMS is someone who I think can change his mind when he believes he is honestly wrong, which is not something you always get with people in his position. This however doesn’t mean his statements should go uncriticised. Linus Torvalds is a gold standard here, where his professional conduct was called into question and he took a serious look at himself, made some changes to his behaviour, and came back stronger than ever. RMS could take a leaf out of his book.
> It is not disrespectful or unethical to espouse this view.
And rms would agree. In fact, you don't need to like rms or believe in Free Software to become a GNU maintainer. This wasn't about that.
> but it is disrespectful to the child victims
Yeah, no. When Nadine Strossen, former president of the ACLU, takes the time to weigh in on a personal title on the matter, that means Stallman has been vindicated. One can no longer pin their lack of reading comprehension on him. If someone only gets "the facts" from twitter, that is their own problem, not GNU's, not Stallman's.
> accuse the signatories of the statement of acting unethically or underhandedly.
They spammed all GNU maintainers addresses.
Not all the advocacy for their cause was transparent and above board. It's all there in the mailing list for anyone to see and make up their own minds.
What exactly is it about then? All I have really heard as a not-unreasonable repudiation of their actions is that they have somehow misused their position as GNU maintainers, which is neither here nor there - whether you agree with it or not (I disagree, I believe they have the freedom to espouse views like this regardless of their position, and that they didn't misuse their platform in any way), it's a complete non-sequitur to the matter at hand.
>When Nadine Strossen, former president of the ACLU, takes the time to weigh in on a personal title on the matter, that means Stallman has been vindicated.
I'm not familiar with her or her statement. Her former position is irrelevant, what we should all be concerned with is the facts. For that reason I can't comment on her position on this.
>They spammed all GNU maintainers addresses. Not all the advocacy for their cause was transparent and above board. It's all there in the mailing list for anyone to see and make up their own minds.
I don't know what your definition of `spam' is, but a singular message containing a statement of interest to recipients doesn't really constitute spam to me. You would think that GNU maintainers would want to be notified of this - imagine if the Guix maintainers and others had made this statement and _hadn't_ sent such a notification, there would be talk about how they are secretly undermining the unquestionable leadership of RMS or some other nonsense. Let's also not forget the fact that Jean Louis really did spam the Guix mailing lists for weeks after their announcement, to the point that the mailing lists were almost unusable, and the Guix mailing list moderators only banned him after a large number of complaints.
The fact that you are saying that not all their advocacy for their cause was transparent and above board, while also saying that it's all in the mailing lists for all to see, is confusing to me. Sounds very transparent to me.
> When Nadine Strossen, former president of the ACLU, takes the time to weigh in [...]
The only source I could find for that comes from some sketchy book promotion site. Are you sure that Strossen wrote about Stallman? Do you know of a better source?
What do you mean by "extreme liberal viewpoints"? The only thing I've witnessed is that the Guix maintainers took a clear stand in support of holding RMS accountable when that was ongoing a year back.
As it stands, my guess would be that it's rather that you feel inhibited in expressing your own hateful ideology?
No, it wasn't Guix maintainers. It was one guy saying "A bunch of us have had enough", "we've just about had it" and basically pretending that the community was against RMS. And there wasn't anything hateful about what RMS said, neither was he expressing pro-pedo sentiments, which was implied by Wingo.
I am upset that someone tried to ruin RMS' character with false rumors. Expressing my own "hateful ideology" is a little far fetched, given that I don't approve of trying to tarnish RMS' reputation for something he didn't do, and I don't see what's hateful about that. How would you like it if an important figure in the community falsely accused you of being a pedophile? This childish hateful propaganda doesn't belong on a programming language message board.
Read "Jean Louis" response to the gross accusations against RMS if you haven't.
For those that read the above comment, I believe by "Jean Paul" they mean "Jean Louis", who spammed Guix, Guile, and other GNU mailing lists for weeks with lengthy, rambling essays saying essentially the same thing over and over. They maintain a web page smearing one of the Guix maintainers. Among other details on this page that I can only describe as a screed, are a collection of cherry picked comments from sources like 4chan that agree with their point of view. Unsurprisingly, these comments include slurs (homophobic, ableist, and more) and other offensive language. So take that into consideration when deciding who is spreading hateful propaganda.
> No, it wasn't Guix maintainers. It was one guy ...
I'm sympathetic towards Stallman because he was subject to a witch hunt and thrown under a bus without a good reason (or at least a good and publicly known reason), but I'm pretty sure you're wrong.
That response seems to mostly consist of name calling and the assertion that GNU Guile and "politics" are completely unrelated topics that should never be mixed. He alludes to a Reddit comment which seems to have been deleted.
At best, that seems to boil down to an argument over whether an organization can thrive while being agnostic about child sex trafficking. (That may sound sensationalist, but I mean… that's his entire argument against the allegations as presented.)
Oh my. One of our maintainers wrote the following on his personal blog:
"It sounds horrible: "UN peacekeepers accused of child rape in South Sudan." But the article makes it pretty clear that the "children" involved were not children. They were teenagers.
What about "rape"? Was this really rape? Or did they have sex willingly, and prudes want to call it "rape" to make it sound like an injustice? We can't tell from the article which one it is.
Rape means coercing someone to have sex. Precisely because that is a grave and clear wrong, using the same name for something much less grave is a distortion."
He's clearly a pedophile! How could the project be agnostic about something like this? Clearly he both endorses and encourages rape of children! (Even though there were no children involved in the story in the first place)
This was Stallman's argument as well. It is also part of why he was canceled.
In the USA and many other places we, society generally holds that, below a certain age, people are still mentally "children" and unable to evaluate certain life decisions. Therefore, if someone above that age convinces someone below that age to enter into an act that the younger party is not able to understand, then the younger party was effectively coerced, even if from their perspective the activity was consensual.
There are a few activities that fall into this category: purchasing drugs and alcohol, driving motor vehicles, enlisting in the military, and sex.
So yes, having "consensual" sex with a minor is rightly considered coercion and therefore rape, unless you disagree with the line of reasoning stated above. Yes, it's not violent like some rape, but it is still definitionally rape. And it absolutely can and does have negative effects on the victim, see here (https://psychology.stackexchange.com/a/21989) for a pretty thorough dive into the subject and a huge pile of academic sources.
And that's not all. In at least one instance, Stallman specifically hypothesized that the girls who Minsky had a sexual encounter with on Epstein's island "presented themselves as entirely willing". We don't know what exactly happened between Minksy and Virginia Giuffre, and it is indeed likely that Epstein's sex slaves were instructed to present themselves as willing. But with his poor word choice and prior history of publicly not understanding the concept of statutory rape, it was a bad look for him, and all it took was one Vice journalist taking him out of context to bring the shitstorm down on his head.
> In the USA and many other places we, society generally holds that, below a certain age, people are still mentally "children" and unable to evaluate certain life decisions.
You can look through some of these consent laws and tell me what that age is:
Let me state up front that I'm an RMS fanboy. I love the guy and think he's dead-on prophetic about 95% of the time.
That said, RMS seems to demonstrate a poor understanding of how his messages will be received. Time after time, he's said things that are perfectly reasonable and defensible when you actually think them through, but on the surface sound awful and turn people away. A big component of communication is tailoring your message so that it will be heard, and I just don't think he's very good at that. In political terms, he's great at speaking to his base but not so hot at converting non-believers.
Let me invent a purely fictional example of something he did not say. Suppose you open an article with "Hitler wasn't completely bad." That's defensible! By all accounts he loved his pets, and it seems like he was nice to his officers' kids. But really, that doesn't matter: that opening sentence has lost an enormous part of the audience, even if the rest of the article built a case that would make sense to people who read the whole thing. Most ordinary people would see that and say "that's crap and I have no desire to hear what else this person has to say", and that's perfectly understandable because most authors who open that way are going to end up saying something absolutely despicable.
Well, when RMS wants to say things implying that maybe pedophilia isn't always bad and perhaps it gets a bad rap because some parents aren't OK with their kids growing up, he needs to be exceedingly careful how he phrases every word of it because he's commenting on an extremely charged subject. And yet, he doesn't. It doesn't matter whether you have a good point to raise if your wording makes most people shut down and reject your idea immediately.
Again, I dig RMS. He's an incredibly smart guy who has some brilliant ideas. But wow, I sure wouldn't want him defending me in front of a jury. I don't think he's a pedophile, but I absolutely see how easy he made it for some people to claim that.
Incredibly well put. Hats off to you sir. I don't think it's simply the unwillingness to think things though that make people attack him though. I think that halfway through writing their heated response, people realize their mistake. However, in today's climate, a lot of people are frothing at the mouth in anticipation of finally having found "a nazi", "a pedo" etc. So much that they see them everywhere.
I don’t think it’s fair to chalk it up to “unwillingness to think things through”, though, and that’s my point. RMS doesn’t seem to me to fully appreciate the emotional landlines in some of the subjects he discusses. When you’re talking about software licensing there’s some wiggle room, but when the subject at hand is pedophilia, successful communication requires a degree of tact and nuance that I’ve not often seen him use.
If you say something that 1% of the audience completely misunderstands, so be it. There’s always going to be some contrarians; haters gotta hate. But if the majority of the people have a different interpretation than you meant, then maybe the problem is in how you said it.
Yes. Some subjects are very tricky to discuss. I have an example earlier: you wouldn’t want to come across as a Hitler fan. You can discuss these things in public, but have to be exceedingly cautious to avoid people misunderstanding your position.
Moreover, no one, I mean /no one/ in this world is 100% perfect. I respect RMS as I respect Nelson Mandela or Gandhi. Think of anyone else from the past.
RMS has done so much for the computing world. And I firmly believe that he isn't a pedophile. And he doesn't even support pedophilia. Just that he has uttered something, doesn't make him a criminal.
Alright, I'm not a doctor, and I certainly not Stallman's doctor. I think it's likely that he has Asperger's based solely on comparing his actions and words with those of my friends who've been diagnosed with Aspergers', but I don't actually know that he does.
With that out of the way, I haven't heard of anyone harassing him for having Asperger's. However, I think it's possible that he has it and that it has led him to saying things in untactful ways, and it's those things he's said that irk people. I can empathize with people who wouldn't want someone who says those things to represent an organization that they work with, regardless of what caused the person to say them.
> I haven't heard of anyone harassing him for having Asperger's
I may have worded this badly (not a native speaker, it takes a lot of time for me to find the right words and formulate my thoughts in English), but what I meant is that they are using Stallman's peculiarities (which are likely ASD-related) against him to destroy his character. See the message I linked earlier where Wingo refers to multiple posts on stallman.org suggesting his very biased interpretation of their meanings and of Stallman's behavior.
> I can empathize with people who wouldn't want someone who says those things to represent an organization that they work with, regardless of what caused the person to say them.
But GNU is Stallman's project (and it is not an organization), he started it. They could just leave and continue working on Guix independently. Some projects join GNU, some leave, no one is forced to work under Stallman's leadership. But it appears to me that Guix maintainers feel so attached to the GNU identity, that they want to hijack it instead.
Yeah, that too seems likely. I'm not going to weigh in much on that because I wasn't there and don't have an in-depth understand over everything that happened, but it does seem like there might've been a better way to handle that.
That said, the parent comment made it sound like it was unreasonable to take RMS's comments as meaning he was pro-pedophilia. And while I think I understand what he was trying to say, I can completely understand how reasonable people could interpret his words in a very bad way. That's the part I was really replying to, not how his dismissal was handled.
> Well, when RMS wants to say things implying that maybe
> pedophilia isn't always bad and perhaps it gets a bad
> rap because some parents aren't OK with their kids
> growing up, he needs to be exceedingly careful how he
> phrases every word of it because he's commenting on an
> extremely charged subject.
I hear your initial thought here, that talking about sensitive topics requires a sensitive hand, and RMS may lack one. And that's a valid point.
For some topics.
RMS has a history of defending or being actively supportive of pedophilia.
This isn't just a matter of RMS being incapable of speaking about a sensitive topic with grace. If I start raising questions about how smart non-white folks really are and supposing that perhaps only white folks can be in leadership positions, multiple times in multiple venues -- well, folks are going to think I'm a white supremacist. And the harm I'll have done to the non-white folks in my community will have already been done.
And no amount of (pp.) "carefully phrasing every word because it's an extremely charged subject" is going to change that.
For full disclosure, I think you can make a reasonable case for at least some of what he said in the link I just posted. For instance, an 18 year old having sex with their 17 year old partner doesn't automatically make it non-consensual, and lots of states have so-called "Romeo and Juliet" laws that agree. That's where the call for caution and careful phrasing come in: does he intend to mean it's OK for an 18 year old and a 17 year old to date (which I'd agree with), or for a 40 year old and a 15 year old (which I'd vehemently not agree with)? If what he meant was the former, I wish he would have clearly stated so and avoided the whole issue. If it really is the latter, then there's no way I'd attempt to defend that or be willing to consider the nuance (and more than I'd be willing to consider your analogy).
Stallman chooses his words precisely. An 18 year old dating a 17 year old isn't a pedophile formally or informally. The article he shared is about a campaign to make 12 the age of consent among other things.
You're willing to give him the benefit of the doubt because you're a fan of his work and his ideologies in other spaces. Which makes sense, I dig it.
For myself, I'd rather not expend the mental gymnastics. If RMS had ever wanted to set the record straight, he could have. If he isn't willing to clarify, personally I'm uninterested in attempting to do it for him, and inclined to assume this (like his other writing) is direct and unambiguous.
(Edit, to add:) And to reinforce my previous point: sometimes the damage one's words do can't easily be undone, and treating everything like it's a philosophical debate and not someone telling us who they are may reinforce that harm.
I'm not disagreeing with you. I didn't follow this whole saga very closely and I picked the one quote of his that I'd seen in the headlines. It's not that I'm trying to give him the benefit of the doubt as much as up until this moment I haven't personally seen anything worse than that one comment.
That one comment by itself seemed bad but explainable. If he's said worse, well, damned if I'm going to be an apologist for a pedophilia advocate.
It's one thing if someone makes an offhand comment like "Oh yeah, Hitler wanted to be an artist!"
You'd be like "Ok, interesting tidbit but whatever".
It'd be a whole 'nother thing if one multiple different occasions you start talking about positive hilter attributes.
I think it's reasonable for people to be pretty uncomfortable with the number of times and frequency that RMS seems to want to talk about underage sex. That certainly does not make him a pedophile. It is, however, pretty off putting.
All this makes me feel very much like the Hans Reiser case. I was internet active at the time and remember all of his fans swear up and down about how innocent he was and how much he was a victim of the corrupt judicial system. Then that fateful day happened when Reiser was convicted and basically said "Ok, if you'll give me a lighter sentence I'll show you where the body is".
Stallman did a lot of good for the opensource community, which makes him a hero to many. I think, however, it's unhealthy to try and justify his statements on pedophilia. It's ok to talk about the nuance of the laws (Certainly there are major issues with the way CP laws work. It's a bit crazy that teens are getting convicted of it over normal teen behavior). Stallman has been really icky here. He talks not about age difference but instead how "voluntary" the acts are. Trying to read in "Romeo and Juliet" scenarios when he himself doesn't even mention that is trying to paint a more rosy picture of what stallman wrote.
All of this, frankly, can also be cleared up by clarifications from Stallman (which he's not published). He could say pretty much exactly what you've said here "When I was talking about X, this is what I meant". He's not done that and I think that's really telling. Maybe someone told him to STFU, but then again, he's not really been silent on his positions on sex throughout the years, so why start now?
Ugh, I remember the Reiser case pretty well, and perhaps that's a good cautionary analogy.
And ultimately, you're right: if everyone misinterpreted him, it's on him to come out and explain what he really meant. It wasn't my intent to play devil's advocate here, and my original point was just that I think he can be a poor communicator on difficult topics.
Could you show us an instance of RMS being "actively supportive of pedophilia"? This is a claim that will both ruin a man's career, life and reputation, so you better have some decent sources.
> I am skeptical of the claim that voluntarily pedophilia
> harms children. The arguments that it causes harm seem
> to be based on cases which aren't voluntary, which are
> then stretched by parents who are horrified by the idea
> that their little baby is maturing.
Please note that for the purposes of determining statutory rape, a person under the age of consent is not mature enough to give consent, so there cannot be "voluntary pedophilia."
> Rick Falkvinge joins me in demanding an end to the censorship of "child pornography"
This second seems to touch lightly on specific cases where the definition of "child pornography" should perhaps be in question -- but given RMS' stance from the former quote, it's not clear that this is the entirety of his viewpoint.
See my answer to the guy below. He's arguing for a law such that child molesters can more easily get prosecuted, instead of prosecuting teenagers who have pictures of their girlfriends/boyfriends.
That's one of the two links I posted, which I think Stallman did not link in the faith you give him (nor do I think was written in that same faith), but that's subjective.
The other is where he's doubting that pedophilia is harmful to children. So yeah, that's pretty well "in support of pedophilia." That one isn't subjective, it's the words he typed, and try as I might I can't find an interpretation where he's not saying pedophilia is fine.
So he links to a post that wants to change the law such that pedophiles can more easily get caught, but you disagree, and feel that he linked to it in some sinister motivation that isn't expressed in said article. Alright...
If I said "I am skeptical that infants smoking weed is harmful to them", does it mean that I smoke weed, or that I smoke weed around infants? Or that I actively support it? Or do I (perhaps wrongfully) state that I am skeptical about claims around the topic?
Personally I think pedophilia is just about the most awful thing in the universe. I wouldn't engage in in depth speculation about how it affects children, because I think it's a horrible thing to think about, but the fact that RMS engages in those conversations doesn't make him a pedophile. And it definitely doesn't make him an "active supporter" of it.
Did you actually read those links? The very first paragraph on the falkvinge-page:
"This article argues that our current laws on the topic are counterproductive, because they protect child molesters instead of bringing them to justice, they criminalize a generation of normally-behaving teenagers which diverts valuable police resources from the criminals we should be going after, and they lead to censorship and electronic book burning as well as unacceptable collateral damage to innocent families. Child abuse as such is not condoned by anybody, and this article argues that current laws are counterproductive in preventing and prosecuting it."
So they're arguing for a change in laws such that child molesters could more easily be prosecuted? And here you are accusing a man of actively supporting pedophilia based on some gossip from someone who also didn't read what he was actually saying?
> I am skeptical of the claim that voluntarily pedophilia harms children. The arguments that it causes harm seem to be based on cases which aren't voluntary, which are then stretched by parents who are horrified by the idea that their little baby is maturing.
We are talking about what stallman has written. The above is what he wrote. The distinction he's drawing between "voluntarily pedophilia" and "involuntarily pedophilia" is one that I don't believe exists. Particularly because "grooming" is a common tactics of pedophilies.
Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.
Every time I see a package being distributed as a Snap, I wonder why. These containered solutions are very complex, trying very hard to emulate FHS with mount namespaces, binding mounting tons of sockets around, and almost always end up mounting all of /home in the container. The don't provide much security, and quite difficult to deal with, and require a daemon.
Nix on the other hand has zero containerization requirements. It simply works by ensuring the programs are looking in the right place for the libraries they need. It would be great if more vendors just shipped a Nix derivation (or store path) that was their application stack. It would end version incompatibilities for ever, in a way that isn't a burden for the user.
Nix + bubblewrap add all the benefits of snap and flatpak as well. But again, there is no benefit to bubblewrap is if you are just going to blanket allow read-write everywhere anyway. At least with raw bubblewrap you can make these policies actually protect something.
Similarly, Nix is easily installed on any existing system. So you can use nix packages on Debian, Ubuntu, Centos, Fedora, DSL, or any other linux distribution because it runs entirely out of /nix. I use nix packages on Archlinux at home, and Debian systems as work.
Cross distro development works 100% of the time because Nix doesn't use anything from the distro.
Nix (and Guix) are really what the Linux community should be moving towards IMHO. I personally prefer Nix's syntax, but the underlying technologies are so similar I consider them the same. Guix started as a fork of Nix, and one day I hope they decide to end up becoming compatible with each other again.