HN user
"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.
It's because tech bros hate feminists and their allies even more than they hate the corrupt tech industry.
[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 think that's a good thing when the principles are worth it. :-)
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.
Enjoy the brain-melt!
Late reply but:
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"...]
Common Lido
Slipped by one column on your keyboard? :-D
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.
Someone else just pointed that out to me too. I didn't know of all the connotations of the term, sorry about that. :-)
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.
Version 0.8.1 of GNU's purely functional package manager Guix has been released.
The project develops, at the same time, GNU GSD (Guix System Distribution), a GNU operating system.
GNU GSD is an avant-garde GNU system utilizing Guix as its package manager, and the similarly Guile/Scheme based dmd as its init system.
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.
So I don't think NIH applies there.
While the phrase "nothing is implicit" was used, there actually are so-called "implicit inputs" in Guix. :-P Each package uses a certain "build system" which can be e.g. "gnu" which has e.g. autotools and bash as "implicit inputs" so every package using that build system gets those dependencies.
Late clarification because I wasn't careful and forgot that "NIH" has very negative connotations:
When I say "NIH is sadly a real problem for GNU," what I mean is that NIH can be an actual valid reason for GNU to fork or reinvent something, not that they're guilty for doing so. As in, it's unfortunate that they'd have to do it, but sometimes they have to. (Often it's not "reinvent" at all though, instead merely maintain an upstream compatible fork such as IceCat or Linux-libre.)
The reason is that if a non-GNU project is heavily relied on by GNU, the project might one day decide that they don't exactly agree with GNU anymore, so it's best to have a fork under GNU which can be fully trusted. Sometimes I find this non-trusting stance sad, but it seems to be necessary; just see Mozilla adding DRM to Firefox. :-(
Adobe Flash is an outright offense if you ask me. A distro providing a separate repo for non-free software is one thing, forcing me to run uninspectable code, which is known to have a horrible security record, under my user's privileges, is another thing. As OpenBSD people say, it's a feature that it's missing. :-P
I don't know what problem with media codecs there are. FFmpeg, as free software, implements H.264 just fine, even though it's a patented format. I don't know how exactly the legal aspects of that work, but I'm happy it somehow works, because otherwise I couldn't watch all my [spoiler]Chinese cartoons[/spoiler].
Now WiFi cards are a problem from what I know. You can buy a WiFi dongle with free software drivers though to get around that issue, or replace your laptop's WiFi card with one that has free drivers. I suspect that will be the one major issue with the GNU OS, and the only thing we can do is ask manufacturers of WiFi hardware to be more cooperative.
The other big problem tends to be the BIOS, but GRUB/Linux-libre at least boot just fine on proprietary BIOS, so it's no issue for those who don't care. Those who want to take the further step for software freedom may want to look into LibreBoot: http://www.libreboot.org/
The comic was applied to the situation somewhat liberally. :-)
I guess you could say it's about de-facto standards here, rather than standards. Deb, RPM, pacman, Nix, etc., as well as all the language-specific PMs all solve the broad problem of package management, so one of them could become the de-facto standard and embrace the others, but it ain't gonna happen.
Thanks for the clarification. Further clarification:
I need to refresh my knowledge before I'm sure, but I think that statement regarding dependencies only goes for build-time dependencies. An update to a run-time dependency wouldn't require a rebuild of the dependent.
And the build-time dependencies' up-to-date status is not very important most of the time. "Does it matter whether I used Bash 4.0 or 4.2 to run that ./configure script?" Nope. I'm not sure to what extent this carries over to practice so far; the recent security patches to Bash did cause a total rebuild in Guix. I hope that will change by the time 1.0 is released. Theoretically, you could use the same build-time-dependency packages for years (e.g. a "bash-for-building" package), yet quickly deploy bleeding edge versions to users (proper "bash" package).
Purely functional package management (PFPM) gives us reproducible builds; other package management systems don't. 1/0 = ∞. Therefore PFPM is infinitely better than non-PF PM. ;-P
And my reasons for choosing Guix over Nix would be: fully-free GNU system, doesn't use systemd (no hate, just a preference), uses Scheme/Guile for everything from init system to PM.
(Add possible future Guile/Emacs integration to the mix, and that Guile might enter even more GNU software (e.g. it's in GCC, GDB, and Make already), and we get an interesting picture of a pseudo-Lisp Machine... I'm thrilled, personally.)
You beat me to it. :-)
Guix is not late in that there aren't many purely functional package managers out there. It's the second after Nix if I'm not mistaken, and it doesn't reinvent the purely functional wheel either; it builds on top of existing core parts of Nix. Why not use Nix? Most importantly because it's not GNU; NIH is sadly a real problem for GNU. But Nix also uses C++/Perl and a stand-alone package recipe language; Guix uses Scheme as much as possible. ISTR Guix also has some features that Nix lacks, such as unprivileged package management. Don't quote me on it though; mayhaps it's trivial to add to Nix or has already been done.
Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-)
It's also extremely unlikely that Debian will just give up apt, and RedHad will just give up rpm.
And every programming language platform seems to have its own package manager precisely because of that reason: there is no one package manager on all systems, but a proglang platform wants to offer package management on all systems, so each bake their own implemented in and special-made for the language.
It's a sad state, but that's the world of software for you.
On top of the Nix daemon certainly, though not Nix as a whole, which has its own package recipe language etc.
Cross-post from Reddit to clarify what exactly Guix is:
GNU Guix is a Guile-using Nix-derivative purely functional package manager and at the same time package recipe database. (Shipped in one so the recipe language doesn't need to be frozen for compatibility.) Development of the Guile-based init system DMD is closely tied with it.
Its last few releases include stuff to install a stand-alone GNU/Linux-libre system which might be sanctioned as the GNU Operating System if RMS approves. Since it builds heavily on GNU software like Guile (GNU's official scripting/extension language) for its init system and package manager / deployment tool, prioritizes GNU packages in its database, and remains ostensibly kernel-agnostic with the hopes of running on the Hurd in the future, it can be seen literally as the GNU OS. (GRUB, GCC, Autotools, Glibc, Bash, coreutils, etc. all go without saying.)
(Until approval of the name GNU, the OS simply has the same name as the package manager: Guix.)
And homepage: http://www.gnu.org/software/guix/
It has no syntax (of its own) in that it hijacks s-expression syntax instead. When you want to write Lisp code, you actually write some data structures in the s-expression data format, like when writing some data in JSON or XML. Then a Lisp interpreter or compiler uses an s-expression parser to read that data structure into memory, and operates on that.
Then again, not just every Lisp dialect but even pretty much every implementation has its own s-expression parser with its own extensions to s-expression syntax to make it most convenient to write code in, so there's not a very good decoupling after all. :-P Nevertheless it provides some benefits. Like being able to use something like "paredit" to edit code structurally, and making macro systems somewhat simpler (though hygienic macro systems cannot work with pure s-expression data; it must be annotated with lexical context).
You might find it hard to believe but I love Lisp syntax with all of its parentheses, and am explicitly against, for example, Sweet Expressions (SRFI-110). (Though SRFI-105 is fine.)
By the way another meaning of the word "syntax" actually refers to something within the data structures after the actual concrete syntax has been parsed away. For example when you have a list and its first element is the symbol "if", then that list is a usage of the if syntax. This syntax takes three arguments (further elements of the list): a test, consequent, and alternative. So "syntax" is something like a function here, except it operates during compilation and its arguments are unevaluated sub-structures (roughly, code snippets, though the syntax could interpret them however it wants, like for example how the "lambda" syntax's first argument is a parameter list). That's why we can say "in other languages you can only implement new functions; in Lisp you can also implement new syntax." (In the form of macros.)