There are a lot of distros out there. That is what makes Linux so great. You can roll your own formula of kernel and userland for YOUR needs[and then share it]. You aren't forced to just take what Microsoft or Apple or XXXX gives you nor do you have to completely write your own from scratch.
I am really not liking this newly interventionist moderation regime. It's not just that I disagree with many of the individual decisions (though I do). It's that it's thoroughly capricious, and that makes HN a really unpleasant place to be.
In all seriousness, Poettering is at least trying to replace complexities with simplicities. He thinks unified config files are simpler than ad-hoc shell scripts for init systems. He thinks a sound system that handles all audio in a uniform way is simpler than having a bunch of different APIs that implement a different and incompatible part of the audio stack.
Nobody is trying to make things more complex, or if they are, it's usually a joke like brainfuck.
He thinks unified config files are simpler than ad-hoc shell scripts for init systems.
That's a gross misrepresentation of the problem. Shell-based rc does not have to be "ad-hoc" if there is a sane process management framework in place. In such cases, the scripts can be extremely terse. [1] [2] In essence, the scripts become mere "callbacks" and have their primary purpose to provide the start command line, optionally with some form of chain loading to compose execution state. One can go further and write a small, special-purpose LL(1) command language for chain loading of programs, e.g. execline. The unit file format, conversely, cannot be composed, the options must be treated as static entries, and implicit state is carried, sometimes making service writers resort to horrifically subverting the systemd model just to escape. [3]
I'm not trying to represent the problem nor do I want to discuss the merits of systemd. I am just talking about what Poettering is trying to do and why he says systemd is better. Whether he's actually achieving it is of no relevance to his stated intentions.
It is terrific that your end users are willing to spend the time and effort on building their own BI solutions. In my experience, at least with C-levels, that is not the case at all. C-levels also tend to want the most stuff.
I agree, but I must point out that in some cases the alternative to the "time and effort" involved in the exec playing around with a particular end-user report tool is the time and effort involved in a series of meetings attended by the exec and everyone on the chain between the exec and whoever is actually building the reports.
If "not able to specify a report format to a software service, even with assistance-as-needed from more technical users" disqualified one from executive employment, would any firm actually be hurt by that?
A lot of what you are paying for in BI solutions is implementation costs and then to a lesser extent yearly maintenance and support costs. I wonder how they intend to lower implementation costs, since that is kind of lengthy and inherently difficult process.
One of the things I like most about my Jetta TDLie is that the DSG will downshift if you keep the brakes on for more than about 5 seconds. On long downhills I can take my foot off the brake for about half the trip down and the gearbox does the rest until the speed slowly creeps back up.
We are 12 developers in a room that is half windows opposite an auditorium. We call it the fishbowl. It feels like we are in some sort of science experiment to see how long we can last the indignity.
