cmm

please don't regret writing the post the way you did, I for one enjoy well-written rants

that PR doesn't actually work though -- it finds the Vulkan libraries and has some memory accounting logic, but the bits to actually build a Vulkan llama.cpp runner are not there. I'm not sure why its author deems it ready for inclusion.

(I mean, the missing work should not be much, but it still has to be done)

The instance of enshittification under discussion is lucrative for the (big) retailers in at least two ways: first (obvious), they get to hire less people and in this way increase their margins, since they never promised to pass any savings to the consumer in the first place and also something something supply chain something something inflation; second (slightly less obvious), it is nudging the less impulsive consumers to have their (bi-)weekly groceries delivered so they don't have to go to the store physically at all. Where I live (a dense urban area), supermarkets are getting fewer and either smaller or with the delivery logictics space gradually cannibalizing the in-person shopping space. I can only conclude that sufficiently scaled-up home delivery of groceries is more lucrative for retailers than traditional in-store shopping, probably due to some combination of smaller variety / more standartization, delivery fees etc.

Looking at Nix internals would, over at the Guix land, be more like looking at the Guile compiler, or garbage collector -- all Nix-the-tool implements is the language and the primitive derivation machinery. Could certainly be educational, but neither is nor should be required of anyone _using_ the abstraction in question.

Do you have any more deliberate obtuseness to share, or shall we stop?

> the whole nix internals are just a black box to you.

Yes, and just as well. Modern software is a barely-holding-together tower of abstractions as it is. Do you find yourself looking at the C source of Guile's runtime often? Or Glibc? The Linux kernel? Intel microcode? Aren't you glad you don't have to?

(Nixpkgs, on the other hand, is very accessible and many parts of it make for great reading)

> if you expect of me to promote the virtues of lisp to you then im sorry but thats not gonna happen.

No, I hope (in vain, looks like) that you'll start making some sense and stop using and then desperately defending stupid arguments.

And let me make some further general observations here, while I'm unfortunately procrastinating.

