And then relabel all the old standards when they create a new one so every generation you need to figure-out what al the new names mean.
And then relabel all the old standards when they create a new one so every generation you need to figure-out what al the new names mean.
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?
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 ];
I hate it when people put commands in screen shots. Means you cannot just copy-paste from them.
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.
Or your example, how would we have processed ore into metal without coal (on any significant scale).
We have been processing ore into metal with coal for thousands of years. It sounds like you are arguing that the industrial revolution has been happening for thousands of years. Which it has not.
We also made bread in the industrial revolution which is needed to feed the workers. Without feeding the workforce we could not access certain advancements. Is bread a corner stone technology of the industrial revolution? No it is not. It in no way defines what the industrial revolution was. Just like coal or oil.
You can run a steam engine off of coal, wood, oil, nuclear, basically anything that creates a lot of heat. Coal is more convenient in a lot of ways but it did not unlock anything special. If not for coal we could use wood or charcoal. That was the steam engine, not the fuel it runs on.
And if the advancements were because of these fuels that why did it not happen 1000s of years ago when we had access to them?
We burned wood. Then we burned coal. Then we burned oil. Then we burned atoms.
That is not a useful way of thinking of things. We have been burning oil and coal for a very very long time. Coal has been used in smiths to forge metal and oil to light lamps for 1000s of years.
It is not what we burnt that changed, it is what we did with the energy that changed things. Aka the steam engine was the real keystone technology in the industrial revolution. It was not the burning of oil that changed anything - but the internal combustion engine being put into cars.
You might do damage. Though that is very hard to actually do and quite rare in practice.
I don’t think it was burning coal that started the industrial revolution. We had been burning coal and oil for far longer. If anything it was the steam engine. And the internal combustion engine was still part of the industrial revolution. Though the development of cars lead to the automotive era.
The devs from ΔV: Rings of Saturn give a completely different story. Yeah, most bug reports come from Linux - but platform specific ones a vanishingly rare: https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/
Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!
Not to mention the quality of the reports from the Linux users was vastly more details and useful to them.
I mean more general than heat with a stove. Not as is every form of meal preparation.
But yes. I would cook a salad - stir frys are basically just cooked salads with some rice or noodles. I would not consider every salad to be cooked though.
I see cooking as a more general term. Both baking and grilling are forms of cooking. You can also roast and grill things in the oven. Cooking on a stove also has different specific terms, boiling, simmering, frying etc.
One of the fabricated battery pouch cells was even able to work after being folded and cut off. “That proves its high safety for practical application,” the researchers emphasized.
If you can cut it in half and it still works I doubt piercing it will do much.
I no longer use git stash. I found far too many issues with it. Merge conflicts and old no longer useful stashing building up, forgetting what was on it and which branch it came from and other things. These days the only time I stash is with --autostash on a git rebase as that is very temporary.
Instead I have moved to a worktree where I just commit everything on the main branch. Then use a different worktree to create a branch and cherry pick from main and create prs from that branch.
No need to stash as my main worktree never changes off the main branch and my second worktree never has local changes that are not committed.
If I need to change focus or fix a bug I can just do that, commit those changes only and cherry pick to a new branch all without affecting my current work (assuming I have not changed the area the bug is in too much but that is not a big issue if you keep commits small and create PRs often so you don’t drift too far from master).
If I have drifted too far I can always create a new worktree from origin and not touch my local main.