Live data from Hacker News

Introducing GNU Guix

lists.gnu.org

81–90 of 113 posts

Re: Introducing GNU Guix

#81

Earlier quoted context omitted.

Why utilize scheme? If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening. Why not scheme? It's liberally licensed and already has mind-share. It's a simple, no fuzz language with little obfuscating magic and great expressive power. It allows you to build your solutions as bare-bones as you like or go on full…

Might as well use python because of greater?? adoption and ease of use?

Packages are mostly just declarations of how you want a package to be built/installed, but sometimes they require additional logic or computation. Using python would require a separate file format to put definitions into (e.g, YAML), and those definitions would need a rigid schema and versioning system. Some existing package managers take this approach, but what happens when you need a feature that doesn't exist in the declarative schema? You would need to extend the YAML format and bump the version numbers to allow your new features.

On the other hand, a LISP does not need a distinction between a declarative format and the computation language itself - it does both in a consistent syntax. (Homoiconicity is the term). It makes it much simpler to mix your declarations and computations, alleviating much of the need for a rigid specification on package definitions.

If you look at places where the former system is used, you'll find they usually age pretty quickly - or have many version increments because the original design omitted features people wanted in their package definitions. In effect, this leads to standards proliferation, because people invent new systems when the existing ones don't do what they need. Rather than trying to second guess the features people might need, it can be easier to just give them the ability to add them when they want.

A recent example of the former system is this project from GNOME: https://live.gnome.org/BuilDj. If you look at what it's trying to do, it really just wants to reinvent makefiles in YAML. A clear example of NIH, which will fail because as soon as someone needs to do something which their YAML schema doesn't support, it's a useless tool.

Re: Introducing GNU Guix

#82
post #7

Debian's dpkg and apt are both GPL2+. What's the reason they are reinventing the wheel here? Is there some kind of licence incompatibility that the GNU project cares about? Is there some kind of major architectural difference? Why is it important enough to fragment Free Software developers over? I feel that this should be answered in an FAQ, but I can't find the answer anywhere.

Those things are never going to be adopted by Fedora, Arch, Gentoo, or any other non-Debian based distro. That is reason enough not to use it.

Perhaps it doesnt matter, if this provides a large enough software base, then fedora, arch, gentoo etc would perhaps just write a guix->(dpkg|rpm|...) converter to keep their distribution up to date. Not sure if it would be possible but moving work upstream where more detailed and in-depth knowledge is available might be a good thing.

Re: Introducing GNU Guix

#83

Earlier quoted context omitted.

Why? Because you predict it won't meet your definition of popularity? Once upon a time, Arch and Gentoo were dismissed in exactly this way.

Arch and Gentoo are still tiny fractions of the linux install base (which is itself a tiny fraction of users), and are mostly irrelevant.

Irrelevant for what, to whom? Everything is a tiny fraction of something -- are you saying that value is purely a function of popularity?

Re: Introducing GNU Guix

#84

Earlier quoted context omitted.

Usually when there is no clear answer to this in a FOSS project, I think it's safe to assume the answer is ego.

While you're not necessarily wrong, "ego" gives off a pretty negative vibe. I would say it's quite often personal dissatisfaction of the status quo. I support what they are doing. Wheels sometimes get better when they are reinvented.

I'm not one to declare other people's motivation, but it strikes me as very odd that there isn't a "So, here's what's irreparably wrong with dpkg/apt and rpm/yum".

Re: Introducing GNU Guix

#86
post #78
post #72

Earlier quoted context omitted.

Until they have their own gkernel.

GNU Hurd?

Ah, I was unnecessarily flippant; stopped paying much attention to it in the 90s.

https://en.wikipedia.org/wiki/GNU_Hurd#GNU_distributions_run...

So what would be a compelling technical or business reason to use this, either now or when they get to wherever they're going?

I suppose it would be great for study.

Re: Introducing GNU Guix

#87
post #48

Earlier quoted context omitted.

You are going about it wrong, you need to talk to the audience. Try this phrasing instead: "Use is three times as performant as utilize."

But utilize doesn't do joins.

That's because utilize is web scale.

Re: Introducing GNU Guix

#88

The Linux community needed this around 15 years ago when Windows 98 came out. Now we've got .deb and .rpm which do the job perfectly well. It's even better nowadays, as well, since their existence is effectively hidden from the user thanks to package managers. Too little, way too late.

I don't think package management is a solved problem. Most distributions fail at the simple task of installing multiple versions of the same package alongside each other. Also, lackluster dependency management (you install library X, it wants to install mail server Y and database Z). There are many approaches that one would mistake as being "reinventing the wheel": 1. FreeBSD ports system is barebones, but incredibly…

"you install library X, it wants to install mail server Y and database Z)"

Almost exactly what happened when I installed nmh. Wasn't at all obvious from the dependency list that I'd get qmail, didn't pay attention to the warning prompt and said Y, ...

Bonus, I have a bunch of new system accounts in my Display Manager's login screen. Bleah. Fortunately my scorched-earth reinstall is coming up, so I just leave them there to make it easier to hate what happened.

Re: Introducing GNU Guix

#89
post #61
post #7

Debian's dpkg and apt are both GPL2+. What's the reason they are reinventing the wheel here? Is there some kind of licence incompatibility that the GNU project cares about? Is there some kind of major architectural difference? Why is it important enough to fragment Free Software developers over? I feel that this should be answered in an FAQ, but I can't find the answer anywhere.

My guess is so they can make it very easy to install only free software.

This system works just as well for free software as for non-free. Downloading a binary blob from somewhere would be easy, just a few lines of code in the package description file.

Re: Introducing GNU Guix

#90

Earlier quoted context omitted.

Why utilize scheme? If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening. Why not scheme? It's liberally licensed and already has mind-share. It's a simple, no fuzz language with little obfuscating magic and great expressive power. It allows you to build your solutions as bare-bones as you like or go on full…

You break the idea of a declarative package by doing this you can have side effects that modify or mess with anything. This means I cannot update a package reliably when it's updated because it may or may not change something.

Homebrew packages are Ruby files, and in practice this doesn't seem to be a problem.
Post reply on HN