RedHat has not won any systemd war. From all the distributions out there using systemd, RedHat is the one that uses the least amount of systemd features.
They are even going so far as disabling features.
Sometimes they even backport systemd features from more recent versions, disable them but leave man pages in the original state.
Even the /usr split isn't progressing at all.
I too find Red Hat's poor documentation hygiene a pain in the arse. But as for the disabled system features, I think that they all fall into the category of experimental/unproven sort of features that overlap with other existing RHEL components. Every enabled feature has a cost in the form of support burden.
Those are not "systemd features", they are components within the systemd suite. Using systemd-init has never required that you use every component within the systemd suite (e.g. ntp, network management, etc.)
When tiling window managers don't work for you, that is totally fine, but I wouldn't say that they are broken and awful. They all have different trade offs, the same as all the Desktop Environments.
I tried a couple tiling window managers many years ago and none was usable in the way I thought how it should work. But instead of investing time to make it work the way I want it, I just switched to the next one and tried that. I think at that time I tried 5 or 6 window managers a day.
The one that worked for me at the end was one written by Sean Pringle called Musca. It used relative movement from each window and it made so much more sense than all others. Sadly he dropped it a bit later for another project but herbstluftwm is its successor and it worked for me.
My config hasn't actually changed for the last 10 years.
There are so many great tools out there we can use for what we want to do. Choose the one you like and works for you.
Thats why peoples desks or their work places all look differently. A smith woulnd't talk to a smelter about his setup being awful, because he does a different job.
I don't understand your analogy. If a smelter is using something in a bad or inefficient way and a smith is capable of explaining it to them, then that would be beneficial to do so. People do not have to do exactly the same job in the exact same way in order to discuss how a specific tool works.
Like you, I went through a period where I tried pretty much every tiling window manager I could find. And I can say with confidence: they are all broken and awful, in part because the very concept of tiling doesn't really work. The design is flawed. It's like you are making a comparison between every jigsaw on the shelf and picking out the best one but are missing that you could get a miter saw and that would work even better for your use case. Does that explain it?
Is musca the one where you divided the screen first, and later could fill specific applications into those areas? I found that pretty cool at the tkme!
It could probably work much better with wayland though, because programs often refused to remain in their little borders.
The problem isn't that 50Mbit/s might be enough. The problem is, that 50Mbit/s isn't everywhere.
Germany is a country which spoutes aloud, that it wants to be one of the leading countries in IT, but in reality, Germany is a developing country in that regard.
Most of the time, only city centers have access to higher bandwidth, the outskirts, smaller cities and most of the country side have very low or no bandwidth at all. The last decades Telekom hat the monopoly with providing connectivity to homes and everyone else was a reseller. But Telekom didn't see the need to modernize their old DSL infrastructure and were happy to let you pay 50 euros per month to provide you 16Mbit/s.
The TV companies could provide higher bandwidth with their newer infrastructure with up to 100Mbit/s, but the country is split between them. So when you were in a bad area, you might have Primacom as a provider and they did stop at 25Mbit/s for a long time.
Now the situation is, that Telekom with all their money is asking the Government to pay for the renovation and they got away with it until the beginning of the year, when they finally said, that DSL will not be supported anymore. Only the fiber will now be supported. But this comes years after some villages got couple 100k Euro together to get at least 50Mbit/s and they still pay a monthly fee of 50Euros.
And the Telekom is not alone with wanting support money from everyone. The southern Rheinland saw multiple providers wanting to connect villages for huge prices, which leads to the weird situation, that southern Rhineland now gets support from a Swiss company. That company doesn't need any money and is still laying fiber through the woods to long forgotten villages.
Compare that with most other European countries, where you can get a fiber connection for the same money with synchronous 100Mbit/s or more. The northern countries with their hard rock grounds did get it working in a much better way than Germany.
And don't rely on LTE, as the LTE tarif were bound to lower GB/month traffic limits and huge costs, as the LTE frequencies were auctioned of between the providers. And the winners couldn't build where they wanted, they had to provide LTE at first where there was no mobile internet available at all, which means on the acres.
Germany is in a sad state in regards to connectivity. And this has nothing to do with people being afraid. If you let the monopolist do whatever it wants and not enforce the modernization, then this is what you can expect.
That does not let me create something from the wiki, only reference issues that already exist.
EDIT:
Specifically, allowing people who are primarily text driven to be reading a doc/wiki page, right click a sentence or phrase, then create an issue right from that screen, without leaving, and have them linked back and forth, is... seemingly obvious, yet I've not seen it done elsewhere. Someone else pointed out gitlab - I've not tried it there yet.
The creation of jira tickets from confluence already seemed useful enough for my use cases - not sure that I'd need a plugin to do more, but interesting to see that you've got something (and to know others want it).
My original post was pointing out that this wiki/ticket connection is something I've only ever seen in jira/confluence, not in anything else.
You can downshift and use the motor for breaking. When doing that, you don't burn any fuel at all, as the kinetic energy of the car will help keep the motor turning.
You have the same effect in automatic transmissions when letting go of the gas pedal.
The last picture shows the commit activity between the various branches. Not sure what the "git" branch, which started to deviate in October, is for though.
Solaris had an init system like systemd for some years, called SMF. It was first released in 2005, the same year Apple released launchd.
It features service dependencies, log collection, fault detection and much more. One of the biggest differences is probably the usage of config files. SMF uses XML files to describe the service and its variables and a program called svcprop to edit variables and create new instances of the service. These can then be managed with svcadm.
I was aware of that, and it wasn't my point. I was talking about the supposed portability of systemd. The question remains, is systemd really Linux-only, or portable to some degree?
HSTORE still is only storing key, value pairs. Nested HSTORE is something we might get in 9.4. JSON/V8 does allow nesting but doesn't allow indexes for arbitrary value access - something that MongoDB easily does.
So depending on your use-case and the type of documents and queries you are dealing with, neither the current HSTORE implementation nor the current JSON implementation will work for you, while MongoDB's model might.
But the reverse is true too: Some use-cases are highly relational and it would be really painful to do that with MongoDB due to the lack of easy joins (you have to do them in your application logic which means a lot more work as your requirements change).
Pick the right tool for the job.
Me personally, I prefer the immense flexibility for querying a relational data set over the flexibility of not having to deal with schemas. The reason is that it's much easier to change or add an SQL query than it is to re-format and re-duplicate all of my data followed by more or less manually implementing as good query plan in application code whenever the requirements change.
See * https://bugzilla.redhat.com/show_bug.cgi?id=1962257 * https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/...
Sometimes they even backport systemd features from more recent versions, disable them but leave man pages in the original state. Even the /usr split isn't progressing at all.
Meanwhile Fedora has implemented all these changes, which according to https://www.redhat.com/en/topics/linux/what-is-centos-stream, should be the upstream for CentOS.
I would say RedHat dropped the ball on systemd and has no intention of supporting any of the new features in any of their systems.