Not sure this type of thing is useful to a broader audience. It is specifically for those that own chisels and/or planes to help with setting things up for sharpening. Anyone in that space who owns a honing guide and set of sharping stones will find it fairly obvious how this functions from the given details and pictures. For anyone that wants to sharpen a chisel or plane blade and does not yet know how there are a lot of guides out there that will go over those details where this device is only one small optional part of the picture - at which point the intent for this device becomes more obvious.

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.

I don’t think that “intermediary authorities” and “peer review” are the problem here nor will they completely eliminate disinformation and conspiracy theories on the internet. Getting rid of them does not help at all with those goals though. The big problem with publishers ATM is the closed access and processes that go on.

IMO places like Open Science Journal and PLOS are vastly better and attempting to solve the issues with the current closed and restrictive publishing models.

rust-analyzer I believe will compile all the deps the first time it runs. This will take some time but after that it should be fast. If you run a cargo clean that will wipe everything and you will have to wait again. So dont do that. clean should be something you run sparingly not before every compile.

cargo add <dep> is a relatively new command. For a long time you had to edit the Cargo.toml file to add a new dependency. So a lot of tutorials still use that as a way of adding a dependency. And other guides often copy from the older ones. They also can describe it this way as a way to introduce the Cargo.toml structure since it is not hard to hand edit. cargo add is just a convenience after all and it is still worth understanding the Cargo.toml structure.

But yes, many people do use cargo add for simply adding deps rather than editing the toml file. Though it is not uncommon to edit it by hand either.

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.

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.

Sovol V8 is a nice printer, especially for its price. Based on the voran v2.4 but pre-assembled.

Nice keys you have there.

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.

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.