How are they not memory safe in a multi-threadded context?
How are they not memory safe in a multi-threadded context?
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?
It is about WPEngine not contributing enough back to Wordpress, in terms of development effort or money. Apparently the trademark is the only legal grounds they have to go after WPEngine to try and get them to contribute back more.
If the trademark is indeed on the wordpress.org foundation and not the wordpress.com company, I didn’t think that’s a fair argument.
It is but the trademark is licensed to Automattic which handles all further commercial sub-licensing. And the CEO of Automattic sits on the board of the workpress foundation and is the creator of wordpress itself.
I don’t think either is a cancer to the FOSS Wordpress ecosystem. Both seem to give back.
I believe that this all started as the Automattic CEO did not think that WPEngine was contributing enough back to the wordpress ecosystem. Even after years of attempts to negotiate this. Seems he gave up trying and went after them for trademark rules as that was the only real leaver he had to pull. Since there is no obligation for WPEngine to contribute back to wordpress directly.
WPEngine using the Wordpress trademark makes me think they’re using Wordpress
Apparently this is contentious enough to be disputed in court not everyone thinks this and there are enough people that are confused over the matter that Automattic believe they can prove a trademark volition in court.
Lots more details in this interview with automattic CEO.
Dont know whos right here. Probably both sides are wrong to some degree. But worth hearing both sides of the argument before making a decision.
So, new plants were green lit on the promise of some carbon capture and storage technology that is yet to be proven. And companies will be given tax payer funds for this project to invest in these unproven technologies.
I bet that most of that money will line the pockets of some rich twat with a token effort being made on actual research - then they will either claim it is too hard or too expensive to actually do or will implement something so cheap and crude as to basically be pointless but makes it look like they are doing something. Then they will build the plants anyway and carbon emissions will be basically the same as any other plant of that type.
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 ];
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.
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.
You should not be struggling most of the time when using the CLI. Basic uses is just as easy as any GUI. Learning the commands might be a bit more involved and you need to be a bit more proactive about it. Anything you need to do 30+ times a day you should be over the learning curve of and can just execute them just as quickly if not quicker than using GUI. Especially when you look at tab competition and the reverse history search.
But what using the CLI more often does teach you is how to lessen that initial learning curve. Making you quicker at finding the new commands you need and how they work slowly building up your tool belt of knowledge about the commands you do look up.
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?
I don’t think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.