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.

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?

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.

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 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?

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.

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.