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.

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 see nothing in this graphic that isn’t easy to do with a gui.

I didnt say the GUI was not easy for the common stuff. But I think the CLI is also easy for the common stuff so there is not much advantage other than a bit of a learning curve with the CLI. But the big thing that GUIs make harder is automation of common things. For instance, when I want to create a PR I like to rebase to the latest upstream. In a GUI that is a bunch of button clicks. With the cli I just <CTRL+R>pus and that will autocomplete to git pull --rebase=interactive --autostash && git push && gh pr create --web and I am landed in a web browser ready to review and submit my PR. Doing the same thing in a GUI takes a lot longer with a lot more clicking.

And that is a very common command for me.

Like logging and diffing is just so much easier when I can just scroll and click as opposed to having to do a log command, scroll, then remember the hashes, and then write the command.

Never found that to be a big issue. Most of the time when you want a diff you want to diff local changes or staged changes which is simply git diff and git diff --staged neither of those are hard or any real easier in the GUI (especially with bash history). For diffing specific commits I dont find that hard either just git log --oneline and find the commits (and you can use grep to filter things out easily as well here) - typically does not require scrolling at all. Then git diff <copy paste>..<copy paste>. In the GUIs you are often scrolling through commits you want to select at some point so I dont see how that saves you any real time here. I would not say the CLI or GUI is vastly easier in this case. And even in this case it is rare to need to do. Far more often is just branches which on a decent shell can be tab completed for convenience.

And sometimes I watch beginners use the gui and I have to bite my tongue because I know it would be faster in the cli.

This is why I prefer the CLI for common stuff. It is just faster.

But, especially for a beginner, i strongly recommend a gui.

And that is where I disagree. I think beginners should spend some time learning the tools they will need to use. IMO the CLI is critical for developers to learn and the sooner the better. So many things a vastly easier with the CLI than GUIs and a lot of stuff is near impossible with GUIs. Automation being a big one. I have not seen a good CI system that is GUI focused that you never need to know the cli for. Or when you have a repetitive task then it is quicker to write a quick script and run that then doing the same thing over and over in the GUI. Repeating actions is also easier in the CLI. All of these apply to more than just git as well.

I have seen so many beginners start with GUIs that don’t really understand what they are doing in git. And quite often break things and then just delete and recreate the repo and manually make their changes again. I find people that never bother with the CLI always hit a ceiling quite quickly in terms of their ability and productivity.

The only real thing that makes the CLI worst is that it has a steeper learning curve. Once you are over that hill I find it to be vastly better for more situations or at least not practically any worst than a GUI equivalent. So that hill is one well worth climbing.

I can always use a GUI if I really needed to. But those that only know the GUI will have a very hard time on the CLI when they need to - which is required far more often than the other way round.

Not sure I would say that is a rebase failing - just you messing things up. Can happen with any merge. But yeah that is a place where reflog would be useful. But I dont see why it would be on the cheat sheet instead of a git rebase --abort or be rebase specific.

Typically because you have been leaning on the GUI for ages and don’t know the CLI well enough to do the easy stuff quickly let alone the advanced stuff at all. Or are even aware of what you can do with the CLI. And if you do know the CLI well enough you tend to find it just faster to work with and easier to automate things.

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.

GUIs tend to only cover the common/basic usage. Which is easy to remember without a cheat sheet. When you need more advanced stuff then GUIs tend to become more of a sticking point I find. And with common workflows it is far easier to automate with the CLI then with a GUI.

The only time I see a rebase fail is due to a conflict. Which can be aborted with git rebase --abort no need for reflogs unless you really mess things up.

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.

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

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

A water central heating system is a closed loop system that is under pressure. This means the water in it is circulated around and around the system and is cut off from other water supplies under normal operation. Naturally, slow leaks happen and gas can enter the system in various ways so occasionally this needs to be released from the system. Any gas in the system naturally collects at the highest points along the path - which tend to be the radiators.

When you bleed a radiator you are opening the system to the outside and hopefully where the gas has accumulated. Since the system is under pressure it forces the gas out of the system to equalize the pressure with the outside. This will cause the pressure of the system to drop and eventually it will stop.

However there should be a control valve somewhere, typically on/near the boiler that connects the central heating system up to the mains water supply. You can open this valve to cause water to flow into the central heating system and pressurize it and really this should be done every time you bleed the radiator a significant amount.

In apartments though you might find that you are on a building wide circuit, or you might have one isolated for your apartment. If you have a boiler in your apartment then you are likely on a closed system and should be able to equalize the pressure yourself. If it is building wide you need to talk with your building manager.

Note that you should not need to bleed your radiators that often. Once every several years should be more than enough. If you are doing it frequently then you likely have a large leak in your system and likely want to get someone to check that out.