People use software to solve their problems. The way you "sell" (in whatever sense) software to people is by showing them which of their problems it solves (they don't even have to be explicitly aware they have those problems in the first place, BTW) and how.

Nix(OS) is adopted first and foremost because it clearly solves some pressing problems. It allows you to have many development environments that don't stomp on each other, without managing a zoo of containers or VMs. It allows you to specify the operating system (or even just the user environment) you use, over as many machines as you need, deterministically and while ensuring that once you solve a problem it stays solved.

Those are real pain points, and since Nix solves them it would be used by people regardless of those people feel about Nix-the-language, because language appreciation is not the main reason people use it -- pain is.

Some goes for Guix, obviously.

So if your goal (whatever your motivation may be) is to explain to a Nix user how Guix is better, you need to point out something that is relevant to the person you are "selling" to and is fundamentally painful with Nix and painless with Guix. And, well, reaching first thing for "Guile is the official extension language of the GNU Project" does not do your marketing effort any favors.

> another significant project that uses guile.

That looks like a typical academic project that is overwhelmingly likely to die as soon as the grants run out, what am I missing? Where are the users?

> nix is developed in cpp

Who cares?

> its own (poorly documented) dsl to interact with it

Nix documentation is not by any means ideal and is kind of scattered, but calling it "poor" is a blatant misrepresentation.

> guix is developed in guile and you use guile to interact with it > this alone implies that you get far more from just learning guile than nix dsl > if all you want to do is package management

Argument by repetition, wonderful.

> as for a one to one technical comparison, it is just a google search away

That is... not good. And when a commenter pointed out its biases and misleading generalizations, the author invited them to go listen to a stream, lol, nope.

> you keep sloganeering that guile is useless outside of guix.

That's because it is, no need to get so defensive about it. It does not detract from its technical qualities! In any case, the goalpost got moved way far from the original "Guile iS tHe OfFiCiAl eXtEnSiOn LaNgUaGe Of ThE gNu PrOjEcT", wouldn't you say?

> forgive me if i dont take your claim at face value

"Guile is for all practical purposes useless outside the Guix ecosystem" is my null hypothesis here and so far I stand by it. "Proving" that would be proving a negative, so I don't intend to even attempt that. It should, however, be fairly easy to disprove if you have data. Show us how learning Guile (or any Lisp that is not Elisp really -- sad!) is likely to be worthwhile for a "normal person" apart from using it for Guix.

> guix uses standard guile syntax and has the whole guile language available to it.

I feel I'm not getting through here. Let me try again: Guile is base Scheme plus some SRFIs plus some more extensions. None of this is useful outside the Guix bubble, because it is not really used for anything outside that bubble. I suppose pointing at a hundred Texmacs users who picked it up after being exposed to Guix would prove me wrong, but good luck with that.

> maybe you invested too much time learning nix

Maybe armchair psychoanalysis is extremely bad form. Note that I'm not trying to argue against Guix (or Guile, or GNU, or whatever) -- for all I know Guix is just great, and I know Guile is great (shall I rephrase and repeat this disclaimer again until it "clicks"?). I just tend to be triggered by idiotic sloganeering argumentation, especially when it is repeatedly reflexively employed as if it can substitute for a honest technical comparison.

> Having macros does not equal having a DSL.

Any set of non-trivial non-standard macros is a DSL, by definition. You have to know what a macro does and what it is for in order to even understand which of its similar-looking keyword or positional arguments are evaluated and which are not, how they relate to each other, etc, etc. I really don't see what you are arguing about here, or to what end.

And even more than that: I think Guile specifically would long have been abandoned and forgotten about if not for Guix.

> DSL implemented by Guix? Whatever do you mean?

From what I've seen (which matches my expectations going in), Guix relies on macros heavily enough to be considered a DSL on top of Guile (as opposed to "library" or "framework"). I could be wrong, of course.

> you didn't even answer my question about Nix.

Your question was basically "is this DSL generally useful outside the domain it's been designed for?", so I thought it was rhetorical. That said, the domain of building, configuring and packaging software is not exactly tiny and is only getting bigger as time goes on (which is more bad than good in itself, but beside the point)!

How useful is the DSL implemented by Guix outside Guix itself? What's the comparative mental footprint of that vs. base Guile? Things get interesting when you think them through honestly and avoid stale slogans.

It is at least used outside of the GNU Project...

It is, but there already are other choices that are not worse and that are more established

Oh boy.

> Guile is also the default extension language for the GNU project.

AFAIK Guix is the only project that uses Guile and has any actual users (I'm not counting Shepherd because outside GuixSD it is nothing). Guile is like 30 years old, and has been envisioned as "the default extension language for the GNU project" all that time (I was an active contributor for a while, so I should know). Guile is not even used by Emacs; Guile extensibility support in GDB is not even commonly built by distros. Guile is a nice and very competent Scheme implementation and I'd love for it to be useful outside Guix, but that's just not the case, and repeating that slogan won't change it. Seriously, just stop.

> It is the old freedom and responsibility problem

No, it is not. Software development is a social and technical field, not a branch of philosophy.

I'm not trying to "debate" anything here.

I do note that those Guix people that are feeling competitive towards Nix for whatever reason tend to over-rely on two arguments that just do not work too well when examined closely.

The first is "Nix is obscure the way Guile is not". I would argue both are equally obscure and neither is obscure enough for its quality or UX to suffer for it. And does expertise in Guile (base Scheme is trivial) carry over anywhere interesting?

The second is "Macros!", where the implied idea is that unrestricted syntactic extensibility is Good. Well, I like Lisp (more partial to CL then Scheme, but who cares at this resolution), and I find unrestricted syntactic extensibility to be more of a hazard than a benefit; plus the expressivity of a non-strict FP language really gets you close enough for practical purposes.

> Any programming language can delay evaluation by wrapping values in thunks where that makes sense

Indeed. I was simply asking whether the macros used for programming Guix are lazy, how is that baffling?

I know quite well what Guile and Scheme are; I was asking about the specific DSL/library/whatever combo that Guix is programmed in. The code snippets on the page which this thread is about, for example, mostly use macros that seem to mimic their Nix equivalents very closely but are marginally more verbose. I would very much like to see a compelling example where the fact that Guile has macros makes a practical difference.

(Note that Nix's laziness is not an unalloyed good either, for example it is notoriously difficult to debug. But let's limit ourselves to pure expressiveness for now)

NixOS can be validly viewed as a very fancy Systemd configuration toolkit. If you think about it, ultimately an instance of a modern general-purpose OS is structured as a set of services which are described for and orchestrated by, well, something. In the case of NixOS (not Nix in general!) that something is Systemd (which also happens to be used by all other major Linux distros); in the case of GuixSD that something is GNU Shepherd (which also happens to be used by GNU Hurd)

I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at?

No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?

correct

er, s/HISTIGNORE/HISTCONTROL/ above

it's not serious for most people I guess, but if you rely on bash's HISTIGNORE and don't disable bash's built-in history mechanism when you adopt Atuin, then this is as serious as you are paranoid

there's this little gotcha you might want to be aware of: https://github.com/ellie/atuin/issues/752#issuecomment-14518...

just to register that I didn't know about scrcpy or gnirehtet, have no obvious need of either, but they are impressively neat!

I wonder what's worse: not supplying open firmware at all, or doing it at the S76 level. You get laptops that don't suspend as shipped, you still cannot remove of disable Intel ME, but yay another desktop shell!

> I guess that one full-time person is just all that's needed?

Emphatically not. I mean, just look at the bug tracker. Or how about this data point: my Lemur Pro (lemp11) could not suspend at all when shipped -- the model started shipping in Summer IIRC, but the relevant workaround/fix was only finally released in November. So yeah, the Coreboot/firmware field is very understaffed.

Things some people (ahem) learn only _after_ investing in System76 hardware: most of the premium goes not toward Coreboot development (S76 employs all of one full-time firmware guy) but rather toward a largely-pointless rewrite of Linux desktop in Rust. Welp, lesson learned

Jumped to KeePassXC (for Linux) + KeePassDX (for Android) after the latest LP fiasco, syncing the databse with Syncthing everywhere it's needed.

It's... fine, actually! And it all being open-source and using an open/documented/versioned database format decreases risks, also the browser extension is perfectly serviceable (certainly not worse than LP's abortion).

In short, I have absolutely no idea why I haven't made the jump long ago.

dockerfiles (or even better but less popular, {default,shell,flake}.nix) are code that can be tracked in a repository and reasoned about, "stuff installed locally" isn't.