No. It wouldn't be better. Running networks is hard. And so far government has proven pretty bad at managing local wifi which is much easier than building out a cellular network. I can think of lots of things that I'd like to socialize long before telco.
Well it isn't a broad tax. It is a fee paid by people who consume lots of bandwidth to people who consume government services. Those aren't necessarily (or likely) the same people. Using price as a mechanism to determine the best possible public use make sense in a capitalist society.
As far as fibre rollout. That's an entirely different function and involves (with some overlap) different companies and different consumers.
First off let's be fair here. Lennart has limited contact with Debian. The people switching Debian over to systemd are the package maintainers and Debian project leadership. That happened because Unity failed which had been the direction Debian was heading in. Blaming Lennart is quite unfair. Debian adopted systemd because lots of people in the Debian community thought systemd was better, mainly because upstream developers like systemd. Until you accept that you are going to continue with conspiracy theories.
As far as real world projects and systemd systemd is already being used in large PaaS deployment how much more real world can you get than that?
Well process management is the baggage. The stuff being replaced are the parts of legacy Linux that for one reason or another are incapable of handling chains of dependencies. If you mean why not just init, that's because initialization is just one possible state from the process manager needs to handle. Why not have it handle other states like suspending, hibernating, recovering, shutting down, daemon crashing.... ?
I don't know of any in the mid 1990s who did that. Compatibility was worse on Linux than just about any commercial Unix. It also had a smaller toolbox. 7 years later that situation was totally reversed.
7500 of the 8000 Debian packages have 0 systemd dependencies and those that even need init support can have easy scripts. No one is arguing about what to do in that case, include in init script where needed.
Let's say another 200 applications operate but with reduced functionality or security. How to handle that is complex and probably is best left to the judgement of the individual project maintainers. That's what the no vote meant, empowering them to make these choices.
Let's say another 300 applications have hard dependencies. That systemd is unavoidable without a major porting effort. This is where the core of the argument lies, what to do with these.
Now of course these 300 applications can start to chain down and create all sorts of other dependencies. Which is why a default was likely needed by the next version and helpful for Jessie.
RedHat has clearly picked their direction with IaaS and PaaS. Just as they moved from desktop to server they are moving from small server deployment to large server deployment, moving up market. Mostly I suspect traditionalist sysadmins were running CentOS anyway.
A Debian derivative doesn't exist yet. It will soon enough. The Linux community has a long track record of creating new distributions to fulfill niches. I think faith is warranted.
FWIW it is fairly easy to create a structure to turn internal capex into opex. You can still do stuff internally, have your people working being paid via. a PEO / staff aug firm and have the hardware leased back to you. If the issue is they want opex that's easy enough to achieve under either model.
Large cloud companies treat large clients wonderfully. Large cloud companies treat midsized clients like crap. Midsized cloud companies treat midsized client quite well. This is the sort of thing you should be discussing with your cloud agent, getting you into a rightsized relationship with your vendor. Which BTW is also likely to save you money.
well, I have yet to be convinced that any of these vendors can provide as much uptime and reliability as a decent IT department.
Your decent IT department doesn't have dozens of redundant colos attached to your network in class 2-4 datacenters. There are statistical measures of reliability for fortune 1000 companies regarding colo and the colo providers crush their internal. There are statistical measures of reliability regarding commercial cloud and they crush internal. Now that's not saying the best internal groups won't beat so-so clouds but they won't beat the best clouds. In the end it comes down to resources and focus and they win on both.
Possibly since there is a fire. But I don't many Debian users who aren't system admins. It was never a particularly good desktop or workstation distribution. Once the debian repository became available in other distributions like Ubuntu...
They are being forced to switch distributions not operating systems. And given the way Debian is configured the forced change is going to be from Debian to a child distribution of Debian that acts and feels like Debian. Not sure why that's such a terrible burden.
RedHat makes RHEL which has longer support contracts thanDebian does. They just use the RHEL versions of RedHat software for Debian stable. Problem solved.
Crux and Alpine have both said their long term plan is non-systemd. They intend to drop packages that can't be made to work without systemd.
Slackware is going to hold out as long as it can. Patrick doesn't think that's more a couple more years.
Gentoo because of the lack of integration will likely in a formal sense be able to hold out forever. They have however mostly abandoned their own OpenRC alternative. So they know they are in a holding pattern at best.
PCLinuxOS is KDE-desktop based. I'm shocked they aren't already systemd. No chance they holdout.
In the end, Lennart Pottering is on the best course to achieve what neither Bill Gates nor Darl McBride was able to do, in spite of their best efforts: destroying Linux. The Linux ecosystem was strong enough to withstand any outside attack, but even it can be brought down if it starts rotting from the inside.
where the initscripts morphed into wireable components so that the system administrator could define whatever network of dependencies he/she required.
That is exactly what systemd excels at, far better than init. It allows for complex definitions of dependencies. People who want chains of dependencies should be embracing systemd.
I'm not buying it. Guys who do thousands of servers have been migrating towards PaaS and IaaS for a decade now unless they are all embedded servers or whatever. There is nothing in systemd that isn't far heavier than what you are already running if you are managing systems that large.
The vendors aren't providing an alternative to systemd. Use Crux or whatever.
Fork. Go ahead. The systemd people have always supported a child distribution of Debian that doesn't support systemd. That "threat" had the full support of systemd. In fact if you can submit patches to keep stuff working on initd as dozens if not hundreds of upstream developers start dropping init support all the better.
if journald simply made plaintext logging alongside (not as a downstream add-on by piping to syslog, natively doing it alongside binary data
What difference does it make is syslogd pipes to syslogd who writes to disk?
If a systemd unit could degrade to start without being able to talk to pid 1 or cgroup support available (with loss of function), then some debug activity is made more straightforward in a rescue environment
That's a better example. Mostly the assumption of syslogd people is the rescue environment is a different system. In other words if the system crashes then you boot to a lower level system and either
a) The node is diagnosed by another system b) The node is blown away and reinstalled by another system
Which honestly is mostly how I've been fixing Linuxes for 2 decades even on single server. Boot from a CD based linux fix the main Linux and restart if I can't get a TTY running. If I can get a TTY running than initd worked...
If open ended init scripts were better accommodated and didn't try to forcibly constrain sysv init scripts to force it to fit the only models that systemd understands.
Systemd can run shell scripts. How is that any different?
It possibly could have been phased for Jessie. If the proposal had been Jessie is a transitional distribution and the next one is systemd only, that might have worked. The problem is the anti-systemd people wanted non-systemd long term.
The option of a smooth transition is the sort of compromise that heated debate destroys.
No one is fighting against choice. The way Linux has traditionally delivered choice in the sorts of situations where it is an true either / or situation is through the distributions. Different distributions had different application stacks. Debian eventually primarily became a parent distribution so that the children under it could specialize. That's the way choice should be preserved. There should be a non-systemd traditionalist child distribution of Debian. Several of these distributions that are non systemd already exist.
But the general purpose Debian should mostly follow the Linux community.
Ken Thompson , Dennis Ritchie and Brian Kernighan (to just name a few) had it all wrong
Ken Thompson , Dennis Ritchie and Brian Kernighan were trying to build a smaller simpler Multics. They agreed that given additional hardware resources the Multics approach fit many use cases better. If you are going to cite their ideas cite them accurately.
Slashdot Mirror
No. It wouldn't be better. Running networks is hard. And so far government has proven pretty bad at managing local wifi which is much easier than building out a cellular network. I can think of lots of things that I'd like to socialize long before telco.
Well in addition to better phone performance, $34b is spending on the public welfare. They lose some spectrum from government usage.
Well it isn't a broad tax. It is a fee paid by people who consume lots of bandwidth to people who consume government services. Those aren't necessarily (or likely) the same people. Using price as a mechanism to determine the best possible public use make sense in a capitalist society.
As far as fibre rollout. That's an entirely different function and involves (with some overlap) different companies and different consumers.
First off let's be fair here. Lennart has limited contact with Debian. The people switching Debian over to systemd are the package maintainers and Debian project leadership. That happened because Unity failed which had been the direction Debian was heading in. Blaming Lennart is quite unfair. Debian adopted systemd because lots of people in the Debian community thought systemd was better, mainly because upstream developers like systemd. Until you accept that you are going to continue with conspiracy theories.
As far as real world projects and systemd systemd is already being used in large PaaS deployment how much more real world can you get than that?
Well process management is the baggage. The stuff being replaced are the parts of legacy Linux that for one reason or another are incapable of handling chains of dependencies. If you mean why not just init, that's because initialization is just one possible state from the process manager needs to handle. Why not have it handle other states like suspending, hibernating, recovering, shutting down, daemon crashing.... ?
RedHat, HP, IBM, Saleforce, Intel .... are all staffed by posers.
Slackware is not long for initd. A few years. Crux is probably a better choice if you want to stand your ground.
I don't know of any in the mid 1990s who did that. Compatibility was worse on Linux than just about any commercial Unix. It also had a smaller toolbox. 7 years later that situation was totally reversed.
Absolutely true.
Let's say by 2016:
7500 of the 8000 Debian packages have 0 systemd dependencies and those that even need init support can have easy scripts. No one is arguing about what to do in that case, include in init script where needed.
Let's say another 200 applications operate but with reduced functionality or security. How to handle that is complex and probably is best left to the judgement of the individual project maintainers. That's what the no vote meant, empowering them to make these choices.
Let's say another 300 applications have hard dependencies. That systemd is unavoidable without a major porting effort. This is where the core of the argument lies, what to do with these.
Now of course these 300 applications can start to chain down and create all sorts of other dependencies. Which is why a default was likely needed by the next version and helpful for Jessie.
RedHat has clearly picked their direction with IaaS and PaaS. Just as they moved from desktop to server they are moving from small server deployment to large server deployment, moving up market. Mostly I suspect traditionalist sysadmins were running CentOS anyway.
A Debian derivative doesn't exist yet. It will soon enough. The Linux community has a long track record of creating new distributions to fulfill niches. I think faith is warranted.
FWIW it is fairly easy to create a structure to turn internal capex into opex. You can still do stuff internally, have your people working being paid via. a PEO / staff aug firm and have the hardware leased back to you. If the issue is they want opex that's easy enough to achieve under either model.
Large cloud companies treat large clients wonderfully. Large cloud companies treat midsized clients like crap. Midsized cloud companies treat midsized client quite well. This is the sort of thing you should be discussing with your cloud agent, getting you into a rightsized relationship with your vendor. Which BTW is also likely to save you money.
Your decent IT department doesn't have dozens of redundant colos attached to your network in class 2-4 datacenters. There are statistical measures of reliability for fortune 1000 companies regarding colo and the colo providers crush their internal. There are statistical measures of reliability regarding commercial cloud and they crush internal. Now that's not saying the best internal groups won't beat so-so clouds but they won't beat the best clouds. In the end it comes down to resources and focus and they win on both.
Possibly since there is a fire. But I don't many Debian users who aren't system admins. It was never a particularly good desktop or workstation distribution. Once the debian repository became available in other distributions like Ubuntu...
They are being forced to switch distributions not operating systems. And given the way Debian is configured the forced change is going to be from Debian to a child distribution of Debian that acts and feels like Debian. Not sure why that's such a terrible burden.
RedHat makes RHEL which has longer support contracts thanDebian does. They just use the RHEL versions of RedHat software for Debian stable. Problem solved.
Crux and Alpine have both said their long term plan is non-systemd. They intend to drop packages that can't be made to work without systemd.
Slackware is going to hold out as long as it can. Patrick doesn't think that's more a couple more years.
Gentoo because of the lack of integration will likely in a formal sense be able to hold out forever. They have however mostly abandoned their own OpenRC alternative. So they know they are in a holding pattern at best.
PCLinuxOS is KDE-desktop based. I'm shocked they aren't already systemd. No chance they holdout.
Me thinks you need to get a grip.
That is exactly what systemd excels at, far better than init. It allows for complex definitions of dependencies. People who want chains of dependencies should be embracing systemd.
I'm not buying it. Guys who do thousands of servers have been migrating towards PaaS and IaaS for a decade now unless they are all embedded servers or whatever. There is nothing in systemd that isn't far heavier than what you are already running if you are managing systems that large.
The vendors aren't providing an alternative to systemd. Use Crux or whatever.
Fork. Go ahead. The systemd people have always supported a child distribution of Debian that doesn't support systemd. That "threat" had the full support of systemd. In fact if you can submit patches to keep stuff working on initd as dozens if not hundreds of upstream developers start dropping init support all the better.
Please do it.
What difference does it make is syslogd pipes to syslogd who writes to disk?
That's a better example. Mostly the assumption of syslogd people is the rescue environment is a different system. In other words if the system crashes then you boot to a lower level system and either
a) The node is diagnosed by another system
b) The node is blown away and reinstalled by another system
Which honestly is mostly how I've been fixing Linuxes for 2 decades even on single server. Boot from a CD based linux fix the main Linux and restart if I can't get a TTY running. If I can get a TTY running than initd worked...
Systemd can run shell scripts. How is that any different?
It possibly could have been phased for Jessie. If the proposal had been Jessie is a transitional distribution and the next one is systemd only, that might have worked. The problem is the anti-systemd people wanted non-systemd long term.
The option of a smooth transition is the sort of compromise that heated debate destroys.
No one is fighting against choice. The way Linux has traditionally delivered choice in the sorts of situations where it is an true either / or situation is through the distributions. Different distributions had different application stacks. Debian eventually primarily became a parent distribution so that the children under it could specialize. That's the way choice should be preserved. There should be a non-systemd traditionalist child distribution of Debian. Several of these distributions that are non systemd already exist.
But the general purpose Debian should mostly follow the Linux community.
Ken Thompson , Dennis Ritchie and Brian Kernighan were trying to build a smaller simpler Multics. They agreed that given additional hardware resources the Multics approach fit many use cases better. If you are going to cite their ideas cite them accurately.