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.
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?
This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default.
Guix package definitions declare other package values as inputs, and evaluation of these inputs is in fact delayed.
Verbosity: in Guix we don't generally run shell snippets as part of a build; the build phases are compiled into a Guile builder script, so in the absence of helpful abstractions build phases do not generally have the conciseness of shell scripts. On the other hand abstractions are easily fashioned, so some things are more concise and clearer than the shell equivalent.
> This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default.
At least in Haskell laziness increases composability.
I can't think of any examples in Nix, but maybe it's the same reason?
One use case for lazy evaluation in NixOS is that you can reference other parts of the system configuration, possibly even defined in other modules, as long as you don't produce cyclic references. For example, I use stuff like the following often to avoid accidentally specifying a username that does not exist:
Another use case is being able to keep everything as plain values. For example, I can run `import <nixpkgs> { }` without evaluating all of `nixpkgs`. You can accomplish that in a language with eager evaluation by wrapping values in functions but I prefer the everything-is-a-value way.
Of course, this is just a matter of preference. Like most Guix vs. Nix aspects, as far as I can tell.
The "service" mechanism in Guix System is designed in part as a reaction against those the NixOS module design you're describing: I think the ambient authority, free-style extension mechanism of NixOS modules makes it hard to reason about it (any module can change the config of any other module), and it makes it easy to shoot oneself in the foot (with infinite recursion in particular, as you write).
In Guix System, services extend one another, forming a directed acyclic graph of extensions. When a service extends another service, that connection is explicitly declared, there's no surprise.
Nix bombs out when it runs into a cyclic reference, so at least infinite recursion doesn't hang without any output. Likewise, it also rejects multiple definitions for a value (though to be fair some values like attribute sets are mergeable and it can be hard to wrap one's head around that).
The service model in Guix looks pretty neat! I've long been thinking it would be nice to have a configuration system for NixOS that uses isolated components with a defined (type-safe) interface. The current modules are kind of that, except it all gets squashed down into a single nested attribute set, so it's not really isolated and (understandably) can be confusing. How does Guix System handle multiple services competing for the same global resource (port allocation, file in /etc, ...)?
There's nothing to prevent multiple services from using the same port at this stage. For files in /etc, the "etc" service should detect that the same file appears more than once and error out--that is, it won't instantiate a "broken" system.
There are other things that are detected statically and prevent you from instantiating a broken system: missing modules in the initrd, invalid file system label/UUID, references to non-existent Shepherd services, etc. All this is possible because there are well-defined data types and semantics for the different components of the system.
Fair enough, NixOS doesn't completely solve this either (other than the aforementioned possibility to reference other parts of the system config and some integrity checks). I was just wondering if that's an area where more static checks are possible.
That sounds pretty good though, thanks! Maybe I'll try out Guix System some day.
It's baffling because the question is too vague to produce a meaningful answer. What does it mean for macros in Guix to be lazy? The expansion of some macros may be (and is) lazy. For some things lazy evaluation is sensible (e.g. for declaring dependencies because you don't necessarily want to go evaluate the whole graph whenever you evaluate a single package value), for others it is not.
One thing that's often overlooked with Nix (the language) is that it does not let you define new data types. For example, there's no "package" type in Nix and Nixpkgs; instead there are only functions that are passed "attribute sets" (key/value dictionaries).
That Nix can't tell what's a package and what's not is a hindrance for its user interface (e.g., it's hard to look up packages by name/version or to iterate over them) and for packagers (e.g., easy to end up with package definitions that don't follow the informal "schema").
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)
Well I mean look at the docs. To each their own but I find Guile much more palatable than Nix. Moreover, I would rather spend time learning Guile than an obscure language like Nix. But for you Nix is a perfect DSL so i think we would probably be bashing our heads against the wall debating which is better.
As regards macros, Guile allows you to write your own macros in a pretty straight forward way that is just not the case in Nix
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.
Besider Guix, Guile is also the default extension language for the GNU project. Moreover by learning Guile you learn a lisp which some people find quite enlightening. What do you gain from learning Nix, asside from Nix?
Moreover, "macros are good" in the sense that they are powerful and grant the user freedom to construct software in ways that are just not possible with languages that try to herd their users into a specific mode of behavioir. It is the old freedom and responsibility problem. Again, I believe it is a matter of choice and personal preference
> 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.
Oh boy, you didn't even answer my question about Nix. I guess you can't in a way that doesn't concede to my point - guile is definitely not obscure in the sense that nix is.
For what its worth, here is at least one recent funded project that is using Guile:
You also seem to think that I am some kind of Guix/Guile evangelist. No (I actually also prefer CL). I just happen to think that Guix is a better solution than Nix and that it uses a much better language.
> No, it is not. Software development is a social and technical field, not a branch of philosophy.
And I guess you get to say what's good and bad in field? Lol
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.
Anyway, most people that I've come across who've used both nix and guix say that the learning curve for the latter is much less. HOWEVER, they usually stayed with nix because it had easier access to non-gnu stuff
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.
Having macros does not equal having a DSL. In fact for me a big benefit of Guix is precisely that it doesn't use a DSL, but uses a well established and maleable language like Guile (Scheme)
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.
> Any set of non-trivial non-standard macros is a DSL, by definition.
thats not entirely correct but even with that definition you should think about the non-standard part. guix uses standard guile syntax and has the whole guile language available to it.
anyway i think you are trying way too hard to equate nix and guile in a way thats simply doesnt click with me. maybe you invested too much time learning nix to concede that there is something better and simpler out there
> 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.
> 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.
"idiotic sloganeering argumentation"?
> honest technical comparison
let me spell it out for you in another way
nix is developed in cpp (which itself is a huge collection of dsls) and you use its own (poorly documented) dsl to interact with it
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
>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.
you keep sloganeering that guile is useless outside of guix. i find it pretty funny how willing you are to twist the picture of reality in order for it to fit your world view. i already pointed you to another significant project that uses guile. here is the part in their documentaion spelling out their choice for guile: https://spritely.institute/static/papers/spritely-core.html#...
as for texmacs, i dont know where you are pulling your numbers from, but i for one used texmacs for writing papers before even considering taking on software development professionally. so please don't be triggered if i dont take your claim at face value
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.
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.
if you know nix DSL but dont know cpp (whatever it means to know cpp) then the whole nix internals are just a black box to you. this is simply not the case with guix. if you cant see the benefit of guix/guile relationship here then there is not much more i can say to you
anyway as i said at the start this whole thing is just heads banging against a wall. i have no problems with you holding your views. it just happens that i disagree with them. if you expect of me to promote the virtues of lisp to you then im sorry but thats not gonna happen. you can do your own discovery. if you dont know then you dont know :)
> 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.
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?
regardless of who is right, the fervent opinions and bless-your-hearts in this thread tell me that I'm better off using neither. Purity tests are fucking dumb, escalating goalposts are fucking dumb, worrying about how others compute is fucking dumb. We're all nerds here, there's no need for this level of emotional investment into other people's opinions..
You're absolutely right, but if that makes you not try something you might be missing out. For example, Rust is probably my favorite programming language (definitely my favorite native-code-producing one) even though I find some of the community extremely off-putting.
> What do you gain from learning Nix, asside from Nix?
Nix is a small and approachable lazy pure-functional language. You can learn a fair bit of functional programming by reading nixpkgs, which is frequently recommended even if you never use it in the real world.
> by learning Guile you learn a lisp which some people find quite enlightening.
By learning nix you learn a FP language which some people find quite enlightening.
Personally I can't find any software which I would want to contribute to or extend which uses guile (except GDB which can also be extended with python), so the "you ain't gonna need it" argument holds for guix too.
It's just such an odd argument for a relatively minor difference between the two ecosystems.
> Moreover by learning Guile you learn a lisp which some people find quite enlightening. What do you gain from learning Nix, asside from Nix?
This thread is baffling. cmm is asking a fairly simple question. He's not trying to make a point. If people don't have the answer, they need not respond! There are so many responses to him - none answering his question.
If you're part of the 99% who know little of Lisp languages, he is correct. There's not much of a difference between 0.001% and 0.01%, when you're working in numbers like 20+%.
While Guix is the Guileverse's biggest and most successful project, a lot of the compiler/VM work that happens in Guile happens pretty independently because Andy Wingo just likes to hack on Guile. Guile would still be here, but the community would be smaller.
> i think any person with a cs education would at least recognise lisp syntax
The discussion wasn't on Lisp, but Guile. They may recognize Lisp syntax, but the majority will not have heard of Guile (let alone Scheme).
And you are referring to recognizing Lisp syntax, which is not what I was referring to when I said "know little of Lisp languages". Sure - most know it exists and has a lot of parentheses.
BTW, many if not most programmers don't have a CS education. And many who do don't encounter Lisp in their curriculum. I just checked my undergrad's required courses - the PL course has Java, SML, Prolog and Python - no Lisp. Anecdotally, in all the teams I've worked in for my career, there was only one team where people had an idea of Lisp. In the other teams, they didn't even know that it's the language with a lot of parentheses (as in they'd look at Lisp code and have no idea which language it was).
Can you tell me if my understanding of this issue is correct?
Let's say I run a command where I've pasted in a credential from my password manager: ` some-cli login username my-secret-password` (note space at beginning)
Normally this would prevent the command from getting saved in any meaningful way in my bash history, so that if I later run a malicious script, it can't collect secrets from my bash history.
With the bug here, it sounds like atuin would prevent that entry from being stored in the sqlite store, but it would still be in my shell history?
If so, this is really significant, and would stop me from using Atuin. Not letting users know about this behaviour is incredibly negligent, and honestly erodes my trust in Atuin to consider user security in general.
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
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
Things I learned after buying one of their machines: I now have a nice usable laptop that has great hardware compatibility with every Linux distro I've tried. They can spend the money however they like, if you ask me.
I like S76's additions to GNOME, and I'm happy to see them moving to a place where they'll no longer be stuck on GNOME's whims and wishes.
They've been positioning themselves to have a more put together and unified stack as time goes on, and this is just one part. On top of that, it seems to me that a DE is a very good place to get memory safety, so I'm glad to see someone moving that direction.
How many people do you realistically need for working on Coreboot/firmware stuff? I guess that one full-time person is just all that's needed?
And I bet that many System76 users don't actually care about all of this either. Some do, but I'm not so sure the majority do. It's certainly not something that actually sells significant amount of machines in the mainstream market. Having a usable functional desktop does.
> 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.
I certainly care a lot about having a Linux desktop that works well with the hardware I bought for it, and has a company with a vested interest in keeping it that way. I admire how Apple controls their entire stack and is able to do interesting, smooth integrations with all of their offerings.
A year ago I asked on my local Linux mailing list for some hardware recommendations, and I mentioned I would like to buy something w/Linux pre-installed. A lot of people got upset with that idea.
I am done installing OSes. I never learned anything from it, and I buy a system to use it, not to configure it.
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!
Are these S76 level bugs, or issues from their suppliers?
The leap in scale from using Clevo designs with S76 software to designing your own hardware is massive.
They worked with HP. But if you are expecting Apple MacBook Pro level devices in the Linux flavour, I think it's going to take a few more years of buying what they are selling to achieve that scale.
Every vendor that seems to say they care about coreboot implementation seems to just be doing it to capture the eyes of people like us who actually care about it. But then as you stated, they'd rather spend their time/money to write their own DE than give a shit about open firmware.
If I was going to buy a coreboot laptop it would likely be a higher end Chromebook that mrchromebox has a hack for.
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.
I don't see how Nix is better than Docker as they serve different purposes. While I agree using containers helps aid in automating build environments, you can also checkin shell scripts and Ansible roles into repos as well. I understand the criticism and hopefully people aren't going to be so thin-skinned to take offense, but at the same time if it works then it works.
Nix and Docker share the same purpose in this context: declaring the dependencies needed for this environment. This can include shell scripts, system-level dependencies etc. If anything I would say Nix would be better here (logical middleground in filesystem separation between having access only to whats in the container vs having to juggle system-level dependency versions for the entire system), while also having better version pinning.
> I don't see how Nix is better than Docker as they serve different purposes
Nix can build many things, among them whole operating systems on the metal, virtual machine images, and container images (including Docker images).
When you use Nix to generate Docker images and deploy them in production using Docker, Nix is not functioning as an alternative to Docker, but your *.nix file is functioning as an alternative to your Dockerfile.
Defining container images in terms of Nixpkgs rather than via a Dockerfile, and assembling it via Nix rathet than `docker build` does have some advantages.
1. It moves you from mere repeatability in the direction of true reproducibility— it makes your outcomes more predictable and reliable
2. Having the benefit of knowledge of the actual dependencies on the system down to the package (or subpackage) level, Nix knows how to generate minimal images when Docker can't.
Plus there's the prospect of reuse, I guess; an environment you've defined in Nix for building Docker containers is easy to install and debug in other environments, without the extra complexity of Docker and filesystems exports/imports, port forwarding, etc. That can be nice, to be able to easily separate out what you're troubleshooting or learning as you're creating or modifying the image's environment.
But yeah that doesn't mean that pairing Dockerfiles with imperative or convergent configutation management or provisioning tools can't also sometimes work well enough in a given situation.
well, let's see: bog-standard cgi, overbearing music that sounds like music in any other big recent(ish) "fantasy" production, stilted dialogue laced with awkward exposition, nobody among the cast seems to know how to fucking act (except the guy playing John Dee, he's excellent though also exactly the same as everywhere else, so he just steals every scene he's in), that stupid raven, shall I go on.
still watchable, weirdly enough, but just not good.
The guy playing John Dee is David Thewlis, one of the best cinema actors of all time.
Matthew the Raven is not well handled (he's not well-handled in the book either!), and his dialog is unearned and superficial. "Dreams don't die" is the Goonies wishing well speech repurposed. I groaned audibly.
Episodes 2-4 were interesting as a fan of the books (though not of Preludes & Nocturnes, the weak first book), but if I weren't one of those, I'd have been happier skipping them. Episode 5 is good; episode 6 is unimpeachable.
> The guy playing John Dee is David Thewlis, one of the best cinema actors of all time.
He's Lupin in Harry Potters, for a quick reference (for others). I take it you've seen The Landscapers? Exceptional performances from both Thewlis and Olivia Colman. I came to Sandman as an adult, and I was not a comic reader as a child. Maybe that's why I love it, not having the fluency to recognize the uneven writing and things you listed as weakness? I remember being absolutely floored when I read the first few, and also being convinced it could never be successfully adapted. I thought there were so many nuances, so many allusions to myths and folklore woven into Gaiman's writing that a film adaptation would absolutely butcher the original material by its inability to render all the shades; (e.g. the Cain and Abel sub-story is played for laughs and misses the sinister undercurrent - it is after all a story about a man murdering his kin and lying about it to God).
So far I'm pleasantly surprised by the series. I thought the casting and costuming of Morpheus dead-on. In the book he's drawn as a tall and pale Gothic priest. I appreciate that the production design tried to keep close to the visual framing in the book, I look at each frame and I could see the original in the derivative.
I'm worried that the complexities of the books and its branching anthologies, after the world-building phase is done, will be reduced to stupid modern clichés, e.g. "when dream dies humanity would die" and similar treacle. For example how are you going to make sense of the story where Dream meets his friends every 100 years for a drink at an eternal tavern, I forget who was there, Newton and Pascal? That's not an episode to view but a novella or in its best form, a 20-page comic.
The raven feels like a studio note. Hey, let's get a grating voice^ to do narration and exposition cleanup, and it can completely counteract the dark moody theme for people who don't like that!
^ No offense to the great Patton Oswald, but the audio is boosted to make the choice seem even worse. He's supposed to be a voice for the Sandman, but instead he's a bullhorn.
I have never read the comic/graphic novel, so - was coming into this blind.
It was going well, until Mathew opened his mouth and spoke - and all I could think of was... "Happy!"... Another graphic novel adaptation where Patton Oswald did voice acting... But that character worked with his voice, this... does not.
Not to mention the lead doesn't have the chops to carry this thing through. In casting him, they went for surface (looks) rather than substance. To paraphrase the great Malcolm Tucker: He comes across like he should still be at school with his head down a fucking toilet.
