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.

Blender is more of an artistic tool. Not great at creating precise geometry. Tools like freecad make it much easier to create functional parts where the geometry matters. They are also easier to edit and adjust things after the fact as they tend to be parameterized - letting you update a value to update the model.

But they are terrible at more artistic things like miniatures or figurines or more organic shapes which is where blender shines.

So it really depends on what you are trying to create. But for a lot of people using 3d printers (which I believe tend to create more functional than atheistic prints - at least from designs they have created themselves) tools like freecad tend to serve them better then tools like blender.

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.