Yes, but perfectly reliable hardware is impossible and every small gain in reliability drastically increases the price. Luckily, most hardware can be "fixed" by replacing the malfunctioning part. The only part that is not easy to replace is hard drives. For data disks, I have guides giving me step by step institutions on how to rebuild off of replicas. With the OS disk, I am depending on hopes and taking notes while installing.

Broken software is tricker to replace. I can uninstall and reinstall it, but I have to be careful to avoid catastrophic data loss. Also, broken software generally means a bad release, so I have to revert and periodically upgrade/revert to check if the issue has been resolved. And running old versions of one part of the system can cause incompatibility in other parts.

Same. If I am reading for please, I am reading the book sequentially and love the convenience of ebooks. If I am reading a reference or text book, I like being able to quickly flip between (physical) pages and skim previous chapters for a section I want to reread.

For me, it is easier to learn to use git via CLI instead of a UI. When I first started using git, I learned a few command/flag combinations that I use every day and I barely learned anything else about git after. Everything I don't do regularly I don't remember, but have written down in a text file of incantations. It is harder to write down what buttons and what menus I have to click.

I am used to seeing ring buffers implemented using an array. They are FIFO if you write to the maximum offset and read from the minimum offset but they are double ended if you have a method to read from the maximum offset and write to the minimum offset.

I always feel a little paranoid when I explicitly close transactions, connections, and files (for quick running scripts, the OS will close the file when my process exits and for long running applications, the garbage collector will close it when the object leaves the scope). Then I read a blog post like this an remember that it is always better to explicitly free resources when I am done with them.

I have used Kotlin a bit for a hobby project and it felt like they were 95% done with a 1.0 version. I love the promise of a single code base that can run on the JVM and browser, but it is not all there. Until recently, the API was not guaranteed to be stable. Every one in a while, I hit a feature that is JVM only or does work right in JavaScript. The JS compiler will "helpfully" remove uncalled public functions unless you explicitly mark them with JsExport.

Also, from what I can tell, only InteliJ is the only supported IDE (which makes sense, since they are the language developers). There is an official Eclipse Plugin, but the last time I tried it, it did not work and tried to take the entire IDE down with it.

Having said that, it was very close to complete and I have not worked on that project for a few months, so it could all be perfect now.

How is this group feature different from the existing group feature (https://github.blog/changelog/2023-06-30-grouped-version-updates-for-dependabot-public-beta/)? Just that it is no longer a beta feature (i.e. they have settled on the configuration syntax and are re-announcing it)?

That is a bit dismissive of Java developers around the world. There are several of us still left and we are in key positions of power.

I have not done much GoLang development, but I am working on automating some dependency updates for our kubernetes operator. The language may be good, but the ecosystem still feels immature.

Too many key libraries are on version 0.X with an unstable API. Yes, semantic versioning does say that you can have breaking changes in minor (and patch) releases as long as the major version is still 0, but that should be for pre-release libraries, not libraries ment for production use.

I have not read the PEP itself or the PEPs that they claim to simplify, but this feel like a very bad idea that only really benefits Meta and a few other mega servers. It is enabling a micro-optimization that is only usable in a niche use case (forking long running processes with shared memory). Unfortunately, it is making all other python applications, on average, 2% slower. This is a minor regression but it hurts everyone and benefits almost no one.

That should be a disciplinary issue. The engineers in question should be brought forth in front of management to explain why they thought that this particular change should be exempt from testing and why this was not explained, in detail, in the code review.

Also, when you find a script try to understand what commands they are using and with what flags.