Except I would be forced to have the job of landlord, and all sorts of liability and restrictions inherent in that job. If you have a bad tenant, it's not exactly easy to end that customer relationship compared to most other jobs. I don't think I could do that job and my real job effectively, and my real job covers about three times my spending and I have paid off the house.
I'd rather keep my income a separate matter from my living arrangements. It's a bit weird to hear so much discussion about capital gains and such, I really don't have a particular interest in selling my house for financial reasons.
I do not relish the thought of sites going to web assembly. Already BS like Angular and other frameworks and minification makes it challenging to trace third party code, don't want it to get any worse, but maybe it is a lost casue...
On the general argument of type safety (an other related sensibilites), it totally made sense in the beginning when javascript was only used for lightweight page manipulation, and being unforgiving and requiring tedium of the programmer just wasn't worth it. The problem is of course that people are writing massive javascript applications, and that stuff really complicates quality as code complexity grows.
I don't mind requiring newer browsers (a browser that old is likely to have security problems).
But on Promises, what annoys me is that they were heralded as the solution to callback hell, but it's still really hellish and tedious. I don't see a lot of benefit of promises over the previous best case, and they all suck.
Probably would have been better to shorten your discussion on the concrete challenges of running self hosted webapps, since no one is advocating for that, and instead bringing more of the linked articles points into your text (that the publisher has eternal control to impose rental arrangement versus the previous arrangement where the publisher had to actually *do something* to extract more money out of the customer).
There are a few reasons why I avoid using Javascript frameworks:
-They can trip themselves up over time. A framework falling out of favor means it actually starts to not work well with newer browsers. -They royally screw up the browser developer tools ability to debug code -They aren't really that necessary if you don't mind requiring users to have a browser that's at least newer than a couple years old, which is a really good idea given security fixes anyway. I remain dissatisfied with Javascript, but the frameworks don't really do anything to mend the frustrations I have, and the core language gives me about as good syntax as the frameworks now. -They bloat the page download
This is of course what makes javascript more controversial than other languages. If I don't like, say, python, I can write in another language. It's easier to adopt a "live and let live" philosophy.
Inside the browser however, there has been little choice. There are roughly three: -Static site. Note that with CSS alone, a lot can be done to enhance the apparent responsiveness of a site, and it will also be a lot faster and less resource hungry than doing the same things in javascript. -Loading whole pages from a backend instead of the data. this makes for more bandwidth, slower rendering, and general non-dynamic feeling -WebAssembly - Not yet mature, excludes a lot of older browsers, and for the occasion you want an arbitrary third party to be able to trace your site's code, it's not the most friendly thing, but then again, angular, 'minifiers', and so on already ruin java script for that use case.
While DOM manipulation is a bit verbose, and CSS can be weird, Javascript as a general language is not exactly consistent, at least not the way I think of consistent.
One is how it tries to cater to the 'object oriented programming' pattern. Javascript is heavily tilted toward closures, but a lot of programmers struggle with that. Now I think there are at least three general ways of trying to make things easier for OO, and they are all still really hard for people to grasp coming from C++/Java/Python where OO is more well defined into the language syntax. This is similar to Perl's OO, which looks more like they accidentally found a syntax that acts OO as did that instead of doing design around the language.
Another is it plays fast and loose with variable values. In a complex javascript applciation, a bad variable value has a stronger tendency to bounce around incorrect until it finally blows up and it becomes an effort to trace things back to where things went wrong earlier. This is another thing that I'd say is very Perl like, compared to other languages that are more forceful about making sure the programmer *really* meant it. There are always some sorts of problems possible, but the forgiving nature of these languages increase the occurrence. Even with 'use strict' (incidentally, same in javascript and perl...) this is the case.
The final situation is where it tries to be forgiving with quoted strings or omitting the quotes. For example, if you have "var a = "key"": both: b = {a: 1} b = {"a": 1}
produce the same object, with string "a" as the key, rather than the unquoted value being used as a variable name. Javascript is chock full of little forgiving things that tend to help simple code work without being anal to the programmer, but explode as you get to larger complex code.
It was less about programming GUI applications and more about distributing and installing gui applications. Over time, the security model also became a key factor as well.
The world might have been a very different place if microsoft *ever* cared about having decent package management. As it stands, getting an executable running under an arbitrary user's desktop is an exercise in excessive bundling of third party dependencies (because you can't ask the OS to resolve it for you), install wizards that make a big deal over the most trivial of app install, and as security evolved, the joy of code signing, anti-virus that assumes all new software is suspicuous, and so on.
Of course on the security front, all the desktop platforms are still in the general permissions model of the 80s: all user content is roughly equivalent. The mobile platforms have made some good permission decisions, like apps not being able to access files from other apps by default and such. On the desktop however, security policies have been implemented in hamfisted ways that make it far easier to make a web app and roll with the security model in the browsers, which seem to make all the anti-virus vendors happy.
It's probably a reference to Prop65, which specifically does enable a company to not get sued, so long as there is the prop65 warning on it. This narrowly applies to prop65 specific cancer things (not any claims about non-ionizing radiation), but it is the poster child for ineffectual crying wolf to not get sued in California.
It has no teeth because pretty much everything has that label. Many companies add the label as a matter of course, even if they don't have any of the relevant chemicals in some products because it's easier to apply the label to everything than keep track of whether they need to or not. Additionally, some of the chemicals on the list are about as likely to cause cancer as non-ionizing radiation.
Heck even contact with most shipping pallets can cause a package to be contaminated with formaldehyde enough to be detected in some of the tests, so a company without a warning could be at risk from that despite it being a shipping company's fault.
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors selection criteria, there's no credible commercial alternative. BSD, devuan, slackware, and so forth are not viable from a support perspective. We have two alternative at least somewhat credible enterprise distributions that are not RedHat, but both of them are the same as RedHat.
Also, if majority rules, then at least on the desktop everyone working on Linux desktop should hang it up and go home, because Microsoft has so much of the market.
Finally, diplomacy and compromise can go a long way to mitigating vitriolic discussion and improving the relationship with those begrudgingly coping with your software and ranting on the internet. When one of my projects made a rather controversial change, we listened to feedback and made those who were starting to froth at the mouth content by adding some configurability to restore behavior they liked. It wasn't a particularly tall order and it would have been more trouble to argue it that to just accommodate. As a result, no one complains about the changes in that project because they have a convenient way to go about things the way they like. Being dismissive and calling all those who want to see improvements "whiners" is not the way to deliver a good project and make people happy with it.
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and state of a system is entirely a man made construct with no objective 'good' or 'bad' about it.
Sometimes that means choices, and you have to pick the subset you'll want to piss off least. For example, perhaps some features that people may have a high opinion of just isn't compatible with the tastes of those who like the fact they understand all that init is doing, even if it doesn't do much. You have to pick to some extent who to make happy. Of course, along the way you may be able to pull off the former while mitigated how concerned the latter group is, but that's a nuanced and convoluted discussion.
Other times, that doesn't mean a forced choice and both sets of dominant sensibilities can be satisfied, e.g. text processing friendly logs, and more structured logging. Here one set of people may think the other's opinion is silly, but they aren't going to go on big rants about it so long as their tastes are satisfied. Part of this is making sure neither preference is relegated to being an obvious second class citizen in the experience.
None of these are insurmountable technical problems, but they do require some shred of humility and diplomacy to appease a large set of people. The current situation just makes folks froth at the mouth and become incoherent as they see their preferences discarded along the way, and also attracts the sort of folks who enjoy setting people off.
A user can reasonably select a desktop environment and the package maintainers can have their output consumed or ignored in that case.
Things like the kernel, init, user session management, low level graphics frameworks, and so on are not so easily swapped around by the users.
So the only choice people have is to select an entirely different distribution, which can suck if the 'only' thing you dislike is the init system, but you *really* prefer that distros packaging or release and support strategy otherwise..
-It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, without good
This reminds me that not all that people experience is systemd's fault. Here the analogy would be dconf.
Ironically, the windows registry is given a *more* filesystem like presentation in powershell than dconf is given by anything. It's exceptionally weird that the platform where 'everything is a file' has drifted away from that philosophy and Microsoft drifted a bit closer to it (though it seemed only temporary, they were talking about a lot of PSDrives, and they seemed to have dropped that..)/
Of course eventviewer still makes journald look crazy better by comparison.
But the short of it, dbus, systemd, dconf, and others are overall responsible for bringing some of the dubious windows design sensibilities over, not just systemd.
Systemd has three fundamental issues: -It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of which systemd has had a fair share). -Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out. It's one thing to not catch such a scenario, but for your *gut* reaction to be "oh yeah, you are doing it wrong, nothing should have let you do that", implication there that he's just *trying* to make life hard for systemd. Most people immediately recognize a security problem is something that *must* contend with unclean input. This is also why journald continues to have no native text logging. Instead of engaging with the community to create a best of both worlds solution with both human readable text and high performance indexing and *some* mild defense against tampering (only real solution to that is one-way append-only logging to an external part). Instead, the reaction is "you guys are idiots" and those use cases are ignored. It's one thing to have a rough start, but if there continues to be this much vitriol around a project this many years on, the project has screwed up their relationship to the community. -It also becomes the poster child for a lot of other design changes that are common to the distros, but may not even be systemd related. Sometimes exacerbated by systemd (dbus), but largely not particularly the projects fault. However it has the curse of being very visible and loud and can attract other problems with systemd complaints.
Things that have come from that include: -Unreasonable disdain for text format logging. Rather than pursue a compromise where text data is a first class citizen, they say 'just schedule dumps to a text file ever so often' or '*add* syslog *and* journald'. There is clear disdain for the whole idea of a format that doesn't require a specific tool to read, despite reasonable proposals to do things like externalized binary metadata to preserve the best of both worlds. -Unreasonably drawn out vulnerabilities while they spend sometimes months complaining about it being intentional instead of fixing it. -Inability to allow a user to select a deterministic boot mode. Yes, properly done dependencies are the 'right' way to solve, but some folks would rather have a deterministic boot than contend with unknown race conditions. It would be a simple matter to have a serialized boot behavior with a very deterministic approach to serializing services consistently that do not seem to rely upon each other.
It also becomes a matter of controversy because it does bring value, and attract people to white knight for it: -Faster boot, not everyone cares, so this being optional would be an easy thing to do to make folks happy -Fast and structured log analysis, which could have been done with external metadata to keep text analysis feasible. -Intelligent use of cgroups to keep reasonable tabs on a process -Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software -Encapsulating the overwhelmingly common startup scenarios as a config file instead of rewriting the same basic scipt over and over. So long as
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
This is one of the things that frustrates me, they didn't need to make it a binary format to acheive those ends. It's not like text records cannot accommodate such feats. It's also not as if you must embed the binary and text data in the same file to acheive performance gains (I maintain that segregating the data would have made for even faster indexing).
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Well, there is at least a kernel of something in that first sentence... Small teams can be often far more effective than a large team. Trying to overcome limitations through quantity of developers won't win the day.
Take an arbitrary well established and known project with 'thousands' of contributors. They will almost all have about six to twelve people carrying the project, and a thousand trivial commits for little things, mainly for resume boosting.
Of course, that exists (Sixel) and could be improved upon (more efficient format, some way to make binary data ok so that you don't lose 25% of bandwidth to base64). Also, mouse support is also there (though it usually annoys me more than it helps me). So the things one could logically imagine are there, albeit in crappy form, and could be extended to be more sane...
However, even if these *were* ubiquitous, then you have the problem of multiple windows, focus, input grabbing, not allowing input grabbing, more input devices, compositing, interacting with the graphics crad to accelerate primitives, communicating information about 'systray' like presentation, and a host of other things I can't even think of.
It also ignores the fact that SSH offers far more extensible and flexible solutions than just the tried and true escaping things over the textual streams, even if trying to speak on these terms, which would be a far more sane thing to chatter about (the sort of thing that became ssh -X, for example).
Slashdot Mirror
Except I would be forced to have the job of landlord, and all sorts of liability and restrictions inherent in that job. If you have a bad tenant, it's not exactly easy to end that customer relationship compared to most other jobs. I don't think I could do that job and my real job effectively, and my real job covers about three times my spending and I have paid off the house.
I'd rather keep my income a separate matter from my living arrangements. It's a bit weird to hear so much discussion about capital gains and such, I really don't have a particular interest in selling my house for financial reasons.
Also those repair expenses that you don't have to worry about? You worry about it in every rent check.
I do not relish the thought of sites going to web assembly. Already BS like Angular and other frameworks and minification makes it challenging to trace third party code, don't want it to get any worse, but maybe it is a lost casue...
On the general argument of type safety (an other related sensibilites), it totally made sense in the beginning when javascript was only used for lightweight page manipulation, and being unforgiving and requiring tedium of the programmer just wasn't worth it. The problem is of course that people are writing massive javascript applications, and that stuff really complicates quality as code complexity grows.
I don't mind requiring newer browsers (a browser that old is likely to have security problems).
But on Promises, what annoys me is that they were heralded as the solution to callback hell, but it's still really hellish and tedious. I don't see a lot of benefit of promises over the previous best case, and they all suck.
Probably would have been better to shorten your discussion on the concrete challenges of running self hosted webapps, since no one is advocating for that, and instead bringing more of the linked articles points into your text (that the publisher has eternal control to impose rental arrangement versus the previous arrangement where the publisher had to actually *do something* to extract more money out of the customer).
There are a few reasons why I avoid using Javascript frameworks:
-They can trip themselves up over time. A framework falling out of favor means it actually starts to not work well with newer browsers.
-They royally screw up the browser developer tools ability to debug code
-They aren't really that necessary if you don't mind requiring users to have a browser that's at least newer than a couple years old, which is a really good idea given security fixes anyway. I remain dissatisfied with Javascript, but the frameworks don't really do anything to mend the frustrations I have, and the core language gives me about as good syntax as the frameworks now.
-They bloat the page download
This is of course what makes javascript more controversial than other languages. If I don't like, say, python, I can write in another language. It's easier to adopt a "live and let live" philosophy.
Inside the browser however, there has been little choice. There are roughly three:
-Static site. Note that with CSS alone, a lot can be done to enhance the apparent responsiveness of a site, and it will also be a lot faster and less resource hungry than doing the same things in javascript.
-Loading whole pages from a backend instead of the data. this makes for more bandwidth, slower rendering, and general non-dynamic feeling
-WebAssembly - Not yet mature, excludes a lot of older browsers, and for the occasion you want an arbitrary third party to be able to trace your site's code, it's not the most friendly thing, but then again, angular, 'minifiers', and so on already ruin java script for that use case.
While DOM manipulation is a bit verbose, and CSS can be weird, Javascript as a general language is not exactly consistent, at least not the way I think of consistent.
One is how it tries to cater to the 'object oriented programming' pattern. Javascript is heavily tilted toward closures, but a lot of programmers struggle with that. Now I think there are at least three general ways of trying to make things easier for OO, and they are all still really hard for people to grasp coming from C++/Java/Python where OO is more well defined into the language syntax. This is similar to Perl's OO, which looks more like they accidentally found a syntax that acts OO as did that instead of doing design around the language.
Another is it plays fast and loose with variable values. In a complex javascript applciation, a bad variable value has a stronger tendency to bounce around incorrect until it finally blows up and it becomes an effort to trace things back to where things went wrong earlier. This is another thing that I'd say is very Perl like, compared to other languages that are more forceful about making sure the programmer *really* meant it. There are always some sorts of problems possible, but the forgiving nature of these languages increase the occurrence. Even with 'use strict' (incidentally, same in javascript and perl...) this is the case.
The final situation is where it tries to be forgiving with quoted strings or omitting the quotes. For example, if you have "var a = "key"":
both:
b = {a: 1}
b = {"a": 1}
produce the same object, with string "a" as the key, rather than the unquoted value being used as a variable name. Javascript is chock full of little forgiving things that tend to help simple code work without being anal to the programmer, but explode as you get to larger complex code.
It was less about programming GUI applications and more about distributing and installing gui applications. Over time, the security model also became a key factor as well.
The world might have been a very different place if microsoft *ever* cared about having decent package management. As it stands, getting an executable running under an arbitrary user's desktop is an exercise in excessive bundling of third party dependencies (because you can't ask the OS to resolve it for you), install wizards that make a big deal over the most trivial of app install, and as security evolved, the joy of code signing, anti-virus that assumes all new software is suspicuous, and so on.
Of course on the security front, all the desktop platforms are still in the general permissions model of the 80s: all user content is roughly equivalent. The mobile platforms have made some good permission decisions, like apps not being able to access files from other apps by default and such. On the desktop however, security policies have been implemented in hamfisted ways that make it far easier to make a web app and roll with the security model in the browsers, which seem to make all the anti-virus vendors happy.
For example, Debian's SysV init scripts:
https://wiki.debian.org/LSBIni...
X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]
provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.
It's probably a reference to Prop65, which specifically does enable a company to not get sued, so long as there is the prop65 warning on it. This narrowly applies to prop65 specific cancer things (not any claims about non-ionizing radiation), but it is the poster child for ineffectual crying wolf to not get sued in California.
Someone needs to put a prop65 label on the sun.
The problem is that strategy causes no one to take California's concerns remotely seriously.
For example, prop 65 warnings are on everything and everywhere:
https://media.licdn.com/mpr/mp...
It has no teeth because pretty much everything has that label. Many companies add the label as a matter of course, even if they don't have any of the relevant chemicals in some products because it's easier to apply the label to everything than keep track of whether they need to or not. Additionally, some of the chemicals on the list are about as likely to cause cancer as non-ionizing radiation.
Heck even contact with most shipping pallets can cause a package to be contaminated with formaldehyde enough to be detected in some of the tests, so a company without a warning could be at risk from that despite it being a shipping company's fault.
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
The goalpost keeps moving here...
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors selection criteria, there's no credible commercial alternative. BSD, devuan, slackware, and so forth are not viable from a support perspective. We have two alternative at least somewhat credible enterprise distributions that are not RedHat, but both of them are the same as RedHat.
Also, if majority rules, then at least on the desktop everyone working on Linux desktop should hang it up and go home, because Microsoft has so much of the market.
Finally, diplomacy and compromise can go a long way to mitigating vitriolic discussion and improving the relationship with those begrudgingly coping with your software and ranting on the internet. When one of my projects made a rather controversial change, we listened to feedback and made those who were starting to froth at the mouth content by adding some configurability to restore behavior they liked. It wasn't a particularly tall order and it would have been more trouble to argue it that to just accommodate. As a result, no one complains about the changes in that project because they have a convenient way to go about things the way they like. Being dismissive and calling all those who want to see improvements "whiners" is not the way to deliver a good project and make people happy with it.
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and state of a system is entirely a man made construct with no objective 'good' or 'bad' about it.
Sometimes that means choices, and you have to pick the subset you'll want to piss off least. For example, perhaps some features that people may have a high opinion of just isn't compatible with the tastes of those who like the fact they understand all that init is doing, even if it doesn't do much. You have to pick to some extent who to make happy. Of course, along the way you may be able to pull off the former while mitigated how concerned the latter group is, but that's a nuanced and convoluted discussion.
Other times, that doesn't mean a forced choice and both sets of dominant sensibilities can be satisfied, e.g. text processing friendly logs, and more structured logging. Here one set of people may think the other's opinion is silly, but they aren't going to go on big rants about it so long as their tastes are satisfied. Part of this is making sure neither preference is relegated to being an obvious second class citizen in the experience.
None of these are insurmountable technical problems, but they do require some shred of humility and diplomacy to appease a large set of people. The current situation just makes folks froth at the mouth and become incoherent as they see their preferences discarded along the way, and also attracts the sort of folks who enjoy setting people off.
A user can reasonably select a desktop environment and the package maintainers can have their output consumed or ignored in that case.
Things like the kernel, init, user session management, low level graphics frameworks, and so on are not so easily swapped around by the users.
So the only choice people have is to select an entirely different distribution, which can suck if the 'only' thing you dislike is the init system, but you *really* prefer that distros packaging or release and support strategy otherwise..
-It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, without good
This reminds me that not all that people experience is systemd's fault. Here the analogy would be dconf.
Ironically, the windows registry is given a *more* filesystem like presentation in powershell than dconf is given by anything. It's exceptionally weird that the platform where 'everything is a file' has drifted away from that philosophy and Microsoft drifted a bit closer to it (though it seemed only temporary, they were talking about a lot of PSDrives, and they seemed to have dropped that..)/
Of course eventviewer still makes journald look crazy better by comparison.
But the short of it, dbus, systemd, dconf, and others are overall responsible for bringing some of the dubious windows design sensibilities over, not just systemd.
Systemd has three fundamental issues:
-It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of which systemd has had a fair share).
-Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out. It's one thing to not catch such a scenario, but for your *gut* reaction to be "oh yeah, you are doing it wrong, nothing should have let you do that", implication there that he's just *trying* to make life hard for systemd. Most people immediately recognize a security problem is something that *must* contend with unclean input. This is also why journald continues to have no native text logging. Instead of engaging with the community to create a best of both worlds solution with both human readable text and high performance indexing and *some* mild defense against tampering (only real solution to that is one-way append-only logging to an external part). Instead, the reaction is "you guys are idiots" and those use cases are ignored. It's one thing to have a rough start, but if there continues to be this much vitriol around a project this many years on, the project has screwed up their relationship to the community.
-It also becomes the poster child for a lot of other design changes that are common to the distros, but may not even be systemd related. Sometimes exacerbated by systemd (dbus), but largely not particularly the projects fault. However it has the curse of being very visible and loud and can attract other problems with systemd complaints.
Things that have come from that include:
-Unreasonable disdain for text format logging. Rather than pursue a compromise where text data is a first class citizen, they say 'just schedule dumps to a text file ever so often' or '*add* syslog *and* journald'. There is clear disdain for the whole idea of a format that doesn't require a specific tool to read, despite reasonable proposals to do things like externalized binary metadata to preserve the best of both worlds.
-Unreasonably drawn out vulnerabilities while they spend sometimes months complaining about it being intentional instead of fixing it.
-Inability to allow a user to select a deterministic boot mode. Yes, properly done dependencies are the 'right' way to solve, but some folks would rather have a deterministic boot than contend with unknown race conditions. It would be a simple matter to have a serialized boot behavior with a very deterministic approach to serializing services consistently that do not seem to rely upon each other.
It also becomes a matter of controversy because it does bring value, and attract people to white knight for it:
-Faster boot, not everyone cares, so this being optional would be an easy thing to do to make folks happy
-Fast and structured log analysis, which could have been done with external metadata to keep text analysis feasible.
-Intelligent use of cgroups to keep reasonable tabs on a process
-Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software
-Encapsulating the overwhelmingly common startup scenarios as a config file instead of rewriting the same basic scipt over and over. So long as
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
This is one of the things that frustrates me, they didn't need to make it a binary format to acheive those ends. It's not like text records cannot accommodate such feats. It's also not as if you must embed the binary and text data in the same file to acheive performance gains (I maintain that segregating the data would have made for even faster indexing).
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Well, there is at least a kernel of something in that first sentence... Small teams can be often far more effective than a large team. Trying to overcome limitations through quantity of developers won't win the day.
Take an arbitrary well established and known project with 'thousands' of contributors. They will almost all have about six to twelve people carrying the project, and a thousand trivial commits for little things, mainly for resume boosting.
Of course, that exists (Sixel) and could be improved upon (more efficient format, some way to make binary data ok so that you don't lose 25% of bandwidth to base64). Also, mouse support is also there (though it usually annoys me more than it helps me). So the things one could logically imagine are there, albeit in crappy form, and could be extended to be more sane...
However, even if these *were* ubiquitous, then you have the problem of multiple windows, focus, input grabbing, not allowing input grabbing, more input devices, compositing, interacting with the graphics crad to accelerate primitives, communicating information about 'systray' like presentation, and a host of other things I can't even think of.
It also ignores the fact that SSH offers far more extensible and flexible solutions than just the tried and true escaping things over the textual streams, even if trying to speak on these terms, which would be a far more sane thing to chatter about (the sort of thing that became ssh -X, for example).