If I ever wanted to follow a career in law enforcement - I would only even CONSIDER doing it in a country where teh police do NOT carry guns.
That's most civilized countries.
Intriguingly it doesn't seem to cause the anarchy you seem to fear it would. The UK doesn't arm police - they ONLY get given guns for specific, known-dangerous operations and have to give them back after the op. They patrol unarmed.
Since 2000 only 3 people have been shot by police in the UK - and nobody is therefore accusing the UK police of being trigger happy and wondering if there is maybe too many for it all to be legitimate ? Oh, and they have a LOT less cops who GET shot than the US police as well.
So, to answer your question - I would refuse to be a cop WITH a gun.
Where is the evidence that he had an assault record ? Oh right, he didn't.
Even if you are right about guns. So. Fucking. What.
He was American - he had a constitutional right to own a gun if he wanted to.
You do know that black people have that right as well ? Right ?
Amazing how the SAME people who keep fighting even the most basic of common sense gun regulations ALSO keep claiming that "I thought he had a gun" is a justification for killing somebody !
And what exactly was Tamir Rice guilty off ? 12-year old kid with a BB-gun. Even if it had been a REAL gun - why shoot him ? Isn't gun rights supposed to be enshrined in the constitution ?
It's not like he was threatening anybody, there's video that shows he did nothing wrong.
For that matter, what exactly did John Crawford do wrong ?
I could keep going -but the fact is even if you were right about Brown - I can list a hundred names of people killed where it's absolutely, provable that they did nothing wrong- and where no cop faced any justice.
More like second-in-charge of their legal department. Considering how Verizon loves to sue the F.C.C. - it's entirely likely that, in quite a few lawsuits, the current head of the F.C.C. was the main company lawyer for the plaintiff (although it's unlikely he acted in court directly - that usually gets farmed out to specialised trial lawyers but those work very closely with in-house council in lawsuits).
Not that this is particularly unusual now. The current head of the EPA had previously sued the EPA 14 times !
And if he's "trust telco provider" is Verizon I'm not even sure that's true. The company has been rated "worst company in America" for 3 years running.
People trust used car dealers more than they trust telcos for fucks sake ! And nobody trusts a used car dealer.
Now whether people in general trust congress more or less (or just trust the other party's congresspeople more or less) I don't know - but an apples to apples comparison is really to compare telcos to other businesses - and there is no business less trusted than telcos anyway.
Your mistake is to think that regulations are anything other than law and order to ensure civility.
That's exactly what they are, so by your own definition, this IS part of government's job. Just because the particular type of laws are specialized to deal some unique circumstances that don't really exist with individuals doesn't make them any less about maintaining order and civility.
You can poison somebody, maybe a few if you are very good at getting away with it. A corporation can poison millions of people in a day for about a penny each and consider it well worth while, all while shielded by limited liability laws (which to be fair, may actually have some merit and could indeed be as claimed much more good than bad). That's a unique circumstance - so we make specialized laws for that circumstance.
If I have a complaint about regulation it's that it tends to go in the opposite direction of where it should: we shouldn't have less regulation, we should make the punishment for violating existing regulations much, much harsher. The principle of equality before the law demands that, if a company does anything bad, it's CEO should face the same punishment I would face for doing the same thing - multiplied by the much larger number of victims.
When every CEO who dumps toxic waste in a river gets the same death penalty (or life in prison) I would get if I poisoned you - nobody will dump toxins in a river. The problem with regulation is that it, all too often, allows the CEO to get away with a fine for crimes that you and I would get a lifetime in prison or even executed for. That problem however cannot be fixed with deregulation - it can only be fixed by making the punishment for violating regulations much, much harder so it's in line with criminal law.
I'll give you the reason Thomas Jefferson gave when he first proposed an estate tax: to protect America from the tendency of society to develop aristocracies.
Even if you are right it doesn't follow that text config files belong in/usr/lib does it? That's where libraries go. At the very least if it had to be under/usr it ought to have been in/usr/share/SystemD
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else. Capturing stdout was never actually a good thing. It's not supposed to be logged. It's supposed to be read live if you manually start a command and contain information only useful in that scenario. A well written daemon will not write anything to stdout at all unless you specify foreground running in which case it should give debug level info.
I didn't work with gentoo's init enough to comment on it.
Supervisord is a prime example of why systemD is a bad design. It's a terrible init approach... For almost but not quite every use case. But for what it is designed for its absolutely brilliant, indeed better than anything else I have seen.
Thats exactly where systemD annoys me, no single program can ever be the best for every use case, so having a program that is so tightly coupled to so much of the system that it's hardly possible to replace it (and trying means weird breakages in utterly unrelated software) is terrible because it inevitably forces a bunch of use case to use inferior software.
We have apache and nginx and haproxy and there is great overlap in what they do but none can fully replace the others. Haproxy is simply a better load balancer than the others if your use case is complex because it's specialized and thus has far more powerful features. Apache is still better at doing things like tomcat hosting and nginx is deservedly popular because it's great. But nothing in nginx says if I use it for web hosting I cannot use haproxy for load balancing despite nginx also having loads balancing features. If I need the extra power of the specialized tool nothing in either stops me combining them. That's how it should be. The job should dictate the tool, nothing else. There must be standards about how tools talk to each other, how they respond to signals etc. But never standard tools. The task should determine the tool and no tool should make it difficult to swap out a component when a task would be better served by a different one. There is no such thing as a best program. There is only the best program for what I am doing right now.
I've never found journalctl to contain anything that wasn't in/var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have been in EVERY distro - each distro should have been using the one best suited to the use-cases and target markets that distro was aimed at.
Mostly these are packages that predate the establishment of the/etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process. Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian standards - other distros are a bit more lax about it).
But SystemD is not archaic, and it's not a small third-party package whose developers are few in number and perhaps just don't care or know about the standard. It's a major system component, which has pushed itself as an irreplaceable part of every major distro now. Surely such a component of all things should try to comply with good practise and standards ? Surely the the bar should be higher for a component that aims to replace most of the other components in a linux system ?
But SystemD has never cared about best practise or standards or legacy of any kind. They do whatever the hell they want and everybody else has to either adapt to whatever THEY decided is how we WILL work - or we have to go to the extreme effort now required to avoid them.
That's the opposite of how it's supposed to work. You want your code in a distro ? On my PC ? You should be adapting to the distro's standards, and to MY needs and desires - if you can't do either, then you belong on neither. Upstream should not get to dictate to downstream, that's the way of closed-source software. The entire point and purpose of free and open source software is the opposite: that downstream should be in control of itself, which requires that the only possible path to acceptance for upstream must be to comply with the wishes and standards that downstream establishes.
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thing and do it well", "Simple pipes and text-based configs and communications. It's because this has been the single most succesfull development philosophy is the history of computer science. Unix is now almost 50 years old - no other OS that old is still in active use. It runs on everything from massive server-farms and mainframes to cellphones. Doing widely disparate jobs and it adapts to all these completely different usage scenarios. Just within Linux you have GNU stacks, you have the JAVA based android stack, you have busybox - if you feel like it you can build a system by compiling BSD utilities from source on a Linux kernel and build BSD/Linux - nothing stops you (the only reason you can't go download that is because nobody has wanted it badly enough to maintain such a system - but there's nothing stopping you from making one).
The reason it can adapt is that philosophy - because it's made up of simple drop-in-and-replace programs you CAN adapt it for any use-case. The unix philosophy is very much the software equivalent of an old-style giant bucket of legos. You can drop and in and replace any brick with any other, the pieces are all ridiculously simple but they can connect to each other in well-understood ways and you can build truly magnificent structures by coupling all these simple pieces together in arbitrary ways. SystemD violates that approach entirely. And so you get the very issue you describe - in one of the most common use-cases it works quite well, in the other most common use-case it works a lot less well - and in the millions of niche use-cases... it fails entirely, because I can't no longer take individual components and arbitrarily swap them out, or put them together in arbitrarily different ways. The Unix philosophy is to give you a bucket of lego bricks so you can build whatever you need. SystemD is more like the modern lego-kits, sure it may give you a prettier model of the death-star, but you can't build a model Boeing 747 from the same kit. The lego company apparently decided they'll make more money selliing people single-purpose kits than buckets they can play with for decades and build anything with - it doesn't mean the buckets weren't a far superior product.
And that's a real issue- because even the one use-case it's great at isn't static (not to mention it's a shrinking part of the market - I suspect it's only a matter of time before only programmers, gamers and engineers have desktops at all anyway) - the needs there will change in time, it may change very radically, and it's impossible to predict how it will change. For Microsoft it meant having to rewrite their entire API from scratch in the mid-2000s because it simply could no longer do what their market required, systemD is now creating the groundwork for the same thing happening to Linux in the end - because it's not small, generic blocks you can put together differently to meet new needs when they arrive, you either have to extend systemD to support those needs - or if it cannot be logically be extended that way, you'll have to abandon it entirely and write an all new system ! That's a very real issue - and one there is no good answer for.
So, unfortunately, that leads me to predict that systemD is more likely to get worse than better - the more our needs evolve, the harder it will be for such a large all-encompassing and interconnected project to evolve along.
No. I didn't change anything. No configs, editable or otherwise, should exist outside/etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under/usr as being) belong under/etc/default. They no more belong under/usr than the similar files installed by a thousand other packages do.
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them. Config outside/etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally./use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user. A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running. SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system
Your accusation actually makes no sense. How can you accuse the democrats of being unwilling to compromise and negotiate when the entire legislative approach of republicans have been to preclude the possibility? How do you negotiate on a bill when they won't let you read it? How do you offer ammendments or debate when the bills are secret until hours before the vote? Forget 2 years of negotiating major bills, Republicans refuse to offer 2 hours. Even most fellow Republicans don't get to know what they will be asked to vote on!
Slashdot Mirror
If I ever wanted to follow a career in law enforcement - I would only even CONSIDER doing it in a country where teh police do NOT carry guns.
That's most civilized countries.
Intriguingly it doesn't seem to cause the anarchy you seem to fear it would. The UK doesn't arm police - they ONLY get given guns for specific, known-dangerous operations and have to give them back after the op.
They patrol unarmed.
Since 2000 only 3 people have been shot by police in the UK - and nobody is therefore accusing the UK police of being trigger happy and wondering if there is maybe too many for it all to be legitimate ?
Oh, and they have a LOT less cops who GET shot than the US police as well.
So, to answer your question - I would refuse to be a cop WITH a gun.
Where is the evidence that he had an assault record ? Oh right, he didn't.
Even if you are right about guns. So. Fucking. What.
He was American - he had a constitutional right to own a gun if he wanted to.
You do know that black people have that right as well ? Right ?
Amazing how the SAME people who keep fighting even the most basic of common sense gun regulations ALSO keep claiming that "I thought he had a gun" is a justification for killing somebody !
And what exactly was Tamir Rice guilty off ? 12-year old kid with a BB-gun. Even if it had been a REAL gun - why shoot him ? Isn't gun rights supposed to be enshrined in the constitution ?
It's not like he was threatening anybody, there's video that shows he did nothing wrong.
For that matter, what exactly did John Crawford do wrong ?
I could keep going -but the fact is even if you were right about Brown - I can list a hundred names of people killed where it's absolutely, provable that they did nothing wrong- and where no cop faced any justice.
Where exactly is it being "forced" onto anybody's roof ? People are offered a deal, they can either take it or leave it.
More like second-in-charge of their legal department. Considering how Verizon loves to sue the F.C.C. - it's entirely likely that, in quite a few lawsuits, the current head of the F.C.C. was the main company lawyer for the plaintiff (although it's unlikely he acted in court directly - that usually gets farmed out to specialised trial lawyers but those work very closely with in-house council in lawsuits).
Not that this is particularly unusual now. The current head of the EPA had previously sued the EPA 14 times !
It's not accurate to call this a "relaxing of federal rules" - if anything it's a retightening of federal rules that were recently relaxed !
And if he's "trust telco provider" is Verizon I'm not even sure that's true. The company has been rated "worst company in America" for 3 years running.
People trust used car dealers more than they trust telcos for fucks sake ! And nobody trusts a used car dealer.
Now whether people in general trust congress more or less (or just trust the other party's congresspeople more or less) I don't know - but an apples to apples comparison is really to compare telcos to other businesses - and there is no business less trusted than telcos anyway.
Your mistake is to think that regulations are anything other than law and order to ensure civility.
That's exactly what they are, so by your own definition, this IS part of government's job. Just because the particular type of laws are specialized to deal some unique circumstances that don't really exist with individuals doesn't make them any less about maintaining order and civility.
You can poison somebody, maybe a few if you are very good at getting away with it. A corporation can poison millions of people in a day for about a penny each and consider it well worth while, all while shielded by limited liability laws (which to be fair, may actually have some merit and could indeed be as claimed much more good than bad). That's a unique circumstance - so we make specialized laws for that circumstance.
If I have a complaint about regulation it's that it tends to go in the opposite direction of where it should: we shouldn't have less regulation, we should make the punishment for violating existing regulations much, much harsher.
The principle of equality before the law demands that, if a company does anything bad, it's CEO should face the same punishment I would face for doing the same thing - multiplied by the much larger number of victims.
When every CEO who dumps toxic waste in a river gets the same death penalty (or life in prison) I would get if I poisoned you - nobody will dump toxins in a river.
The problem with regulation is that it, all too often, allows the CEO to get away with a fine for crimes that you and I would get a lifetime in prison or even executed for.
That problem however cannot be fixed with deregulation - it can only be fixed by making the punishment for violating regulations much, much harder so it's in line with criminal law.
how all lawmakers are exactly the same on every issue.
Go on, say it.
I dare you.
Today I learned that "conversations of slashdot" are consider "coding" by some people...
I'll give you the reason Thomas Jefferson gave when he first proposed an estate tax: to protect America from the tendency of society to develop aristocracies.
Til trying to avert a deadly catastrophe using a 30 year old law is a 'power grab'.
Even if you are right it doesn't follow that text config files belong in /usr/lib does it? That's where libraries go. At the very least if it had to be under /usr it ought to have been in /usr/share/SystemD
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else.
Capturing stdout was never actually a good thing. It's not supposed to be logged. It's supposed to be read live if you manually start a command and contain information only useful in that scenario. A well written daemon will not write anything to stdout at all unless you specify foreground running in which case it should give debug level info.
I didn't work with gentoo's init enough to comment on it.
Supervisord is a prime example of why systemD is a bad design. It's a terrible init approach... For almost but not quite every use case. But for what it is designed for its absolutely brilliant, indeed better than anything else I have seen.
Thats exactly where systemD annoys me, no single program can ever be the best for every use case, so having a program that is so tightly coupled to so much of the system that it's hardly possible to replace it (and trying means weird breakages in utterly unrelated software) is terrible because it inevitably forces a bunch of use case to use inferior software.
We have apache and nginx and haproxy and there is great overlap in what they do but none can fully replace the others. Haproxy is simply a better load balancer than the others if your use case is complex because it's specialized and thus has far more powerful features. Apache is still better at doing things like tomcat hosting and nginx is deservedly popular because it's great.
But nothing in nginx says if I use it for web hosting I cannot use haproxy for load balancing despite nginx also having loads balancing features. If I need the extra power of the specialized tool nothing in either stops me combining them.
That's how it should be. The job should dictate the tool, nothing else. There must be standards about how tools talk to each other, how they respond to signals etc. But never standard tools. The task should determine the tool and no tool should make it difficult to swap out a component when a task would be better served by a different one.
There is no such thing as a best program. There is only the best program for what I am doing right now.
I've never found journalctl to contain anything that wasn't in /var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have been in EVERY distro - each distro should have been using the one best suited to the use-cases and target markets that distro was aimed at.
Mostly these are packages that predate the establishment of the /etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process.
Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian standards - other distros are a bit more lax about it).
But SystemD is not archaic, and it's not a small third-party package whose developers are few in number and perhaps just don't care or know about the standard. It's a major system component, which has pushed itself as an irreplaceable part of every major distro now. Surely such a component of all things should try to comply with good practise and standards ?
Surely the the bar should be higher for a component that aims to replace most of the other components in a linux system ?
But SystemD has never cared about best practise or standards or legacy of any kind. They do whatever the hell they want and everybody else has to either adapt to whatever THEY decided is how we WILL work - or we have to go to the extreme effort now required to avoid them.
That's the opposite of how it's supposed to work. You want your code in a distro ? On my PC ? You should be adapting to the distro's standards, and to MY needs and desires - if you can't do either, then you belong on neither. Upstream should not get to dictate to downstream, that's the way of closed-source software.
The entire point and purpose of free and open source software is the opposite: that downstream should be in control of itself, which requires that the only possible path to acceptance for upstream must be to comply with the wishes and standards that downstream establishes.
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thing and do it well", "Simple pipes and text-based configs and communications. It's because this has been the single most succesfull development philosophy is the history of computer science. Unix is now almost 50 years old - no other OS that old is still in active use. It runs on everything from massive server-farms and mainframes to cellphones. Doing widely disparate jobs and it adapts to all these completely different usage scenarios. Just within Linux you have GNU stacks, you have the JAVA based android stack, you have busybox - if you feel like it you can build a system by compiling BSD utilities from source on a Linux kernel and build BSD/Linux - nothing stops you (the only reason you can't go download that is because nobody has wanted it badly enough to maintain such a system - but there's nothing stopping you from making one).
The reason it can adapt is that philosophy - because it's made up of simple drop-in-and-replace programs you CAN adapt it for any use-case. The unix philosophy is very much the software equivalent of an old-style giant bucket of legos. You can drop and in and replace any brick with any other, the pieces are all ridiculously simple but they can connect to each other in well-understood ways and you can build truly magnificent structures by coupling all these simple pieces together in arbitrary ways.
SystemD violates that approach entirely. And so you get the very issue you describe - in one of the most common use-cases it works quite well, in the other most common use-case it works a lot less well - and in the millions of niche use-cases... it fails entirely, because I can't no longer take individual components and arbitrarily swap them out, or put them together in arbitrarily different ways.
The Unix philosophy is to give you a bucket of lego bricks so you can build whatever you need.
SystemD is more like the modern lego-kits, sure it may give you a prettier model of the death-star, but you can't build a model Boeing 747 from the same kit. The lego company apparently decided they'll make more money selliing people single-purpose kits than buckets they can play with for decades and build anything with - it doesn't mean the buckets weren't a far superior product.
And that's a real issue- because even the one use-case it's great at isn't static (not to mention it's a shrinking part of the market - I suspect it's only a matter of time before only programmers, gamers and engineers have desktops at all anyway) - the needs there will change in time, it may change very radically, and it's impossible to predict how it will change. For Microsoft it meant having to rewrite their entire API from scratch in the mid-2000s because it simply could no longer do what their market required, systemD is now creating the groundwork for the same thing happening to Linux in the end - because it's not small, generic blocks you can put together differently to meet new needs when they arrive, you either have to extend systemD to support those needs - or if it cannot be logically be extended that way, you'll have to abandon it entirely and write an all new system !
That's a very real issue - and one there is no good answer for.
So, unfortunately, that leads me to predict that systemD is more likely to get worse than better - the more our needs evolve, the harder it will be for such a large all-encompassing and interconnected project to evolve along.
No. I didn't change anything. No configs, editable or otherwise, should exist outside /etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under /usr as being) belong under /etc/default. They no more belong under /usr than the similar files installed by a thousand other packages do.
Right... /etc/default is good enough for every other package but not for systemd.
And
You know, if you don't follow the standards and "misconceptions" arise - it's the fault of bad development.
I should not comment from my phone. Man autocorrect rapes my text...
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). /etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally. /use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them.
Config outside
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
It's the Amiga of the Linux world.
It's not a corporation. It's a privately held company.
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user.
A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running.
SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system
Your accusation actually makes no sense. How can you accuse the democrats of being unwilling to compromise and negotiate when the entire legislative approach of republicans have been to preclude the possibility? How do you negotiate on a bill when they won't let you read it? How do you offer ammendments or debate when the bills are secret until hours before the vote? Forget 2 years of negotiating major bills, Republicans refuse to offer 2 hours. Even most fellow Republicans don't get to know what they will be asked to vote on!