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 plats 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.

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.

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.

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.

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.

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

The known unknowns and especially the unknown unknowns never get factored into an estimate. People only ever think about the happy path, if everything goes right. But that rarely every happens so estimates are always widely off.

The book How Big Things Get Done describes a much better way to factor in everything without knowing all the unknowns though - Just look a previous similar projects and look how long they took, take the average and bounds then adjust up or down if you have good reason to do so. Your project will very likely take a similar amount of time if your samples are similar in nature to your current task. And the actual time already factors in all the issues and problems encountered and even if you don’t hit all the same issues your problems will likely take a similar amount of time. And the more previous examples you have the better these estimates get.

But instead of that we just pluck numbers out of the air and wonder why we never hit them.

The social aspect of going into a dark room to watch a screen in silence? Vs talking a joking around on voice chat?

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.

What I would love to see is a terminal that builds it’s own shell from scratch too rejecting the ancient ideas we have with bash. I still love bash but I’m curious what could come of it.

Thinking about it some more I am not sure that we would have to go that far. Well not in the longer term - short term we might for experimenting with ideas. I think one of the bigger problems ATM is the terminal does not understand what a shell is or its component parts. Terminals just display characters and move the cursor around the screen and send keyboard and now mouse input back to the command they run. They are also aware of alternative buffers and raw input mode and know about echoing characters back the the screen.

If we extended the terminals to also understand some shell concepts like the prompt, commands being typed and output from the commands and gave the shell some markers it could send along with these (like we do with color information ATM) the terminal would be able to use these to change how it displays each part and would open up a lot of new an interesting features. Could even add things like tooltip support or actions on clicking some bits of the text.

I am starting to see these terminals as experimenting on what we features could be enabled if we were not stuck on the current VT100 protocals. Though if we ever get wider adoption and generalisation of these ideas backed back into the protocals will be another question to consider.

Thinking about it some more I don’t think we would need to abandon the whole TTY to get a good set of the features. What is basically required for a lot of the features is more communication between the shell and the terminal. There is already some communication for basic things - like raw mode and alternative buffers, colors and even images. These are how TUI programs like vim or screen/tmux function and how you can exit them without losing what was previously in the buffer.

I wonder if markers for the prompt and start/end of command output would probably enable a lot smarter virtual terminals with only some minor additions to the VT100 protocols. Possibly some extra data could be sent as well - like optional tooltip data maybe or even supporting actions that when the user clicks something it can send a response back to the shell. Maybe like a retry button on previous commands for example.

There is quite a lot that could be done if the terminal and shells had better protocals to communicate between each other. I dont think these will change overnight though so seeing terminal emulators try out these features to find what people like/want to use IMO is a good thing to see where we can take things in the longer term.

Would we have to abandon SSH or always X forward

No we would not. At the end of the day a TTY is just a input and output pipe between the terminal and the program running on the shell with a specific protocal VT100 (or some bastardized version of that - looking at you xterm). This is what network protocals are as well - just with different protocals in play. So you can do a lot over that connection with changes to the protocals. No need for xforwarding at all.