Hacker News Reader

Comment by Koshkin | Hacker News Reader

One of the “options“ is Ubuntu. Looks like a sensible “default” to me. Just works. Stays out of your way.

Until you upgrade the kernel and your wifi stops working. Or the desktop stops loading and you have to spend time going through logs and googling what's broken this time. Or when you plug it to a secondary screen and it freezes. This happened when I was a desktop Linux user and this still happens (less frequently nowadays though). I'm mainly talking about Ubuntu which is supposed to be beginner-friendly and not some obscure distro.

When I was younger I was very happy to deal with these issues because I learned a lot and probably made me the professional I am nowadays. Over time however I realized much of this knowledge doesn't contribute to my day-to-day work anymore and it's just an annoyance - I now want to turn on my laptop and work right away.

If you want to run linux, buy from a manufacturer with decent linux support. In my experience, all my dell laptops worked seamlessly with linux. No driver hackery required. WiFi never stopped working. However, HP seemed to have very poor support for linux, and you need to install drivers for WiFi manually, which need to be recompiled on each kernel upgrade.

objectively speaking, Debian is perhaps the most stable mainstream os in the world. if you want stable give it a try!

That never happened to me on Ubuntu. Fedora, on the other hand...

Ubuntu is good right after you install it, but then steadily decreases in quality. I got to the point where I avoided updates, because random things always broke.

After trying several distributions. I ended up long-term moving to Arch, it's way more work to setup but it has more of a I built it, I can fix it vibe. I always struggled to fix previous distributions after some update blowing something up.

In my opinion, the biggest thing Mac and Windows has going on is how stable they are.

Yeah. Ubuntu package stuff that is simply broken, which has caught me a few times. RHEL at least support most of their packages.

There's a use case for both distros, but I can rely on RHEL / Centos more.

Not being cheeky, but "just works" except when it doesn't.

Then off to the command line to try to make it work.

And I think the way Linux was built, (ok this will sound naive but) focusing on the "command line" first makes everything second class.

Maybe every cmdline app should also include a binary api to be able to be used in an automated fashion (yes, you can call "system" but that is finicky)

It's not wrong, but as someone who has basically always used both Windows and Linux, and has spent some time managing a Windows network, Windows machines have their fair share of "just works except when it doesn't" too. And then you end up with "try changing this weird registry setting" or "run this random cmd command" too.

I hooe my update from 18.04 LTS ro 20.04 LTS will be the opposite of eventful.

Wait for 20.04.1 or .2. I never upgrade until there’s been enough sample data for fixes to come in. Nor do I ever use the odd-numbered releases.

The only "default" I considered insensible with the latest Ubuntu is that it still overwrites the default system boot loader. I was able to recover through the BIOS boot menu though I can see this how it can deterring new users from trying this.

I'm not sure why they insist on installing GRUB when UEFI allows the firmware itself to act as a boot manager (remembering boot options and their order) and the kernel itself can be booted directly as an EFI application.

How do you debug in that configuration? And would a first time user know how to do that?

Well first of all the goal is that there would be no debugging required if the system works well, and in my opinion less moving parts (like GRUB) means less chance that something breaks.

The UEFI boot entries can be configured by the operating system with the "efibootmgr" command (http://manpages.ubuntu.com/manpages/bionic/man8/efibootmgr.8...) so if a more user-friendly version of it is required then a GUI can be written around that. Whether it's necessary or not is another matter because as far as I know there is no GUI around the GRUB configuration either and it mostly works.

Speaking of GRUB, how it works in Ubuntu land is that there are a couple of scripts that read different configuration files to generate the final GRUB configuration file which is actually a bash-like script (yes, GRUB implements a scripting language) and if you look at it you'd be horrified. The UEFI way of doing things is much simpler.

So the idea would be to 1) check whether the installer is booted in UEFI or BIOS, if UEFI then check if an existing OS is installed and whether it boots in BIOS or UEFI mode (whether the drive is partitioned in MBR or GPT), and then decide whether to skip GRUB (for UEFI-capable configurations) or keep it (for BIOS systems).

grub with timeout 0 achieves the same visual effect, but sometimes you need debugging (windows also has "boot into safemode, android has recovery etc.).

There are many bootloaders you could choose from efistub (which you mention), gummiboot, refind ... . Having one with a user visible interface is useful if you either dualboot or want to expose things like previous kernels or filesystem snapshots.

> So the idea would be

Sure you could do that, or you could set grub timeout to zero if multi booting, larger timeout if not and present the same familiar interface no matter whether you use UEFI or BIOS.

My argument was less about the visual impact and more about having yet another moving part. A timeout of zero doesn’t magically solve the complexity of its configuration or failure modes.

systemd-boot is a good solution to this problem. It's less of a horrible complicated mess than GRUB. You can add menu entries for multiple operating systems, an EFI shell, and the BIOS menu, just like with GRUB. It has a much nicer configuration story and integrates with the other systemd components (so, for example, you can reboot into a different boot menu option through a systemctl reboot flag just like the equivalent feature in Windows).

systemd-boot only supports UEFI systems, so GRUB would still have to be an option for legacy systems.

Check out the Arch Wiki page: https://wiki.archlinux.org/index.php/systemd-boot

I kind of wanted to mention it as what I think is a better alternative but I feared it would label me as a systemd propagandist (given the polarising nature of it, even though personally I think it’s advantages outweigh the - often philosophical - drawbacks).

I think that anyone can recognize it as a good alternative for Ubuntu, since Ubuntu already uses systemd (and that's a done deal).

I'd consider myself a pragmatist, so I like systemd because it makes my life easier with the declarative configuration and other nice features (although I recognize that it makes some people's lives harder).

For Ubuntu and it's derivatives, installing from the command line with "ubiquity -b" should work for that.

Sorry, but you can't use trollish usernames on HN (https://www.urbandictionary.com/define.php?term=tikthot) - it ends up trolling every thread the account posts to. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

I've banned this one for now but if you email hn@ycombinator.com with a better username we'll be happy to change it for you and unban the account.

Reply on news.ycombinator.com