First off Apple doesn't deliver via. SMS. The fallover to SMS happens on the phone. If you want your messages you pick them up with your Mac. Second, Apple has websites to change settings and tech support for people to call if they screw up. So they do handle the edge cases.
That person still had the number registered and likely had a mac.
So number X is tied to account Y. Account Y can still be delivered via. a mac or iPad or... So from Apple's perspective everything is good. That person didn't deregister their number with Apple.
That's correct. Delivered and Read are different statuses. Which is ironic given you are complaining about the rapid fanboys yet still even today haven't bothered to read the instructions they were telling you to read.
Of course there could be choice otherwise there wouldn't be a debate. The debate is not whether it is possible to avoid systemd. It will always be possible to avoid systemd. Many distributions do it, and I expect that there will always be some who do. The question is whether the maintainers want to incur the cost, which are going to exponentially increasing in time / effort to make avoiding systemd a practical option for system-admins. And they decided no on that.
There may very well and probably will be ways to get non-systemd to work. It is just become a dependency on more and more software going forward.
As for people leaving Debian. I doubt it. Where are all the anti-systemd people working to break the dependencies in Gnome? Where are all the anti-systemd people in creating a non-systemd version of Arch or Fedora? Why the long discussion about a Debian fork rather than just creating a child distribution and doing it? The anti-systemd party doesn't exist in the sense of being willing to do the work they are asking others to do.
I suspect that your typical Hipbuntu ponce doesn't even know what it is.
People like the effects of all sorts of things.
But no doubt you have figures to prove me wrong.
Yes. The strong support for things like queued directories for example.
Even if you were right, there are systems other than desktops.
That's true though you are responding to my comment out of context. The dominant server platforms, PaaS also favor process management and are enthusiastic about how systemd enables it. No one is claiming that systemd is best for all use cases, just that it is far better for many and generally not much worse for all but a few. And thus meets the criteria one would want for a standard.
There are going to need to be distributions that don't have process management, some embedded systems for example can't spare the RAM and thus may be a bad place for systemd. And those should naturally migrate towards non-systemd distributions. There is no reason those distributions can't be child distributions of Debian. What Debian has determined is that Debian itself will not be a non-systemd distribution.
And finally, why make it mandatory? I can't think of a good reason for that, but I can think of two bad ones.
For upstream because built in process management allows applications to perform complicated interactions without having to write their own process managers. Moreover if there is a shared process management framework then applications can cooperate between themselves in an actor framework. As more and more applications utilize systemd features they pick up direct or indirect dependencies on it.
That's like saying "why is libc mandatory"? It isn't. But a lot of applications depend on the standard-C library to accomplish their tasks. Many that don't directly do so indirectly. At a certain point a distribution just considers it part of the base. It certainly is possible to create operating systems that don't need libc to retain "choice" but no one does.
The problem is that they have to support it, because the evidence tells us that when the inevitable security problems come calling the 'upstream maintainers' won't be terribly responsive.
Systemd is part of RHEL. Debian isn't going to have to worry. RedHat is going to be all over security issues.
but that has no relevance to other Linux distributions or those administering them.
Of course it does. RedHat leads on a lot of products that are upsteam for many of the distributions, in particular Debian. Suse also supports this shift with their products. So yes it is relevant.
Again, this argument of "Red Hat is doing this therefore you have to" holds no water
No one has to do anything. But there are tradeoffs. I was objecting to the "catch-22".
I also wish them luck with the inevitable security problems because they are going to be humdingers even if you had a bunch of maintainers who were extremely responsive to bugs and had a clue what they were doing.
Do you really believe that RedHat doesn't know what they are doing? Do you really find that plausible?
If upstream make their package depend on systemd then either that dependancy isn't needed, in which case just remove it, or is needed for some feature, in which case the user would have to install systemd whether it was the default or not.
What they asking for (or let's say with Ian is pushing for) is for Debian package maintainers to try and remove these dependencies. For example Brasero uses systemd to detect when a CD/DVD is inserted. In theory Debian could just remove that functionality and use another daemon or change the way Brasero works. Where that is not possible eliminate the package. Do I agree with Ian, no. But that's what he wants.
The people are objecting to package dependencies. And there are some of those creeping in for Jessie more than anticipated which is part of the upset. Moreover as upsteam is adding dependencies that number is going to increase rapidly.
I'm pro-systemd but let's not pretend that the chains of dependencies aren't present.
Your point is different that GPs. No more bugs than the mature system is often an unachievable goal in practical time frames. Not too many bugs is a judgement question. Gentoo, Arch are more cutting edge. RHEL and Debian stable are much less cutting edge. The balance there is something Linux distribution do well, given the limitations of how buggy upstream is.
One example of this is how Canonical dropped support for upstart after Debian adopted systemd as the default.
That's not quite what happened. Upstart was having problems keeping up for a long time. Ubuntu had already decided to move towards systemd regardless and drop Upstart as a major focus. When Debian picked systemd it was no longer going to be easy to even support something else...
If Debian imposes a requirement that packages do not depend on systemd, then that will have a significant effect
What effect? Gnome already does. KDE (dbus) is going to. Other packages already have. So what effect?
Ultimately, distros and upstream projects have a symbiotic relationship, so the larger players on either side can influence the outcome.
Exactly. And in this case many of the upstream projects are passionate about systemd. The distributions are not. There likely will be a non-systemd distribution aimed at classic server which just doesn't have a whole bunch of packages. I think the Debian fork (though more than likely it will just be a child distribution) if it is possible is a good idea. But I don't see what Debian can do given that upstream is committed.
If that really was the case, how come wireless ISPs are able to deliver so much more data for about the same price?
WISP is a totally different technology with a different cost structure. Apples to baseballs type comparison.
If the spectrum costs say $1b for a nationwide 20 year lease and there are say 10 million subs, that's only $100/sub, or $5/sub/year.
It is more than that. For example the AWS-3 auction (which wasn't much bandwidth) has a $10.5b reserve (i.e. below that price the government wasn't selling) and sold for $19.6b.
In addition to the bandwidth there is the cost of the many towers in terms of maintenance. That is a big expense. Finally I gotta tell you the towers I've seen no way are they under $20k. I don't know what they are paying but I'd expect hundreds of thousands. OTOH they serve way way more than 1000 subs.
- how is it that expensive in the US but so comparatively cheap even in tiny island nations like mine where bandwidth is still quite expensive per mbit, or, say, any country in Europe?
In Europe you have a lot of people in very dense regions and then very dispersed regions. In the USA because of the car culture you have a much more uniform population density than Europe. That is lots of areas with too many people to ignore but not enough people to make it profitable at low prices. The result is that coverage requires many times as many towers with each serving less people. That's why the USA lagged Europe by so many years for cell phones. Same issue you have in Africa, BTW which is a far better comparison. I don't know where you live, but a tiny island nation likely has a higher density.
systemd is designed to minimize how long you spend booting
systemd is designed to give Linux a full featured process manager like you have on mainframes. Speeding booting is a side benefit.
___
As for your comment about arbitrary verbs systemd should be handling each process, that's its job. There shouldn't be any functionality in both places after conversion.
and it doesn't seem right that a change in pid1 should even remotely impact userland applications at all, let alone as deeply as systemd has.
I think part of the problem is the anti-systemd people keep saying that systemd is about init. Think of systemd as a process manager not an init system. One of the states that needs to be managed is initialization but that is just one of the many types of process management it does. userland applications use process manager.
That being said I think diversity will be good. I hope the Debian non-systemd fork exists then everyone can stop freaking out.
I think this whole thing would be a non-issue if you could swap out systemd with another system and still have everything function easily.
That's like saying the whole thing would be a non-issue if you could swap out libc with an entirely different structure and still have everything function easily.
Systemd provides lots and ever increasing functionality. It is not just some small component but a core part of the architecture.
What about the other way around? SystemD advocates constantly try to dismiss those who criticize SystemD as a tiny handful of UNIX greybeards. I have yet to see any evidence of that being the case. It very much seems to me that SystemD is pushed on all Linux by a tiny handful of Red Hat marketing execs.
I wouldn't exactly call the OpenShift / OpenStack / GearD group in RedHat "marketing execs" they are some of the most advanced server admin developers on the planet. But if you want a group not RedHat advocates: Docker and CoreOS are huge systemd supporters ( Alex Polvi, Brandon Philips and Michael Marineau).
Debian went with SystemD because they believed a systemd takeover was inevitable.
Actually there are already several programs and a bunch of libraries (ex: http://search.cpan.org/~lkundr...) that can handle the binary format. More are being written. The situation you are describing doesn't exist now and will rectify quickly.
I agree. Systemd is now about a "2nd kernel" or "userspace plumbing". Essentially a redesign of Linux.
The problem is I don't know what there is for Debian to debate. They don't have the upsteam influence. If systemd is expanding and large numbers of developers in upstream and going to be introducing dependencies on systemd what is there for Debian to debate? The most they could in a practical sense do would be to create a subset of packages that don't have systemd dependencies directly or indirectly and frankly that's pretty easy for anyone to do for themselves and just create a child distribution
IMHO the anti-systemd people are mostly admins and not developers so I don't think they have the manpower to pull off what they want.
Instead of offering me an alternative and convincing me to switch of my own volition, systemd has become mandatory by virtue of shifting the ground from out beneath my feet. This is a bullshit way to do things.
That's called progress. I liked MySpace and didn't like the switch to Facebook. So what?
There is no catch-22. Gnome is led by RedHat. RedHat is moving in the direction of OpenShift. PaaS vendors want process management i.e. systemd. That's a clear cut chain of dependency. If you want to be on the Gnome codebase you follow RedHat's lead.
MATE is fighting the user interface battle they don't want to go after user space plumbing as well.
Slashdot Mirror
First off Apple doesn't deliver via. SMS. The fallover to SMS happens on the phone. If you want your messages you pick them up with your Mac.
Second, Apple has websites to change settings and tech support for people to call if they screw up. So they do handle the edge cases.
That person still had the number registered and likely had a mac.
So number X is tied to account Y. Account Y can still be delivered via. a mac or iPad or ... So from Apple's perspective everything is good. That person didn't deregister their number with Apple.
That's correct. Delivered and Read are different statuses. Which is ironic given you are complaining about the rapid fanboys yet still even today haven't bothered to read the instructions they were telling you to read.
It isn't really a bug. It is a correction for users not thinking, not reading and not paying attention. The system was doing what they told it to do.
iMessage integrates with you Mac so you can use it as a computer messaging client that also works well from your phone.
iMessage doesn't have to use PSTN. It works fine for people who don't have a number at all so it can't forward to a number.
In CoreOS, systemd unit files are used not only for system services, but also for running Docker containers.
https://blog.openshift.com/gea...
etc..
Of course there could be choice otherwise there wouldn't be a debate. The debate is not whether it is possible to avoid systemd. It will always be possible to avoid systemd. Many distributions do it, and I expect that there will always be some who do. The question is whether the maintainers want to incur the cost, which are going to exponentially increasing in time / effort to make avoiding systemd a practical option for system-admins. And they decided no on that.
There may very well and probably will be ways to get non-systemd to work. It is just become a dependency on more and more software going forward.
As for people leaving Debian. I doubt it. Where are all the anti-systemd people working to break the dependencies in Gnome? Where are all the anti-systemd people in creating a non-systemd version of Arch or Fedora? Why the long discussion about a Debian fork rather than just creating a child distribution and doing it? The anti-systemd party doesn't exist in the sense of being willing to do the work they are asking others to do.
People like the effects of all sorts of things.
Yes. The strong support for things like queued directories for example.
That's true though you are responding to my comment out of context. The dominant server platforms, PaaS also favor process management and are enthusiastic about how systemd enables it. No one is claiming that systemd is best for all use cases, just that it is far better for many and generally not much worse for all but a few. And thus meets the criteria one would want for a standard.
There are going to need to be distributions that don't have process management, some embedded systems for example can't spare the RAM and thus may be a bad place for systemd. And those should naturally migrate towards non-systemd distributions. There is no reason those distributions can't be child distributions of Debian. What Debian has determined is that Debian itself will not be a non-systemd distribution.
For upstream because built in process management allows applications to perform complicated interactions without having to write their own process managers. Moreover if there is a shared process management framework then applications can cooperate between themselves in an actor framework. As more and more applications utilize systemd features they pick up direct or indirect dependencies on it.
That's like saying "why is libc mandatory"? It isn't. But a lot of applications depend on the standard-C library to accomplish their tasks. Many that don't directly do so indirectly. At a certain point a distribution just considers it part of the base. It certainly is possible to create operating systems that don't need libc to retain "choice" but no one does.
A guy whose been in the Linux community for 19 years and Unix before that.
And it will still be about choice. There are going to be non-systemd distributions just like there are all sorts of other specialized distributions.
Then don't upgrade.
Systemd is part of RHEL. Debian isn't going to have to worry. RedHat is going to be all over security issues.
Of course it does. RedHat leads on a lot of products that are upsteam for many of the distributions, in particular Debian. Suse also supports this shift with their products. So yes it is relevant.
No one has to do anything. But there are tradeoffs. I was objecting to the "catch-22".
Do you really believe that RedHat doesn't know what they are doing? Do you really find that plausible?
What they asking for (or let's say with Ian is pushing for) is for Debian package maintainers to try and remove these dependencies. For example Brasero uses systemd to detect when a CD/DVD is inserted. In theory Debian could just remove that functionality and use another daemon or change the way Brasero works. Where that is not possible eliminate the package. Do I agree with Ian, no. But that's what he wants.
The people are objecting to package dependencies. And there are some of those creeping in for Jessie more than anticipated which is part of the upset. Moreover as upsteam is adding dependencies that number is going to increase rapidly.
I'm pro-systemd but let's not pretend that the chains of dependencies aren't present.
Your point is different that GPs. No more bugs than the mature system is often an unachievable goal in practical time frames. Not too many bugs is a judgement question. Gentoo, Arch are more cutting edge. RHEL and Debian stable are much less cutting edge. The balance there is something Linux distribution do well, given the limitations of how buggy upstream is.
That's not quite what happened. Upstart was having problems keeping up for a long time. Ubuntu had already decided to move towards systemd regardless and drop Upstart as a major focus. When Debian picked systemd it was no longer going to be easy to even support something else ...
What effect? Gnome already does. KDE (dbus) is going to. Other packages already have. So what effect?
Exactly. And in this case many of the upstream projects are passionate about systemd. The distributions are not. There likely will be a non-systemd distribution aimed at classic server which just doesn't have a whole bunch of packages. I think the Debian fork (though more than likely it will just be a child distribution) if it is possible is a good idea. But I don't see what Debian can do given that upstream is committed.
WISP is a totally different technology with a different cost structure. Apples to baseballs type comparison.
It is more than that. For example the AWS-3 auction (which wasn't much bandwidth) has a $10.5b reserve (i.e. below that price the government wasn't selling) and sold for $19.6b.
In addition to the bandwidth there is the cost of the many towers in terms of maintenance. That is a big expense. Finally I gotta tell you the towers I've seen no way are they under $20k. I don't know what they are paying but I'd expect hundreds of thousands. OTOH they serve way way more than 1000 subs.
In Europe you have a lot of people in very dense regions and then very dispersed regions. In the USA because of the car culture you have a much more uniform population density than Europe. That is lots of areas with too many people to ignore but not enough people to make it profitable at low prices. The result is that coverage requires many times as many towers with each serving less people. That's why the USA lagged Europe by so many years for cell phones. Same issue you have in Africa, BTW which is a far better comparison. I don't know where you live, but a tiny island nation likely has a higher density.
systemd is designed to give Linux a full featured process manager like you have on mainframes. Speeding booting is a side benefit.
___
As for your comment about arbitrary verbs systemd should be handling each process, that's its job. There shouldn't be any functionality in both places after conversion.
I think part of the problem is the anti-systemd people keep saying that systemd is about init. Think of systemd as a process manager not an init system. One of the states that needs to be managed is initialization but that is just one of the many types of process management it does. userland applications use process manager.
That being said I think diversity will be good. I hope the Debian non-systemd fork exists then everyone can stop freaking out.
Joey Hess was pro-systemd. Your entire article is wrong.
That's like saying the whole thing would be a non-issue if you could swap out libc with an entirely different structure and still have everything function easily.
Systemd provides lots and ever increasing functionality. It is not just some small component but a core part of the architecture.
I wouldn't exactly call the OpenShift / OpenStack / GearD group in RedHat "marketing execs" they are some of the most advanced server admin developers on the planet. But if you want a group not RedHat advocates: Docker and CoreOS are huge systemd supporters ( Alex Polvi, Brandon Philips and Michael Marineau).
Yes. And they are right.
Actually there are already several programs and a bunch of libraries (ex: http://search.cpan.org/~lkundr...) that can handle the binary format. More are being written. The situation you are describing doesn't exist now and will rectify quickly.
I agree. Systemd is now about a "2nd kernel" or "userspace plumbing". Essentially a redesign of Linux.
The problem is I don't know what there is for Debian to debate. They don't have the upsteam influence. If systemd is expanding and large numbers of developers in upstream and going to be introducing dependencies on systemd what is there for Debian to debate? The most they could in a practical sense do would be to create a subset of packages that don't have systemd dependencies directly or indirectly and frankly that's pretty easy for anyone to do for themselves and just create a child distribution
IMHO the anti-systemd people are mostly admins and not developers so I don't think they have the manpower to pull off what they want.
That's called progress. I liked MySpace and didn't like the switch to Facebook. So what?
There is no catch-22. Gnome is led by RedHat. RedHat is moving in the direction of OpenShift. PaaS vendors want process management i.e. systemd. That's a clear cut chain of dependency. If you want to be on the Gnome codebase you follow RedHat's lead.
MATE is fighting the user interface battle they don't want to go after user space plumbing as well.