Hacker News Reader

Comment by rbanffy | Hacker News Reader

> I find it fairly easy to work on both Mac OS X, Linux and WSL2 -- but not pre-WSL Windows

The thing that annoys me most on Windows is Windows itself. After using Linuxes for almost two decades now, the notion of the OS taking tens of minutes to self update when all I wanted was to quickly reboot it is unbearable.

> I don't know how/if they're going to handle freeing memory again -- here the NT kernel really needs to communicate with the Linux kernel

Usually "free" memory only happens when a Linux machine starts. During normal usage most of the memory is being used to cache things and, when some large app frees its own memory (such as when Slack quits) it'll eventually be used for other things.

Not sure how that would work. Memory doesn't stay unused in Linux for long - whatever programs free will end up being used to cache information that's slow to access.

View on HN

> The thing that annoys me most on Windows is Windows itself. After using Linuxes for almost two decades now, the notion of the OS taking tens of minutes to self update when all I wanted was to quickly reboot it is unbearable.

This is definitely a problem especially considering that the shotgun approach to some Windows updates actually hurt the performance of some machines, even breaking Windows on occasion [0]. However, in fairness I would say that I've spent just as much or more time fixing rolling release issues on Arch/Manjaro, or troubleshooting the package stopping me from sudo apt upgrade. The worst experience for me was having to reformat after the update from Ubuntu 14.04 crashed.

What annoys me most about Microsoft's overarching paternalistic philosophy is is how creepy their telemetry initiatives are. Granted plenty of companies do this now, for the same profit-driven motivations, but Microsoft goes above and beyond in terms of disabling or even ignoring opt out options [1]. I've found the Winaero blog [2] to be a good source of tools to stop some of the Windows telemetry shenanigans.

[0]: https://www.forbes.com/sites/daveywinder/2019/05/19/microsof...

[1]: https://www.reddit.com/r/Windows10/comments/a4lpg0/windows_1...

[2]: https://winaero.com/

So after a very long hiatus I have decided to try installing linux on a raspberry pi - and wow, the results were amazing. Using my decade-old knowledge of using fstab I added some drives to /etc/fstab and rebooted. Oooops. Raspbian would fail boot with a message "root account locked, couldn't open console".

Fantastic - so if any of the fstab entries are missing, the entire system effectively bricks itself. The only way to fix it was to remove the SD card, put it in another machine, and manually remove the offending entries from the fstab file. Fantastic. I Don't think I have ever managed to get windows to self-brick itself with something so simple.

