Just because your bowser is not caching does not mean something else between you and the server is not caching as well.

You could do a lot of things. Rust had a gc and it was removed so they have already explored this area and are very unlikely to do so again unless there is a big need for it that libraries cannot solve. Which I have not seen anyone that actually uses the language a lot see the need for.

Not like how async was talked about - that required a lot if discussion and tests in libraries before it was added to the language. GC does not have anywhere near as many people pushing for it, the only noise I see is people on the outside thinking it would be nice with no details on how it might work in the language.

Nice keys you have there.

Just factor it into your estimates and make it a requirement to the work. Don't talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.

Cdk8s is better at generating yaml. Pulumi is more of a terraform replacement that has a good kubernetes provider (the tf one sucks). Though it can generate yaml as well it is really not designed for this.

IMO there is something nice about having all your infra, both inside and outside kube, controlled by one thing. Then you can declare a whole application in one rather then half of it in one tool and half in another.

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.

Damn how does Linux have standards !?

Linux has standards where interoperability is important. The more things needs to talk to each other the more they need a common standard to talk over. Things like X11/Wayland don't have many alternatives as so many things need to talk over them. The only reason there are two standards here is because X11 has massive limitations that cannot easily be worked around.

For package managers applications don't care about them. Interoperability only matters within a single distro. So people are more free to create what ever standards they want for their own distros. And when people can choose people have opinions and these opinions evolve over time. Which results in multiple competing products that effectively do the same thing.

And here is my hipotesis if the GNU project came up with a good and easy to work package manager in the early days of Linux

Probably, but creating a good, easy to work, fast and reliable package manager that meets everyones needs when you are discovering how you want it to work for the first time is extremely hard. And even if you created a perfect one at the start, requirements can change. This happened with X11, and even with package managers seeing the rise of things like flatpack, snap and appimage that all work fundamentally different from the traditional ones.

Rust isn’t an OO language, but you can organize your code and have hierarchies.

IMO I think this is a common fallacy. OOP does not mean inheritance/hierarchies (despite them being part of every introductory OOP course nowadays). The original meaning of OOP had nothing to do with inheritance, that idea was mostly popularised by Java. And these days not even Java devs recommend inheritance as the first port of call but instead often favour composition and interfaces as the better language constructs.

Rust is as good at OOP styles as it is functional or procedural, if you ignore inheritance as a requirement of OOP. And a lot of code in rust can look and feel like OOP code in other languages. The abilities to encapsulate state, and polymorphism your code are far better features of OOP and both are well supported in rust. IMO rust offers the useful features from all paradigms fairly equally, which lets you write in any style you like, or even mix and match depending on the various situations. As one is not always better then the others, but each alone is useful in specific situations. More languages should be like this rather than forcing everything into one mold as it lets you pick the best style for each task.

The teams behind the DART mission are tracking it, and will continue to track it into the future. There is even a new mission set to launch to send another craft to the asteroid to gather more information. So, yeah lots of follow up to come over the next year. It is just far more likely that they don't really have much to say ATM aside from well, that is not acting as predicted, we need more evidence/data to figure out what exactly is going on. Which is what this students paper basically concluded.

https://phys.org/news/2023-09-dart-impact.html gives a far better overview of the situation than the BBC article linked above.

The crontab has no concept of . meaning the current directory.

Not quite true. . exists in all directories so will work in any application. But it raises the question of what is the directory cron is running in. Probably not what you expect, definitely not your users home dir and you probably should not rely on it. So you should not use relative paths inside it - even if you can get them to work. Best to just stick to absolute paths or explicit cd to the right location before hand (that is on the same cron line or in the script it calls).

Canonical, the creator and main contributor of the LXD project has decided that after over 8 years as part of the Linux Containers community, the project would now be better served directly under Canonical’s own set of projects.

Or does Canonical think Canonical is better served if LXD is directly under its control 🤔

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.