Cannot remember if the study was stupid or if peoples interpretations of it where. But when covered up else where you will lose a lot of heat through your head. More so then if just an arm or just a leg was exposed as with your arms and legs your body will slow down blood flow through them to try and converse your core temperature - it cannot do that with your head.

Huh? If it can be used while it is charging - which is all laptops since forever - then it will run off the adapter while plugged in. Regardless of the battery state. You cannot charge a battery and discharge it at the same time - if it is charging then power must be coming from anything other then the battery. Epically with LiPo batteries which you cannot continue charging after they are full - doing so will cause them to burst into flames. So all LiPo charging circuits will cut off power to the cells once they reach a desired voltage - weather that is considered 100% (aka once it reaches 4.2V) or at a configurable lower amount.

And every extra step adds more losses and reduces the efficiency. So it is worst then just using the fossil fuels directly.

There are quite a few places where a GC is just not acceptable. Anything that requires precise timing for one. This includes kernel development, a lot of embedded systems, gaming, high frequency trading and even latency critical web servers. Though you are right that a lot of places a GC is fine to have. But IMO rust adds more than just fast and safe code without a GC - lots of people come to the language for those but stay for the rest of the features it has to offer.

IMO a big one is the enum support it has and how they can hold values. This opens up a lot of patterns that are just nice to use and one of the biggest things I miss when using other languages. Built with that are Options and Results which are amazing for representing missing values and errors (which is nicer than coding with exceptions IMO). And generally they whole type system leads you towards thinking about the state things can be in and accounting for those states which tends to make it easier to write software with fewer issues in production.

but imagine if you have to perform this operation for an unknown amount of runtime values

This is a poor argument. You dont write code like this in rust. If you can find a situation where it is an actual issue we can discuss things but to just say imagine this is a problem when it very likely is not a problem that can be solved in a better way at all let alone a common one is a very poor argument.

Typically when you want an escape from lifetimes that means you want shared ownership of data which you can do with an Arc. Cow and LazyLock can also help in situations - but to dismiss all these for some imagined problem is a waste of time. Comes up with a concrete example where it would help. Very likely you would find another way to solve the problem in any realistic situation you can come up with that I would suspect leads to a better overall design for a rust program.

I would say this is just a straw man argument - but you have not even created a straw man to begin with, just assume that one exists.

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.

Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle).

Even that gets overused and abused. My big problem with it is what is a single responsibility. It is poorly defined and leads to people thinking that the smallest possible thing is one responsibility. But when people think like that they create thousands of one to three line functions which just ends up losing the what the program is trying to do. Following logic through deeply nested function calls IMO is just as bad if not worst than having everything in a single function.

There is a nice middle ground where SRP makes sense but like all patterns they never talk about where that line is. Overuse of any pattern, methodology or principle is a bad thing and it is very easy to do if you don't think about what it is trying to achieve and when applying it no longer fits that goal.

Basically, everything in moderation and never lean on a single thing.

empirical data ... legislative processes.

Haha good one. The only data that matters to those in charge is what makes them more money, and the business friends more money and the lobbyists more money. Other data is basically irrelevant with the current asshiles that are in charge.

The package format is almost irrelevant TBH. Most packages are not interoperable between distros due to the versions and names of dependencies. That is not something that gets fixed by a standard package format. Packages don't even work well between different versions of the same distro. largely due to libc - anything that depends on that is built against a specific version and when you upgrade it you need to rebuild and install everything that depends on it. Similar problems exist for all compiled dependencies on a distro.

And while some packages of the same format can be installed on multiple distros (mostly those based of the same foundation) most cannot. This is what the newer package formats (like flatpack) are trying to solve - by including all dependencies inside the package.

So a standard format does not really solve those issues, so there is little advantage for one. At least not one of the old school formats. And the wars are not really over the format, they are over the tooling required for that format. At the end of the day RPMs, DEBs, and arch packages are just tarballs of files and some meta data (and there is even a tool that can convert between them - though anything with dependencies quickly becomes a complete mess). It is the build and install tooling that makes all the difference.

I am not sure there is any killer feature that you cannot do in a cli application. It is just a different way of working. Slightly better at some things slightly worst at others. But the biggest difference is what you are used to more then and single feature set.

Though I don't personally use them, I also use a shell with a lot more interactive features built in then default bash does. If I where stuck with only default bash maybe I would lean more towards them. But that is just the way I work, others work differently then ai do.

On rough ground that would put a lot of stress in the landing system and likely the rest of the plane. Small cracks in things can lead to catastrophic failure later on even if everything looks fine now. Would you want to take a chance on that?

Not to mention they have to get it out of the field. That alone is probably not worth the effort to save a possibly compromised frame.

They don't really offer tools and parts to their partners, which is how they will weasel out of it. Authorised repair centers are basically glorified mail outpost. Anything but minor repairs or whole assembly replacements will not be possible if that is the wording. But they also want to restrict anything that might touch on security, which they will be able to just serialised any part and claim it cannot be repaired because of bogus security concerns.