When I change devices or hit file size limits, I’ll compress and send things to my NAS.

Whaaatt!?!!? That sounds like you don’t use git? You should use git. It is a requirement for basically any job and there is no reason to not use it on every project. Then you can keep your projects on a server somewhere, on your NAS if you want else something like github/gitlab/bitbucket etc. That way it does not really matter about your local projects, only what is on the remote and with decent backups of that you don’t need to constantly archive things from your local machine.

It doesn’t technically have drivers at all or go missing. All supporting kernel modules for hardware are always present at the configuration level.

This isn’t true? The Linux kernel has a lot of drivers in the kernel source tree. But not all of them. Notably NVIDIA drivers have not been included before. And even for the included drivers they may or may not be compiled into the kernel. They can and generally are compiled with the kernel but as separate libraries that are loaded at runtime. These days few drivers are compiled in and most are dynamically loaded depending on what hardware is present on the system. Distros can opt to split these drives up into different packages that you may or may not have installed - which is common for less common hardware.

Though with the way most distros ship drivers they don’t tend to spontaneously stop working. Well, with the exception of Arch Linux which deletes the old kernel and modules during an upgrade which means the current running kernel cannot find its drivers and stops dynamically loading them - which often results in hotplug devices like USB to stop working if you try to plug them in again after the drivers get unloaded (and need a reboot to fix as that boots into the latest kernel that has its drivers present).

I don’t get it? They seem to be arguing in favor of bootc over systemd because bootc supports both split /usr and /usr merge? But systemd is the same. There is really nothing in systemd that requires it one way or another even in the linked post about systemd it says:

Note that this page discusses a topic that is actually independent of systemd. systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems.

I don’t really get his points for it either. Basically boils down to they don’t like mutable root filesystem becuase the symlinks are so load bearing… but most distros before use merge had writable /bin anyway and nothing is stopping you from mounting the root fs as read-only in a usr merge distro.

And their main argument /opt and similar don’t follow /usr merge as well as things like docker. But /opt is just a dumping ground for things that don’t fir the file hierarchy and docker containers you can do what you want - like any package really nothing needs to follow the unix filesystem hierarchy. I don’t get what any of that has to do with bootc nor /usr merge at all.

TLDR; yes it does affect security. But quite likely not by any meaningful amount to be worth worrying about.

Any extra package you install is extra code on your system that has a chance to include vulnerabilities and thus could be an extra attack vector on your system. But the chances that they will affect you are minuscule at best. Unless you have some from of higher threat model then I would not worry about it. There are far more things you would want to tackle first to increase your security that have far larger effects than a second desktop environment being installed.

So, why wait for windows 10 EOL? If you are already mostly on Linux and are planning on getting rid of the last bits anyway? If you really need to you can always reinstall windows on a second disk or in a VM later on if you really need to - no real need to preemptively do that if you dont plan on using it.

If you have everything you need backed up you can reinstall on a new hard drive and restore everything you need. So you should not be completely fucked. Just an inconvenience you might have to go through. You will lose the stuff not backed up so if any of that is a pain to get again it might be more painful to restore everything.

Others have said some thing you might want to try. But having a spare disk you can swap to is never a bad idea. Disks to fail and you should plan for what to do when they do. Backing up your data is a good first step.

I would say it is not a bad idea to just get a new disk now and go through the process of restoring everything anyway - you can treat it like your disk has failed and do what you would need to do to restore. With the ability to swap back when you need to.

This is a good way to find things you might have missed in your backups.

Not if you have backed up your data. You have a backup of your data right?

Why wait? Start using Linux friendly software in your day to day workflows. Then start to dual boot Linux with your current system and start using it more and more. By the time windows 10 reaches EOL you will know if you still need a Windows install or not.

I don’t mind ads so much. What I don’t want in invasive tracking and collection of every scrap of data they can to push ads on you. Give some dumb ads based on the damned contents of the page and I would be fine. But no, ads is basically a synonym for tracking these days.

Oh they care. They care a lot. Particularly that you don’t have any so they can sell all your details to any bidder.

Linux makes up exactly one package on a so-called Linux system.

True, it was a poor proxy for what I really meant - which was the amount of code that my system runs. Linux as a project is growing quite fast these days and is getting bigger and bigger. But the number of GNU tools I use (and thus their code that I use) is growing smaller and smaller.

Musl, systemd, Freedesktop, etc. were never OS projects. GNU and Linux are OSes.

What the hell makes a project an OS project? What even is an OS - that is a debate as old as computers. What makes GNU more of an OS than systemd or musl or anything else? GNU is not a complete OS on its own. It has failed to meet that goal for decades. Is it just because it claims that title? Are the other projects just not ambitious enough? Hell why are we not raising pitchforks at GNU for being a all encompassing project that wants to consume everything like everyone complains systemd is trying to do?

