Or the RFID chips on their spools.
They do quite a lot of things that are fine atm but are gateways to giving them a huge amount of control if they every want to flip that switch - like if they get brought out or their investors start wanting to squeezing them for all they are worth.
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 ];
Probably nothing. This is more steamdeck related stuff since the SteamOS is based on ArchLinux. And even then, it does not mean much for SteamDeck users. They wont notice much at all really. This might help with development a bit on valves end. The big news is really for ArchLinux users and maintainers which will see more effort in the development of that distro.
There is some wild speculation that maybe this makes arm for Arch Linux more official in the future. Which is based of the other recent news that Valve are creating an ARM emulation layer for running games on ARM devices. Which means maybe they are working on an ARM device and maybe need to start working on getting ARM support for Arch. Though again this is all wild speculation.
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.
Arch normally immediately updates to the latest version of every program
This is not true though. Arch packages new program versions as soon as they can - for popular stuff this happens quickly but not everything updates quickly. And when they do publish a new package it goes to the testing repo for a short time before being promoted to the stable repos. If there is a problem with the package that they notice it will be held back until it can be solved. There is not a huge amount of testing that is done here as that is very time consuming and Arch do not have enough man power for this. But they also do not release much broken things at all. I have seen other distros like ubuntu cause far more havoc with a broken update then Arch ever has.
as an illustration of our player-centric approach
Or in other words: We lots loads of money when people didn't flock to our exclusive platform like we wanted and it seems they don't like being squeezed for every penny they have.
Avoid
clone()options ^_^
I don't really like that as general advice. A lot of the time a clone is perfectly valid and fine thing to do. More often then not I will read for a clone rather then an Rc or Arc. Its fine, you dont need to be afraid of it. And it misses the more important advice - avoid allocating in tight loops.
There are lots of ways you can allocate data. Clone being only one and not even all clones will allocate data. So it is a poor thing to get hung up on. If you have an Rc or Arc then clones are cheap. Stack only data is also cheap to clone (and is often copy). Some structs internally use Arc or Rc or are just simple wrappers around copyable types. And it misses other forms of allocations, creating Strings or Vecs, boxing data etc. All of these things including cloning are fine most of the time. But should be avoided in tight loops and performance sensitive parts. And when learning it quite often does not matter that much to avoid them at all.
I have seen quite a few people make things way harder for themselves by trying to avoid clone at all costs in all situations and IMO articles like this add to that as they never explain the main nuances of allocations and when you want to avoid them or when they are actually fine to use.
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.