Someone once told me somewhere, that if I am trying to learn rust, I should learn C first, so that I know how to shoot myself in the foot, learning to avoid doing so

This is stupid advice. If you want to learn rust then learn rust.

So thats what I did (somewhat) for the past 6 months. I wrote some stuff in C

In that time you are no closer to learning rust. If you started with rust you would know it by now. Rust is not harder to learn then C. If anything C is harder to learn as it's compiler doesn't guide you at all.

You don't need to learn C to appreciate the borrow checker. I find beginners just accept whatever they are first taught. It is only really those that come from C the put up a bigger fight when learning rust.

And 6 months in a language without a borrow checker is not really long enough to learn the reasons why a borrow checker is useful. Not without a good guide that focuses on that. Which most c books don't. The best way to learn it is with rust that actually tells you when you mess up.

Worktrees are great. Although I use them is a different way. I only use them to allow me to rebase or cherry pick onto branches, which require a working tree to do, without ever leaving my main branch. Basically I use them as more powerful branches then full worktrees.

Instead I just do all my work in the main branch/worktrees. When I have something I want to push to a pr I commit just that change to main. Then create a branch and work tree (I store them in .git/wt/). Then cherry pick the commits onto that branch and push that creating a pr from it. Then go back to working on main again on top of the changes I have done. Once the pr gets merged I do a pull --rebase which drops the commits from main.

This means I don't need to switch directories ever and let's me work on a feature, then do a refactor (or minor bug fix), commit and push the refactor in isolation while continuing to work on the feature on top of the refactor.

I don't agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.

On their readme

Harper currently only supports English, but the core is extensible to support other languages, so we welcome contributions that allow for other language support.

Or refactored at a later date.

Would it even need to pretend it is open? If it can fake a port being open then it can tell when a close port is being pinged. So can outright block connections from those IPs without ever pretending it is open?

Anything is possible with sockets... and that is a meaningless statement. It is like saying you can build anything with bricks. Technically true, but missing all the important details of how.

In an alternative universe we could have done so many things differently to solve the same problems. But we don't live there and in our universe dbus was the attempt to solve that problem among others. And yes you can create a standardization for music players easily enough - but what about notifications, and everything else? DBus tries to be a generic interface anything can talk over at a logical level - rather that just being the basic way two process can physically send bytes between each other.

And therein lies the issue, how clear is clear?

For example, if someone managed to get hold of bottles with slightly thicker glass, you could sell a bottle of wine with slightly less wine in than is obvious from the outside, increasing the price per mililitre by a few percent. Not much individually, but it all adds up over the year.

You put the volume on the label, like you already required to do along side the ABV and other markings. That tells you how much liquid is inside - not trying to judge the size of a bottle by how thick the walls are.

Standardisation simplifies manufacturing (of bottles) as well as purchasing of the end product by consumers. There is no benefit to an overly wide selection of sizes.

This makes no difference to manufacturing really. If it did then all bottles would be the same shape. We can have different shaped bottles for everything already so varying the size makes no practice difference here.

These arguments for standard volumes of bottles are very weak. There might not be any big benefit to different sizes, but there is also not a huge disadvantage either. At best it is mildly simpler to compare things of the same size rather than just at a price per 100ml (regardless of the actual volume). Though you should still have a price per 100ml so you can compare the cost of things at different sizes groups (even for the same product).

A far better argument against this is that it is a pointless stupid waste of time that no one asked for and no one under the age of 50 was even alive to remember wine being sold by the pint. There are far more important things the government can be spending their tax payers money on fighting for.

I think it is more malicious then that on the manufacturers part. It is more that when something goes wrong it just gives a cryptic error message and the workers have no clue what went wrong and so don't know what to do to fix it or stop it from happening again. For instance, it seems one issue is that if you overfill the hopper and out it through a (4 hour long) cleaning cycle it will fail to reach the required temp and then refuse to work until it has gone through the cycle (for safety reasons). But all it spits out is a cryptic error message and the workers are clueless as to what is wrong. Then they need to call out a technician to diagnose and fix it at a fairly high hourly cost, even though it is something the works could solve if they know what was wrong (ie not filling up the hopper so much).

https://www.youtube.com/watch?v=SrDEtSlqJC4 goes into a deep dive of the problem. And note that the problem is only with McDonalds ones - other chain using the same basic machine don't have the same issues. Likely due to some old partnership between the manufacturer and McDonald screwing over the franchise owners.

There is also no loss for McDonald's central, but they have a old and close business relationship with Taylor that they seem to care about more than their own franchise owners.

It is part of their kernel. And there are a few different schedulers at play, you have the CPU one as well as the I/O one. Arch Linux has various different kernels (such as the zen one) that use different CPU schedulers (with lots of options in the AUR as well) and there are various settings you can tweak for different I/O ones.

I general you should go through the Improving performance wiki page on the details for these and even more performance tweaks you can do.

There is also pages for tuning things for better battery life for laptops as well that you may also find interesting.

Nothing wrong with hardware raid in general. But most consumer motherboards do not have true hardware raid - but instead fake raid. Which is some basic hardware boot time support for software raid. IE the BIOS can understand the basic raid features to boot the system - before handing it off to the OS to manage.

I would not use fake raid on a Linux system if you can avoid it, full software raid is just better than most consumer hardware fake raid support.

True hardware raid generally requires a separate expensive card that has its own controller and ram buffer.