The lines drawn here are meaningless and arbitrary. GNU is no more important to my systems as any other project mentioned here and makes up no more of my system then they do. I don’t see why so many are obsessed with singling out GNU and explicitly excluding everything else. It is a pointless distinction created by a guy that was pissy that his pet project was not getting the attention he thought it deserved.

Why not also recognize systemd, or musl, or kde or gnome or any of the other millions of non GNU packages that are needed to make up a complete OS.

Fuck if I am going to rattle off all my installed packages every time I want to mention what OS I am running. Linux is good enough. People know what you mean when you say it. And these days GNU makes up less and less of the core packages that most distros run anymore.

Also the copy pasta that this all stems from explicitly calls out eliminating nonfree programs which most popular distros do not do these days:

Making a free GNU/Linux distribution is not just a matter of eliminating various nonfree programs. Nowadays, the usual version of Linux contains nonfree programs too. These programs are intended to be loaded into I/O devices when the system starts, and they are included, as long series of numbers, in the “source code” of Linux. Thus, maintaining free GNU/Linux distributions now entails maintaining a free version of Linux too.

And they even link to a vanishingly small number of approved free GNU/Linux distros. Of which non of the mainstream distros are listed. So can we really label anything not on that list as GNU/Linux?

Plus this applies to your family as well. DNA is shared and by you giving it up you give up info about those related to you as well.

The problem with bash scripts is they tend to explode in unexpected ways when thing don’t go as intended. This could be one of the command you run returning some expected or not output which might work now but might not in the future. Best to program bash defensively.

Remove the loop and sleep from the script you created so it just runs and exits.

Then create a file at /etc/systemd/system/battery-alarm.service with the following:

[Unit]
Description="Sound alarm when battery is low"

[Service]
ExecStart=/usr/local/bin/battery-alarm.sh # point this to your script

Then create a file at /etc/systemd/system/battery-alarm.timer with the following:

[Unit]
Description="Run battery-alarm.service every 2 mins"

[Timer]
OnUnitActiveSec=2m
Unit=battery-alarm.service

[Install]
WantedBy=multi-user.target

Then sudo systemctl enable --now helloworld.timer to start and enable the timer on boot.

This will be a little more robust then your current script. It works without the user needing to log in. And there is nothing to get killed so will always trigger. The current script will just silently stop working if it ever gets killed or crashes.

Worth running shell scripts though https://www.shellcheck.net/ (has a cli as well). Finds lots of common issues that can blow up scripts when input is not what you expect. With links to why they make the suggestions they do.

Line 4:
        battery_level=`cat /sys/class/power_supply/BAT0/capacity`
                      ^-- SC2006 (style): Use $(...) notation instead of legacy backticks `...`.

Did you mean: (apply this, apply all SC2006)
        battery_level=$(cat /sys/class/power_supply/BAT0/capacity)
 
Line 5:
        battery_status=`cat /sys/class/power_supply/BAT0/status`
                       ^-- SC2006 (style): Use $(...) notation instead of legacy backticks `...`.

Did you mean: (apply this, apply all SC2006)
        battery_status=$(cat /sys/class/power_supply/BAT0/status)
 
Line 6:
        if [ $battery_status = "Discharging" ] && [ $battery_level -lt 21 ];
             ^-- SC2086 (info): Double quote to prevent globbing and word splitting.
                                                    ^-- SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: (apply this, apply all SC2086)
        if [ "$battery_status" = "Discharging" ] && [ "$battery_level" -lt 21 ];

The Steamdeck was motivation for the collaboration - since it is based on Arch Linux. But as a desktop client they only support ubuntu officially which makes level 1 tech support easier as supporting every distro can be very complex.

C is easier to get a program to compile. Rust is easier to get a program working correctly.

REPLs are basically shells. They behave the same way in every essential way. So the real question is support vs non-supported shells. But then that is easy - non supported shells fall back to just what a normal commands do ATM to process input/output. Other applications like TUIs are also easy to deal with as they already enter a different mode called raw mode - when a application requests that it can do what they currently do - switch to a new buffer and give full control to that one application.

I can’t think of any, but I’m not the most creative person… what do you have in mind?

Having smarter scroll back that knows the difference between a prompt/command and the output would let you do quite a few things that would be nice to have. Such as collapsing the output so you can only see the commands, keeping the command at the top of the screen even as other output scrolls off the top so you can always see what was running. Extra support for other UI elements could be nice to have as well - like tooltip support for blocks or similar.

All the shell - or really any application - needs to do is tell the terminal which bits of the output are witch. Like mark the start/end of the prompt, command and command output. Then the fallback is basically ignore the markers and print things out like it currently does.

And those are just random thoughts I have had over the last few days. These can be implemented in backwards compatible ways I believe and don’t need special support for specific shells - just needs to expand the VT100 protocols to be able to send more information between the terminal and shells/applications that are running. Much like how color, cursor positioning, entering/exiting raw mode etc are already done. Though I think some tight specialized integration might be a good start to explore these ideas before the protocols are formed.