With great power comes great responsibility, I guess. I agree it would have been nice for Linux to come with a few more sanity checks by default, like maybe a warning flag for rm -rf /* and dd commands...

I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick. You don't even get a basic command prompt to fix something, the default behavior is to lock everything down and forbid access, making it impossible to repair the machine from itself. Windows will reboot a few times and then automatically start in safe mode when this happens, you don't need to extract the drive to manually edit some text files before the system can boot again.

> I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick

If you can't properly start the OS, that's correct behavior. You don't want the OS to start writing things to /var when it can't mount the filesystem that should be mounted to /var.

In any case, the fix with an RPi is easy - pop out the microSD, mount it on the other computer and fix whatever is broken (which should be in the logs). If the RPi is the only computer, put a microSD with a plain install of the OS, mount the other microSD through an USB dongle and fix it the same way you'd do with a laptop.

FWIW, you're using the word "brick" incorrectly. Bricking is when the only fix is to throw the device away and buy a new one, which clearly is not the case here.

I don't think I am. I've been fixing hardware for years and any device that doesn't switch on is "bricked" - its utility has dropped down to zero, it has turned into a literal brick. Just because you can revive it through some arcane procedure doesn't make it any less bricked to the end user.

Flashing a new OS onto the SD card is not "some arcane procedure" for the RPi's target audience.

Distinguish Hard Brick and Soft Brick.

you're getting downvoted, but as a 19-year Linux fanboi, I actually agree with you. If the system has booted at least once, then it knows how to successfully boot. i.e. it knows of a string of modules, kernel, initrd image, etc that worked. As you upgrade, the OS should have a courtesy feature where it doesn't simply delete these files (unless you do the equivalent of issue a "-rf" force command). For instance, we currently have (kernel, initrd, filesystem, and modules that exist on our fs). All we would need to make it (nearly) brick-proof is to add one more thing: fallback-rd that has all the previous shit that worked last time. This would save so many users' asses at hardly any cost since storage is so cheap these days.

Standard rm (coreutils) has included rootfs protections since at least 2012:

    --no-preserve-root
        do not treat '/' specially
    --preserve-root
        do not remove '/' (default)

https://manpages.debian.org/stretch/coreutils/rm.1.en.html

Mind that if your rm comes from elsewhere (say, Busybox), it may not have that protection.

Very careful use of rm as root is an excellent habit to cultivate.

As are backups.

Interesting, I didn't know that and I stand corrected.

What about it? I don't think that does anything for "/*"

I think you are being unfairly downvoted. On of the major downsides to Linux is that while you can, and often have to, tinker to make it work you can break it on many levels. Sometimes it's even hard to know if it is working properly, until you realize it doesn't. Many developers uses virtualization just for those reasons alone. It might even be a major upside to using WSL, if they do it well.

Our tools are either too powerful or too weak. To each their own. I can cope with a tool that is too powerful, but I can't cope with a tool that is too weak.

I don't think that is the general problem. More so inconstancy. It's almost harder to quit vi then to delete your boot record. I am not sure many tools are even that powerful. Which often means you have to use many different ones, making it even more confusing. Linux lacks abstraction and makes you do things manually as root, it isn't very robust.

Use a gui if you don't know your way around the shell. I'm pretty sure Debian provides one.

I wanted to setup a headless Samba server - so after the reboot I didn't even have any way of knowing why the system wouldn't appear on the network anymore. I had to find the right HDMI adapter to see if the system even attempts to start as it was completely dead by all other indications.

And no, I'm sorry but I hate the argument of "you should have known better" - the system first and foremost shouldn't have defaults set up in such a way that not only the SSH server doesn't come up in case of an issue during boot, but the local console is entirely disabled for any access. That's a crazy default.

You probably haven't tried changing windows partition and messing with Windows bootloader's registry file...

I've had a windows update brick my laptop. It failed to complete an update, would roll back, reboot, then try again. Nothing I did fixed it. I spent almost a week with it in a boot loop, trying various fixes and such before giving up and reformatting. Put linux on it and added it to my pile of linux laptops.

Check your video card chipset and call support :P

> In fairness I would say that I've spent just as much or more time fixing rolling release issues on Arch/Manjaro.

That doesn't even matter much to me. Obviously, less time spent is better, but what really matters is the timing.

When I have to spend time upgrading my linux box, I have set time aside. I decide that I have a bit of time, and if it turns out to be a bigger job than expected, I can decide to abort and continue some other time.

On Windows the upgrade is always inconvenient, because you have no way of controlling it. Microsoft decides when the best time for you to upgrade is, and once it starts you have no means of punting on it.

Although the telemetry is certainly a problem too.

> Obviously, less time spent is better, but what really matters is the timing... On Windows the upgrade is always inconvenient, because you have no way of controlling it.

True, very good point in favor of user control. Linux has the added benefit of teaching the discipline and foresight to understand that "Hey... maybe I shouldn't run sudo pacman -Syu and reboot until I have some time set aside". Though in recent years I've found Arch to be way more stable with very few updates causing major problems.

> Though in recent years I've found Arch to be way more stable with very few updates causing major problems.

Can confirm. I've had the same Arch install for nearly 6 years now. I've borked it only once in that time, and that one was my fault for not reading the news first. Fixed it in < 5 minutes.

And I've made considerable changes in that time, including moving the entire installation from one hard disk to another.

> That doesn't even matter much to me. Obviously, less time spent is better, but what really matters is the timing.

That too. When I update MacPorts, it can, sometimes, take ages. I don't care - I just continue working.

Send a hotplug notification that a region of memory is going to be disconnected. The kernel will stop making allocations there, and eventually it won't be in use. (This could take a while for a heavy system with long-running processes.) Then you send the hotplug physical disconnect notification. If it fails, you'll need to wait longer. If it succeeds, the host system can reclaim the memory.

I don't see how that is a specific problem. All operating systems have annoyances. But if you are for example an engineer you won't find a competitive range of software on Linux. For someone in need of doing software engineering a similar situation have been developing on Windows. WSL changes that.

> All operating systems have annoyances

But not all annoyances are created equal

I don't find that annoyance particularly grave or different from other annoyances. I just updated and rebooted my Windows machine I haven't used for a month, took maybe 5 seconds longer than usual. Regardless if that happens every day that isn't something I am going to base my choice of operating system on. This is one of the problems with desktop Linux, caring about some detail (even though it might affect some a lot) rather than the big picture which affects everyone.

>The thing that annoys me most on Windows is Windows itself. After using Linuxes for almost two decades now, the notion of the OS taking tens of minutes to self update when all I wanted was to quickly reboot it is unbearable.

I find the same thing with electric cars. Eight hours to charge when I've spent two decades filling in minutes is absurd.

Reply on news.ycombinator.com