I didn’t mean the Kernel but more the development community, because it is part of systemd and installed by default…
All(most) the points you mentioned are non-points from a bootloaders p.o.v. because those are the responsibility of your kernel+initrd.
Point-by-point response:
no automation for multibooting Linux distros: False
The entries made by the other distro’s are all automatically used in it’s menu.
no support for booting iso files from disk: True
This could be seen as a lack of feature, but this is not used widely and even with Grub it needs manual configuration.
no support for full disk encryption: Non-Argument
This is not the responsibility of your bootloader, but more of your kernel+initrd combo.
no support for legacy boot: True
This bootloader is for x64 UEFI only, which most modern desktop machines are nowerdays.
no theming: True / False
This is not a big deal for just being able to boot, even the default UEFI boot menu is just text…
If you meant boot animation then it is False because that’s handled outside the bootloader.
no automation for booting into btrfs snapshots: False
This is not the responsibility of your bootloader, but more of your kernel+initrd combo.
You could make a special entry whos only purpose and functionality is to select which snapshot to use by the other boot entry with a nice menu etc.
In short again: Non-Argument
no rescue mode: False
This is just a matter of an extra kernel option, which can be provided by a separate menu entry. Grub does this also…
And finaly “Grub is the most common bootloader for a reason.” that reason is: It has been used in the past because there were no other alternatives yet…
If you were to follow that same argument then we would all be using the older system managers instead of SystemD nowerdays, which has proven to be more and more useful and advanced in respect to SysV/etc, hence why most distros now use it as their default init process…
Don’t be shy and just embrace SystemD you will learn to it once you learn what/how it can do things more effectively.
A good alternative seems to be rEFInd, but i have not used that yet.
ANYHOW, this is all OFFTOPIC so lets drop this sub-topic…
So you have to manage the bootloader entries from all the distros you install. I don’t see that as automation. Also, even with a single boot, distros like manjaro that have multiple and changing kernel filenames require manual fiddling. There is sdboot-manage written by @dalto that can manage this. But my point is that from distro packagers perspective systemd-boot is actually quite a lot of hassle. You have to implement many things at distro level that you would get from upstream with grub. Having written systemd-boot support for manjaro-architect, I have some experience with this.
But it’s awesome and grub does it.
Grub supports storing kernel and initrd on encrypted partition. Systemd-boot does not. Still I conceed that it is not a major win for grub, because grub sucks at it, and it’s not that worthwhile anyway.
I contest this. Systemd-boot does not have automation for this, grub does. Providing kernel parameters is definately bootloaders job, and booting into btrfs snapshots is done by custom kernel parameters. Either you know something that I don’t, or you have misunderstood the point I was making.
With grub, I can very easily at boot time choose a snapshot that I boot into, with snapshots having been automatically generated on every pacman action and every boot. You can do special entries for this with systemd-boot, but my point was that grub does this automatically.
It seems to me that we are talking about different things, which is probably caused by me using a misleading term.
I have. It is awesome, I recommend trying it.
I don’t this systemd-boot is a bad bootloader, but from distro maintenance perspective, it ends up being a lot of hassle despite (or because) of its inherent simplicity. We used to have isos with syslinux+systemd-boot for bootloader to support both legacy and uefi systems. But we switched to grub, so that we could use the same bootloader for both options. Systemd-boot is simple, grub is feature rich. Both have their uses.
I love systemd-boot and use it whenever practical. However, one place where grub is definitely easier is managing a multi-boot system. There are a few reasons for this:
Since systemd-boot keeps all the kernels in the efi partition, you may need a larger efi partition than most people have. This isn’t a big deal if you recognize it upfront, but it can be a pain if you have a small partition such as the one Windows creates by default. Resizing the efi partition is often non-trivial. For example, I use systemd-boot to boot four Linux distros and the used space in my efi partition is currently 768MB. I suspect not many people have an efi partition that large. This has become a bigger issue since more distros are keeping multiple kernels installed.
Similarly, kernel collision is problem that needs to be worked around. For example, booting two versions of Manjaro or multiple Arch-based distros requires some acrobatics to get everything working where in grub it “just works”.
From my perspective, grub is a good solution when you want something “easy” and systemd-boot is better if you prefer “simple”. Personally, I prefer simple over easy.
No, each distro manages its own entry separatly from the other distros…
When it comes to sdboot-manage, IMHO that is buggy as hell and i prefer to write my own hooks…
And it’s no hassle at all from a distro pov. compared to what else they need to customize, a small text file can hardly be labeled as such…
Wrong thats not the job of the bootloader, its the job of the bootloader configurator.
About grub doing that automatically, you’re wrong update-grub aka “the bootloader configurator” is creating the menu entries.
Grub does not generate menu entries at runtime…(But sd-boot actually can and does for firmware setup, efi shell and M$)
I solve that by mounting the ESP at /efi and do a bind-mount of a subdir of the ESP as /boot eg: systemd-mount -o bind /efi/Manjaro /boot or inside fstab or like me in (auto)mount units…
So in short grub looks like it is easier because it already has scripts doing all the needed heavy lifting, while sd-boot (Systemd-boot) does not yet, which will change as time goes by and more and more people use it
Since this seems like an attack on something I spend my personal time on, I will just say that I have fixed every bug that I can verify and has been reported with sufficient information to resolve. In your case, of the four issues you reported, one was fixed, one was not a bug and the other two required more information to resolve.
That being said, it doesn’t work for everyone and may not be a good fit for your specific situation. The goal of it is to provide automation for people who are familiar with how grub works on Manjaro. Not to be a replacement for things a power user can do by hand.
That is what I was referring to as “acrobatics” and what you describe is the opposite of “just works”
systemd-boot has been around for a long time now. It doesn’t seem to me like lots of distros are moving to it in the near future. It seems more like the distros who want to use it, already are.
Again, I am a fan of systemd-boot so don’t take this the wrong way. I just don’t see it as the clear path towards the future. I see it as one option of many. It fits some use cases well but grub fits a bigger variety of use cases in a more automated fashion. Unfortunately, to do that, it brings with it a bunch of complexity that many of us find unnecessary.
To avoid misunderstanding, I recommend using more neutral language when criticising other projects.
Since both of you work on similar projects, how about some collaboration? Major issue for adoption of systemd-boot is the lack of ecosystem around it. If there was a cross distro tool similar to os-prober for systemd-boot, it would be quite beneficial.
Here is a link to a repo
When I talk about grub, I’m referring to the whole ecosystem around it, not just the bootloader itself.
This reply made me say that, as it will wipe pre-existing entries with its default config which is used at install time…
That reply clearly stated that he was unwilling to fix that behavior (my point 4 in that issue)
It also made me drop that topic instead of going into a debate…
I completely agree with the need and i have already mentioned it to the systemd devs.
But the fact is that different distros do things different wrt to kernel and ramdisk images, thats why they all need separate scripts to give the same results…
I use rEFInd, but I don’t believe it supports encryption, which I need for my laptops. I use rEFInd on my desktop though, and love it. That being said, I haven’t actually tried it with an encrypted drive myself, I’ve only read about it.
Sure it does, exactly the same way as systemd-boot does. Not fde, but encrypted root anyway. Manjaro-architect even had automation for setting it up like this.
Yes it is. It’s more than just a simple text file that is needed. You need to write scripts, hooks, and modify the installer. The you need to package it and test it. With grub, all that is already done. So compared to no hassle at all, it sure is hassle.
Also, even if the work for grub wasn’t already done, you would still need to maintain another bootloader option for legacy boot. So even in that hypothetical scenario, it’s twice the hassle.
So, as a distro maintainer, you need to justify the extra time you would need to spend on it. And systemd-boot offers… Less features and marginally better performance on low power hardware.
If you eliminate every performance gain like that from the start, then your whole system will stay a powerhog at end…
It’s like a developer prefering VisualC over assembly to write a driver…(eg. bad choice)
Performance is important, but it is not everything. There are other factors to consider too. Assembly is not the right choice for every need. You always have to balance developer time with execution time. In my tests, systemd-boot is 0,5-1,5s seconds at booting than grub. Booting happens 0-10 times a day. That’s some added benefit, but not a lot. If someone else is putting in the time, then the tradeoff for me personally becomes better.
But it’s not just developer time versus execution time. It’s also less features and less supported hardware. It doesn’t support legacy systems and all, and some systems like my previous laptop, systemd-boot just refuses to install where other bootloaders start happily.
So, is there something else interesting that systemd-boot is bringing to the table as a a distro default? I think it is a great option for some use cases, but it doesn’t currently support enough use cases yet to become the default.
I guess you must have worked for M$ in your past or still are…
Because your line of thought is not that of a real developer who puts execution time over the efforts needed to get the benefits wanted…
Seriously:
How many new hardware do you expect to be non-UEFI in the coming 5 years.
Do you want your distro (well ours actually) to be top-notch or a snail following the oldest software.
As a distro maintainer, i would personally put aside my own personal gains/usage plans and look for the benefit of the user-base for long term plans, but that’s just my opinion…
Reading this topic and there are some things that make me wonder how you get your info.
You claim.
There are two persons who ask for a source on how you came up with that idea, but you never provided one. So is it your own opinion or a fact with multiple sources?
This is nonsense in the first degree.
Yes GRUB is the most widely used Linux boot manager but not the only one and there are multiple alternatives.
The thing I like is that if I don’t want to use Grub I can use… well lets see… rEFInd, Clover, systemd-boot and many more depending on what I want or need.
Some claims you make are good and surely something to discuse or think about.
The ideas are not bad either, but it seems that you want to force your ideas and claims on others.
The reason of that is (and I see it in more topics you start or reply in)on some point when people question your claim. you are going more and more in a personal direction.
In this topic also more then ones, lookes to me you want to hear your right.
Same in your last comment for instance…
What is this about?
Also it is Microsoft and not M$
It is my personal logical conclusion of the software used in most distros. Eg. Most have adapted to SystemD as system manager.
Most distribution maintainers like to minimize the required software for an operational distro.
Because systemd-boot (sd-boot for short) is part of SystemD, it will become the default bootloader on systems that use SystemD in the long run.
If you guys insist on source references you can use my replies on the internet mentioning it
So no it is not an “official statement” by Linus Torvalts (who else would you accept as official source right?), it is just a logical deduction of what and how software is used in the community…
Nowadays that’s correct (your statement) but in the early stages of Linux it was the only one acceptable for multiple hardwares.
Thank you, but no i never force my ideas i only try to persuade by using logical arguments, which is all anyone can and should do on the internet. (IMHO)
Yes i might come over a bit hard headed, but that’s a flaw of my logical mind that has problems with non-logical solutions. (Or ways of doing things)
If you have noticed most of the times i make statements i use “IMHO” which we all know what it means right?
(Sometimes i forget to use it, but its always in my intentions when i write stuff, im human afterall)
Not at all, but its human that people perceive it that way when their opinions are being questioned.
I never intend to hear just the words “You’re right”, even in cases that i might be i prefer arguments explaining why im right or wrong.
(That’s the only way every human will learn new things and correct wrong info it had)
It’s a ventilation of frustration from an old hacker that coded in assembly in the past and noticed how new “Programmers” created new code.
Plus 2 questions to make him think (and share with us) about where Manjaro is heading…
And no it stays M$ for me and most others who know the reason of it…
(I refuse to write that name in full)
All in all: Yes im an old fart, take me with a bit of salt, im really pleasant when you get to know me, and my intentions are always “good”
I believe it would be better to have an option in the installer to select the boot loader and init.
let the users decide what they want. It would also simplify the process.
I’ve been trying to ask you what the benefit you foresee is. For some reason you seem to be disinclined to answer this, or maybe you just feel that the extra performance is worth it? I like good performance, but there is a limit on how how much time I would use to save 0-10 seconds a day, when that time comes out of my sleeping hours. My backlog is long enough as it is. Again, if someone else codes the ecosystem around it, it becomes much more interesting proposition. But I don’t have resources to do it myself in the foreseeable future.
Legacy boot support is not for me. I’ve actually never used anything but uefi boot on my own linux systems. But as a distro, we need to consider also other users and not just think about ourselves.
Just because systemd keeps bundling in functionalities doesn’t mean that it should be used for everything. Should we also switch from networkmanager to systemd-networkd just because it comes with systemd?
it once you learn what/how it can do things more effectively.
