git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space
Yeah, once you realize that everything falls into place.
I believe you can replace start with the command that is suitable for your system (e.g., xdg-open for linux).
Not having any personal projects is perfectly fine. Don't worry about it. Not everyone has to have their job as their hobby. Try other things (music, hiking, cooking, etc.). Try to find a hobby that makes you happy (if you don't already have one). That's way more important than having a public GitHub profile. And if a company decided not to hire you because of that, you basically dodged a bullet.
Who is this particular developer
As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.
I don't follow it very closely, but as far as I know, they are the only one implementing the open protocol they designed (which doesn't interoperate with ActivityPub). However, there seems to be some efforts for creating a bridge: https://www.docs.bsky.app/blog/feature-bridgyfed
As you said, there are some recognizable faces and that may impact the adoption. But not being compatible with ActivityPub is a real bummer.
I no longer look forward to updates.
[...]
It seems to me that some software is actually getting worse, and that this is a more recent trend.
[...]
Why does this happen? I don't know, but my own bias suggests that it's because there's less focus on regression testing. Many of the problems I see look like regression bugs to me. A good engineering team could have caught them with automated regression tests, but these days, it seems as though many teams rely on releasing often and then letting users do the testing.The problem with that approach, however, is that if you don't have good automated tests, fixing one regression may resurrect another.
Every time I see a new update, I think: "I wonder what will break after this update" and postpone them as much as I can. Software updates shouldn't cause anxiety. But they do these days...
I think you have a better chance if your instance focuses on a topic instead of being general purpose. That's the reason I chose programming.dev. All communities there are related to programming so when I sort by "local" I see something interesting even though I haven't subscribed to that community. And that increases my interaction with those communities.
Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.
Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.
Good point. However, approaching this problem from "YAGNI" point of view is a bit misleading, I think. If you are not going to need the timestamp, you shouldn't add it to your code base.
In my opinion, hastiness is the culprit. When a property appears to be a binary one, we jump to the conclusion to use a boolean way too quickly. We should instead stop and ask ourselves if we are really dealing with a situation that can be reduced to a single bit. The point raised by the article is a good example: you may want to record the state change as timestamp. Moreover, in a lot of the cases, the answer is not even binary. The values for is_published may be, "Yes", "No" or "I don't know" (and then we will be too quick to assign null to "I don't know"). Underlying problem is that we don't spend enough time when modeling our problems. And this is a sure way of accumulating technical debt.
Don't they already have the names Leap and Tumbleweed? Changing the name to Leap would make sense since it's the name of the "official LTS" version. At this point it sounds like "openSUSE" is the name of the project and not the distro. But I haven't been following them closely, so perhaps I'm wrong.