"TERF" is just the newest slur anti-feminists came up with to further the evil feminist trope. Anyone who looks into the conflict between feminism and the transgender movement can see that the so-called "TERFs" are the ones on the side of common sense, fairness, and universal anti-discrimination principles.
[I hope this is OK to share here; the guidelines haven't made it very clear to me what HN's stance on political submissions is. Feel free to ignore / purge / flame me if this isn't a good place to share. This account is literally 10 years old but I only have 2 past submissions.]
This is an article of mine lamenting how the code of conduct trend has not changed anything for the better.
To the contrary, I believe the massively popular Contributor Covenant (the specific CoC now used everywhere, even by Linux) is arguably sexist/misogynist in nature, and can be used to harass feminists.
Specifically, I was hounded out of the Guix community for daring to suggest that the CoC should perhaps include the term "sex." (You know, whether someone is female or male.) It does, after all, list everything else under the sun for which you could be discriminated against.
Eventually, they included "sex characteristics" in line with the changes made upstream in the C.C., but I'm unhappy with this for reasons outlined in the article / in the GitHub issue mentioned in the article.
To be honest, I've grown overall highly skeptical of CoCs, and believe they've become tools to push specific political views instead of foment a friendly and inclusive environment. (Yes, I know some will say "duh" but I used to be very optimistic.) This article is, however, written from a very pro-feminist standpoint, so be wary if that's not your cup of tea.
I was thinking "wow that's a great idea" while reading through this and then noticed it's basically what a Lisp environment does. :-)
(And probably the environments of many other languages, but Lisp implementations (including Scheme implementations) tend to do this exceptionally well. A very good example might be Emacs, which has just an amazing help system and all.)
Sorry but I have to disagree on pretty much every single point. In part you simply make factual errors.
I think the page looks fairly stylish. Could improve, but pretty great already in choice of colors and layout. ("Dehydrated urine" for a simple gold color? Seriously? Stop watching watersports.)
Being 100% free software as in GNU, meaning being entirely free of uninspectable binary blobs, and working hard to make the system easily improvable and amendable by the user community, is a big deal. Deal with it. GNU aims for people for whom these are important criteria.
The features listed in the second point are based in concepts that are nontrivial to grok. There is no short way to explain them on an intro front page, but not mentioning them would be silly since they are what sets Guix apart from standard package managers (which ironically is what you request being listed). Maybe you should look up the meanings of those terms instead of straight out assuming they're marketing buzz. Transactional updates, and unprivileged/user-level package management are pretty big deals. Likewise, providing clean APIs in a high-level programming/scripting language is very much a big deal; see how easily a web front-end could be made for Guix.
Redirecting newcomers to Nix would just add an unnecessary layer of indirection. The name is clearly a homage to Nix, and also otherwise "everybody knows" that Guix is Guile+Nix, so claiming there's malicious intent in leaving out a mention of Nix would be just silly. And Guix is not a Guile wrapper around Nix; it has an entirely different package recipe format and database. You don't use Guix to work with a Nix system; rather the Guix system uses a low-level component taken from Nix. Casual users don't need to know anything about Nix.
Lastly, functional package management brings immense pragmatic benefits (source-binary correspondence, reliability of transactional updates, etc.), i.e. it's not simply a dogmatic application of FP concepts to package management. You'll note that Guix uses Scheme, not Haskell. I think most people interested in functional package management are so for the practical benefits, so I think you have a pretty wrong image of those folks.
All in all, please make sure you have a proper understanding of a topic before making such inflammatory remarks. It doesn't help anyone.
>And tell me about all of those wonderful command-line games!
You can pry my MUDs out of my cold, dead hands, thank you very much.
More seriously, it simply says {applications, games} x {desktop, web, CLI}, where the (game, CLI) tuple is left for the reader to filter out. Obviously it primarily means CLI applications. I think you're being unreasonably pedantic.
And yes, server-side programming is part of web programming.
I really see nothing wrong with the new Guile website. In fact I think it's excellent both in information and artwork. :-)
I wrote this a while ago, mostly to clear up my own thoughts and document the knowledge for the future because inevitably I'll forget about the details again and again since they're so freaking complicated.
It used to be an intimidating .txt, but I just converted a few of my scratch documents to fancy HTML pages using some minimal CSS, thanks to MarkDown, pandoc, and bettermotherfuckingwebsite.com, so I thought it might be worth sharing now.
All of the things you list are annoyances with crud that exists to satisfy this or that use-case which I suppose you personally don't need, which doesn't mean they don't have purposes. I would also say they are all minor annoyances. Your builds run faster than a ./configure script? Not building particularly large projects I suppose. Installing autotools? Big deal! I don't know when one needs to write m4, but the Makefile.am format looks rather clean and minimal to me; I don't see how you could have something much cleaner without losing a lot of generality. And having to delve into the guts of some obscure system is exactly what I had to do a few times because some piece of software refuses to keep with the convention and just use Autotools.
The documentation you ask for is idealistic and unrealistic. GNU Autotools are free software, and with decades-old proven maturity; I see no reason not to use them. The only pseudo-reasons I see are NIH, FUD, etc.; the usual.
GNU Guix (and before that, Nix) is fundamentally different from all other package managers, so that analogy makes no sense here unless you have some radically different innovative build system.
I wonder what makes you say CL feels more well-engineered? I can't think of any reasons, unless you simply mean Scheme's under-specification.
Scheme is not just "conceptually" cleaner if you ask me. It's very concretely cleaner. The naming conventions for one ("rplaca" anyone?), the clear-cut orthogonal APIs, the numeric tower with exactness/inexactness, and [insert pun about "hygienic" macros being "cleaner"...]
I agree that a Lisp is better than no Lisp; I'd be more or less equally content if Guix used CL. Major Scheme implementations don't have much lacking compared to CL though, and the core is somewhat cleaner with less historic baggage, so I'm most happy with Scheme. (The standardization though ... sigh)
This is off-topic but I personally prefer to just say "GNU" these days for what most people call "Linux" (excepting systems that somehow use Linux without GNU of course). It makes sense when you consider that:
- GNU has always been a project to make a whole OS, and the name of said OS is GNU. Linux on the other hand is explicitly a project to make a kernel only. When talking about a system consisting of GNU components for everything but the kernel, that would simply be the GNU OS using a third-party kernel.
- In terms of components implementing the base Unix system (see e.g. POSIX for a formal description of this "base system"), GNU components and Linux are probably roughly equivalent in size (don't underestimate Glibc and the whole userland Unix toolbox, not to mention compiler toolchain), so just "GNU" might downplay the importance of Linux and thus "GNU/Linux" would be the most correct term, but we all know it's cumbersome especially in speech, and if I'm going to shorten it then GNU is the obvious choice in line with point 1. It certainly makes more sense than "Linux".
Some people like to point out that GNU components can be replaced. So can Linux, as evident from e.g. Debian GNU/kFreeBSD, so that's not an argument. You can even use GNU on top of Windows via Cygwin. :-P
Of course the reason I bother is that I want GNU to be more widely known. It deserves at least equal respect with Linux if you ask me, yet 98% of everyone I met who had heard of "Linux" never heard of GNU; some knew the GPL but not GNU. And I work at an IT company...
Guix is a GNU project, meaning it will adhere to a higher code of software freedom ethics. (For instance Nix ships Adobe Flash Player with Firefox if I remember correctly.)
Guix uses Guile Scheme APIs/EDSLs for package recipes, build systems, etc., giving you the power of a proper programming language (and a lisp at that) as opposed to the special-purpose Nix language and arguably dirty Bash and Perl code.
The Guix System Distribution uses a Guile-based init system, DMD, instead of systemd, which again should give a lot of power and flexibility. (systemd being implemented in C instead.)
That's all off the top of my head. I haven't used Nix and someone who did might be able to point out many more differences that aren't obvious at first.
>Some day when I have the time, I will rip out all the autocrap stuff and replace it with a 5 line shellscript that calls uname -s.
And packagers will everywhere will hate you for it.
I've recently written many GNU Guix package recipes, and packages using Autotools are the ones I tend to have the least headaches with. CMake and Waf are so-so I think, perhaps lacking in maturity, but I didn't have that much experience with them. Custom/hand-written Makefiles and ./configure scripts are the worst.
Just learn Autotools, get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD. Even if only targeting GNU and BSD systems, there is already enough diversity and library detection boilerplate to make it worth using a proper build system, and Autotools is the most mature one out of the bunch.
It's even more important for unconventional systems like Nix/Guix where software is to be built in very special ways, where hard-coded assumptions in build systems hurt, especially if a custom one; if it's a known one then even if hard-coded it will probably conform to some typical pattern of use of that build system so one can use tooling to automatically fix packages using that build system, and in the case of Autotools that isn't necessary in first place because everything is parameterized and flexible to hell and back.
Also please do use pkg-config. Like Autotools, it's not perfect either, but I could write another two paragraphs on how helpful it is in bringing consistency, toolability, etc. into build/packaging systems...
I also started thinking things along the lines of that when I first looked into how Guix does things, but after annoying the developers a little (many thanks to Ludovic's patience) I've come to understand that things like that beat the whole purpose of having pure packages not only in binary content but also in run-time behavior.
Basically, reproducible builds are a red herring here. A package's identity is not only the hash of its byte-by-byte contents, it also includes ("closes over") the identities of all packages it "references" (depends on), meaning it will always have the exact same run-time behavior everywhere because even all its dependencies count as part of its identity.
From my understanding, the biggest disadvantage to purely functional package management is that you can't just swap out a package in isolation when many others depend on it. If I upgrade a package, I have to upgrade its whole DAG of dependent packages if I want them to use the new version (I could however delay that; they would simply continue to use the old version which hasn't been garbage-collected yet because they still use it).
So lots and lots of compilation (on build farms at least), and lots of bandwidth usage. Though something like ccache can help with the compilation, and binary diffs could help with the bandwidth.
Immutable data structures in FP are probably a good analogy.
Edit: argh, this was supposed to be a reply to the question about the disadvantages of the purely functional package managers specifically, not the OS in general.
Guix is a big effort at making a purely functional package manager with a large recipe database and all kinds of bells and whistles you want in a full operating system.
Emacs's minimal package manager is to install Elisp libraries (and nothing else) on every platform where Emacs runs, including MS Windows, and you can be happy it does dependency tracking.
The two can't really be compared. Maybe in 10 years Guix will run on all platforms and have its components separated in such a way that it's sensible for Emacs to ship a version of Guix with it for Elisp package management, but don't hold your breath.