Mind your typos... It seems clear a bad actor is hiding behind that one.

Looks like a nice tool to monitor your Proxmox install.

We can expect more misleading papers to be published by the big LLM providers. Don't fall in the trap, wait for actually peer reviewed papers from academia. Unsurprisingly the results aren't as good there.

Looks like a neat way to learn shader programming.

Alright... That's really bad security practices. Don't do this at home.

We really have nice facilities in the kernel to squeeze some extra performance nowadays.

Keep in mind this is a rant, so it likely goes over the top a bit. That said, I first hand encountered some of the constructs mentioned here... I find that surprising in such a recent language indeed.

Here is another point of view on the XSLT situation in the WHATWG. Clearly the process needs to be made clearer. I'm not necessarily convinced by everything which is brought forth in this piece, still nice to have different point of views on it.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

Feeling blocked? Maybe try a few of those things on your project.

Or why competitive multiplayer games which anti-cheat probably will never make it to Linux. I'm not into this kind of games but this is an interesting piece on comparing the differences between the Linux and Windows kernels. It also show that with some care from the game developers, those anti-cheats might not be necessary in the first place.

Indeed, let's not fall for the marketing. It's better to write less code if it's enough to solve actual problems.

Interesting, it looks like index scans in your databases can have surprising performance results with SSDs.

The idea is interesting, I wouldn't throw away level based logging but this could complete it nicely.

Long but interesting chapter which shows how GPUs architecture works and the differences with TPUs. This is unsurprisingly written in the context of large models training.

Easy to misunderstand as an elitist stance... But it's not the way I read it. Churning more code faster isn't going to help us, you need to take the time for people to grow and improve. It's not possible to achieve if you're drowning in eager beginners.

Interesting parable, it's indeed a good way to illustrate different leadership styles. Being more strategic is clearly what one should try to do.

A good way to frame the possible models for your organization regarding remote work. The GitLab Handbook stays a very good resource regarding remote work, they really thought about it and documented their findings.

I think this is still one of the best distilled explanation of product ownership. It's also interesting for the other parties on an agile project.

A good reminder that long hours are not a sign of success with your project... on the contrary.