Exactly.

I am old enough to have observed the gradual transformation of sporting activities into extremely predatory commercial monopolies with total media complicity. This is completely abnormal and it’s crazy how many people still don’t understand the extent of the problem, even with so many scandals and abuse stories.

Of course, there is a curiosity to see the best in their respective fields, but people more like to participate and progress by sharing and spending time with others with respect. This community aspect has been completely destroyed by business and the media.

Money and sex seem to be the only things that motivate you.

I'm 53, a father of two adult sons, and I LOVE how people hangout remotely on Twitch. There are a lot of amazing people sharing a part of their lives live, their skills, their art, their travels, their discussions, etc... Twitch and Discord use the same model of moderators and all benefit two from much more respectful communities than on other major 'social' (but actually toxic) network.

We live in a society of social apocalypse incapable of renewing itself and incapable of changing because of the inverted age pyramid. The reality is worse than many expected, with great stress from anxiety-inducing one-way media, wars and AI. Twitch and Discord communities are a kind of reaction that creates peaceful places focused on humans and socialization. There's a reason Youtube and X try to do the same, but they're far behind in the moderation model and the creativity they enable.

Now I wonder how business predators like the South Korean network operator will face satellite networks like Starlink and the others that will arrive.

You're welcome. Two more links you may find interesting:
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
Have a nice day.

https://users.csc.calpoly.edu/...
https://en.wikipedia.org/wiki/...
While the first is clearly a software bug, this is not the case of the second: the pilots did take too many risks and responded too late. The machine operated within the specification of it certification. https://bea.aero/docspa/1988/f... There was multiple manipulations by some medias on the subject of that accident, trying to point out the FBW. If you digs a bit into how the A320 work, you will quickly understand that the alleged alternate explanations are impossible as it's controlled all the time by two completely separate computer systems running different software done by different teams with different languages running on different processors architecture from different manufacturers. Again the machine worked exactly as expected by it certification. The pilot disabled the safety law and manually pushed the machine too low for too long, unaware of the trees, and because there were improvising a demo instead of executing the initial planning demo.

https://en.wikipedia.org/wiki/...
Be curious and use the information first hand each time you can. There is a lot of really good stuff in the Internet, far more than what was available when I was a student, and even if there is a large proportion of useless/fake/conspiracy/generated information today.

Of course, having a redundant, secure computer doesn't magically create bug-free software running on it. :-D

Please verify your information. The crash of the A320 at Mulhouse airport during a demonstration is well documented and has nothing to do with the original subject. Additionally I did not list the A320 in my list, because its safety architecture is different (still much better than the outdated avionics of the B737). There are many materials on this topic on the Internet. Look at the A380 and B777 which ushered in a new era in avionics design architecture. The A350 and B787 use the same general design. So far, these designs have proven to be incredibly reliable and safe over decades of large-scale operation.

Redundant computing is common in modern commercial aircraft designs like the A380, A350, B777 and B787. Their operation over the decades has proven the extreme security of the system even in the event of a node failure. Triple redundancy is very common on rockets and on spacecraft.

Yes, a single piece of hardware can fail, for example due to a radiation-induced bit flip.
This is exactly why secure systems rely on redundant hardware, usually a triplet of computers that compare to each other.
Bug-free software is achievable if the hardware architecture presents no vulnerabilities. If run on redundant and secure hardware, the probability of failure can be incredibly low.

I think in the future we will have a network with multiple layers of redundancies connecting massively redundant nodes, with each node aware of the complete state of the system. The probability of failure will be so low that the risk of such systems will be practically zero compared to other risks.

My experience is very very different. There are many people who think they are professional but are unable to deliver what the project needs, and the main reason is that they lack the motivation to understand the highly technical part of the job. I've seen great resumes with a decade of experience that fail my tech test miserably. These are often people who, in a large organization, were part of a project but were not among the main contributors. On the contrary, I recently said go to two people with very little professional experience but who are literally hackers with an incredible open source culture. They adapt perfectly to the project and they deliver at a high rate.

The only very important point is the technical ability test. I use a C driver source code. The candidate can ask any questions to analyze and explain the code. Then follow 4 tricky questions that only programmers that have delivered and understand real working code in that field can comfortably respond. The questions are accessible to candidates that start there carrier if there have enough motivation to have done some kind of relevant project.

This process work really well. Almost all candidates are doing good presentation of themself. But only about 1/4 of them are able to pass the test in a way that convince me that there will comfortably deliver what the project need. If I say go to my hierarchy, you get a second interview with them, and then a contract proposition if still go for them.

Fully agree.

I don't see any difference: ESR and non-ESR are not the same product branch. You have to choose one branch, then you only look at the version on that branch.
i did not say to not use branch name. What I say will cause the version on each branch to be based on ISO 8601.

You are right obviously.
Using the build version might still be useful to trace the observations bring back by the users before there is an understanding of the cause.

For example: 2023-01-01
It bring a better idea to human.
It can be automated very easily from the commit date.
I usually use a COMMIT_DATE constant in ISO 8601 down to the second UTC
For example: 2023-01-01T00:35:12Z
Very cool for continuous integration build and testing.

You're right, thank for the complement. To me it's evident that the Debian decision to includes xfce as an alternative to Gnome 3 was a powerful boot for the project.

I second that. Gnome 3 and all releases after that are the worst thing that ever happened to the Linux community. Even after a decade of criticisme there still continue to impose an insanely wrong concept that nobody see as a so good idea that it wanted to copy. On the contrary this started a lot of projects against that wrong concept, notably XFCE that I recommend. Even if the default XFCE settings are ridiculous, it's very quick and easy to configure it like a normal powerful desktop.