Hacker News new | ask | show | jobs
by chungy 801 days ago
It's pretty well documented with a pretty simple configuration language (if you already use a bourne shell (and you probably do), you already know how GRUB's syntax works).

I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.

4 comments

I just want to boot my system and get on with my life. Grub is exactly the sort of thing I aggressively don't want to spend time on.
The point is, GRUB is unnecessary complexity for probably 99.9% of all systems that boot Linux and maybe one other OS.
... can you really fault software that has "Grand" and "Unified" right there in its name for trying to be just that? The number of systems supported by GRUB is really impressive, the number of special-sauce features supported (filesystems, RAID levels, snapshots, etc.) downright staggering. And if you don't like it, there's plenty of alternative, simpler options with a narrowere focus. I use systemd-boot on most non-Debian (which supports A LOT of other platforms, mind you) x86 EFI boxen of mine.

GRUB might be an unnecessary complexity for a number of use cases, but it's a solution that strives towards being universal (which is also a goal of Debian). I think it comes rather close, and I am happy it exists. Learning you way around it for an hour or two will yield payoffs down the road.

I think it's fair to wonder, if the job is that varied, then was it ever the correct design approach in the first place to presume to ever be able to predict and handle the unpredictable infinite permutations?

This is init vs systemd. 50 years ago, they could not predict all the crazy infinite things a unix system would want to do. And yet they made a system that handled it all possible needs by knowing enough to avoid making assumptions about the infinite other end users or the infinite future. They knew the most important thing which was not to pretend to know the unknowable.

They made a simple base framework and a toolbox, and everyone was able to serve their own crazy individual needs, still 50 years later.

And it still works. Systemd did not need to come along to fix some deficiency, it just came along anyway because for every wise engineer there are 10 clever engineers, and after 50 years of rapid growth the population of linux admins is less than 1% people that know how to reject a shiny new bad idea and 99% kids who do not. Plus of course a few huge businesses who just want that kind of appliance system for their own business reasons and don't care one turd about engineering or empowering the end user or anything like that outside of their own walls.

It's at least fair to look at grub2 and wonder if it's not just a huge self-inflicted wound from trying to deny the undeniable.

Maybe it should be something more like a library of smaller scope scripts that the end user uses a bit more manually.

The common cases can still be handled automatically so no change for 99%, the uncommon but known cases the user can configure their system to use something from the library for that situation, and totally new unknown situations are simpler to handle by writing a new script or adapting an existing one, because the framework is fewer layers and less indirect.

"And it still works. Systemd did not need to come along to fix some deficiency, it just came along anyway because for every wise engineer there are 10 clever engineers, and after 50 years of rapid growth the population of linux admins is less than 1% people that know how to reject a shiny new bad idea and 99% kids who do not. Plus of course a few huge businesses who just want that kind of appliance system for their own business reasons and don't care one turd about engineering or empowering the end user or anything like that outside of their own walls."

If you want to you can always run something like Devuan. You don't have to shit on other projects or people to run the software that you want.

Sure if I want, I can indeed run anything at all, including that. What's that got to do with anything?

The observation of majority linux and systemd and unix design principles remains a fact regardless what I happen to run. Even if the only thing I happen to run is freebsd which has no such problem. "you can run ..." is both true and irrelevant, doesn't change a thing.

Another thing I can do if I want to, is observe something and describe what I see, even if someone like you doesn't agree, and has no better way to handle that than to suggest the speaker should do something else besides speak their mind rather than actually argue or counter any of the points. (Everyone including me already knows the sales pitch for systemd, it's unlikely you have any argument that I don't already know, this is very much a religious issue at this point, as in there is no actual changing of anyone's minds on either side)

You like systemd and don't like hearing blasphemy criticizing it? Tough shit!

The complexity of GRUB isn't justified by the number of systems it has to support. The number of supported systems is also not the reason why GRUB is so complex. The cause of complexity is poor design choices, if you can even call it that, when it comes to configuration and defaults.

It doesn't matter that better options exist. GRUB is the subject of this discussion. If it were about systemd-boot, then it would've been legitimate to complain about it or to praise it. But, it's not the subject.

But, since you mentioned "other options"... they are both the indication of the larger problem: Linux boot process is poorly designed and that's why many independent teams tried to replace it to variable degree of success. GRUB isn't the only poorly designed piece of this process. And they work to obscure and make even less accessible the subject of system booting for the wider audience, creating a feedback loop where the only few people brave enough to dive in and try to understand it are the people who started way back and usually have very distorted ideas about how their code is used by the layers built on top of it.

The whole of the booting process didn't need to be this complex: it could have fewer stages, fewer utilities that are responsible for different stages, fewer possible boot scenarios, better defined order of device initialization... the list goes on. GRUB is only a part of the larger problem, albeit it's a big part.

Configuration in Bourne Shell is already a bad idea, documented or not. Add on top of it is that there isn't really a configuration... you edit some files (multiple!) then you need to know to run some other script, that on different distribution of Linux will be called differently (if it at all exists) to generate this configuration from another configuration. And the added bonus is that this script will also sometimes run when upgrading some (typically completely unrelated) packages, and if you were so naive as to try and edit the configuration w/o running the script, your changes will be undone without warning.

Configurations are supposed to use a languages that is just powerful enough to express it. The more declarative the better. Shell is a very bad configuration language because it allows to do way too much and is very forgiving of errors.

Now, add to this that GRUB installation is trying to do configuration too... and if you are doing stuff like creating VM images or similar, where you have to install packages in an environment that's not a real physical computer with a bunch of periphery attached, you will run into all sorts of problems (because for some reason GRUB wants to have a PTY and a bunch of other devices / pseudo-filesystems that it has no business sticking its fingers into) and if you aren't present at the keyboard during package upgrade / install you might not even notice that GRUB has failed to install / install correctly.

> has a complete manual that explains it all.

So does quantum field theory, which, as a matter of fact, has many manuals.

Doesn't mean either QFT or grub are understandable or even usable by mere mortals.

Difference being than in the case of grub, given what is does, the complexity and opacity of the manual, config languages and diagnostics message is completely unnecessary.