From: "James Harper"
Rsync integration
Not claimed - no patches yet - Not in kernel yet
Now that we have code to efficiently find newly updated files, we need to tie it into tools such as rsync and dirvish. (For bonus points, we can even allow rsync to use btrfs's builtin checksums and, when a file has changed, tell rsync _which blocks_ inside that file have changed. Would need to work with the rsync developers on that one.)
Update rsync to preserve NOCOW file status.
Means: Make rsync work like btrfs send/receive;-) and put filesystem specific code in it.
I'm just testing out some of the deduplication stuff in btrfs, and was actually a little shocked to find it calculating the hashes itself. btrfs already has checksums, and if nothing else it could have used them to trivially reject blocks that are different before calculating a stronger hash. There is talk about exposing the btrfs checksums to userspace, but of course that puts contraints on further development as they now have to consider userspace compatibility.
ZFS has feature flags you can test.
I am not sure whether this is a great idea.
Most of the time you will have the same filesystem on both ends. Then you can use zfs/btrfs etc. tools. Or rsync if it's not a COW system.
It is more "code polluting" than it's worth I think.
Maybe. Depends on the speedup. In a lot of cases, the above optimisations would speed up the processing that rsync has to do, but if 90% of the time taken in your rsync was actually moving data then you're never going to get anymore than 10% faster. For LAN links though, I normally just use -W for rsync because computing changes just adds overhead (I mean you have to read the file at both ends anyway, and unless your disk can pull data faster than 1GByte/second you're not going to saturate your 10GBit /second link so don't bother computing changes. If you got the change computation "for free", then it's a big win.
Yes, that's what you get from btrfs/zfs send/receive:-) You only need rsync if you have to deal with a different filesystem at the other end and then it may help you only in a few percent of the cases. If both cases have a 10% likelihood you start this "layer blurring" coding for 1% of useful cases.
And if btrfs send/receive isn't stable there is a good chance to implement an unstable rsync as well.
(I think) Russell was supposing that there weren't many bugs reported for send/receive because not many people were using it. I'm not sure how we got from there to "send/receive isn't stable".
From Chris Samuel today:
Watch out with 3.17 then, there are early reports that it's broken btrfs send.
That may need a bit more evaluation, maybe. Overall I hear a lot of "btrfs is having this or that issues" which I never followed up properly. But it makes me wary. I am using ZFS on FreeBSD for at least 3 years in production now (and upgrade the kernel regularly when needed) without any issues. Besides of early problems with nearly full ZFS and memory which were known. On both fronts there seems to be improvement. E.g. I have 92% full ZFS volumes which are still performing - there was a 80% "warning" in the past, and I run ZFS on 3GB and 4GB RAM boxes and do not see issues. Regards Peter
On 7/10/2014 5:41 PM, Peter Ross wrote:
Overall I hear a lot of "btrfs is having this or that issues" which I never followed up properly. But it makes me wary.
I don't know if I could ever trust BTRFS ... I want to, but I see too many issues, far too often and file system problems are the last ones I want due to a buggy implementation or failed feature adjustments that just plain break things...
I am using ZFS on FreeBSD for at least 3 years in production now (and upgrade the kernel regularly when needed) without any issues.
Besides of early problems with nearly full ZFS and memory which were known.
On both fronts there seems to be improvement. E.g. I have 92% full ZFS volumes which are still performing - there was a 80% "warning" in the past, and I run ZFS on 3GB and 4GB RAM boxes and do not see issues.
How much storage? RAM was always a problem with ZFS, it seems to be a problem of the past now though and ZFS seems so much better. Cheers A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 7/10/2014 5:41 PM, Peter Ross wrote:
Overall I hear a lot of "btrfs is having this or that issues" which I never followed up properly. But it makes me wary.
I don't know if I could ever trust BTRFS ... I want to, but I see too many issues, far too often and file system problems are the last ones I want due to a buggy implementation or failed feature adjustments that just plain break things...
Every filesystem has problems in the early days. Only a small minority of BTRFS problems caused data loss. I've had a few serious problems (including ones that required backup/format/restore) and none of them lost any data AFAIK.
I am using ZFS on FreeBSD for at least 3 years in production now (and upgrade the kernel regularly when needed) without any issues.
Besides of early problems with nearly full ZFS and memory which were known.
On both fronts there seems to be improvement. E.g. I have 92% full ZFS volumes which are still performing - there was a 80% "warning" in the past, and I run ZFS on 3GB and 4GB RAM boxes and do not see issues.
How much storage?
RAM was always a problem with ZFS, it seems to be a problem of the past now though and ZFS seems so much better.
My impression is that the only way ZFS can be said to no longer have a RAM problem is that RAM is cheap enough that no ZFS server will have less than 8G and everyone knows to turn of dedup. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 12:43 AM, Russell Coker wrote:
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 7/10/2014 5:41 PM, Peter Ross wrote:
Overall I hear a lot of "btrfs is having this or that issues" which I never followed up properly. But it makes me wary.
I don't know if I could ever trust BTRFS ... I want to, but I see too many issues, far too often and file system problems are the last ones I want due to a buggy implementation or failed feature adjustments that just plain break things...
Every filesystem has problems in the early days. Only a small minority of BTRFS problems caused data loss. I've had a few serious problems (including ones that required backup/format/restore) and none of them lost any data AFAIK.
How long do these "early days" last, btrfs has been around long enough to be more stable and trustworthy, but it isn't stable or trustworthy enough for me and many others. Heck, even Oracle declared it production ready quite some time ago, yet we are still seeing issue after issue -- no thanks!
I am using ZFS on FreeBSD for at least 3 years in production now (and upgrade the kernel regularly when needed) without any issues.
Besides of early problems with nearly full ZFS and memory which were known.
On both fronts there seems to be improvement. E.g. I have 92% full ZFS volumes which are still performing - there was a 80% "warning" in the past, and I run ZFS on 3GB and 4GB RAM boxes and do not see issues.
How much storage?
RAM was always a problem with ZFS, it seems to be a problem of the past now though and ZFS seems so much better.
My impression is that the only way ZFS can be said to no longer have a RAM problem is that RAM is cheap enough that no ZFS server will have less than 8G and everyone knows to turn of dedup.
Did you even read what was already posted? " ... and I run ZFS on 3GB and 4GB RAM boxes ...." -- that's fine, but how much storage. ZFS used to have serious problems with RAM requirements, I don't believe that is the case now from what I've been hearing. The way Debian is going, it is looking like a real option to switch to FreeBSD with a very mature ZFS and to give up on Linux for some use cases and possibly end up not even having to worry about systemd or other things being pushed in to Debian by Red Hat people ever again. I am very sure that these issues will drive many AWAY from Linux in general and Debian in particular! Cheers A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Every filesystem has problems in the early days. Only a small minority of BTRFS problems caused data loss. I've had a few serious problems (including ones that required backup/format/restore) and none of them lost any data AFAIK.
How long do these "early days" last, btrfs has been around long enough to be more stable and trustworthy, but it isn't stable or trustworthy enough for me and many others. Heck, even Oracle declared it production ready quite some time ago, yet we are still seeing issue after issue -- no thanks!
Filesystems are getting increasingly complex due to the increasing demands on them. It takes a lot more work to develop a filesystem than it used to.
My impression is that the only way ZFS can be said to no longer have a RAM problem is that RAM is cheap enough that no ZFS server will have less than 8G and everyone knows to turn of dedup.
Did you even read what was already posted? " ... and I run ZFS on 3GB and 4GB RAM boxes ...." -- that's fine, but how much storage.
ZFS used to have serious problems with RAM requirements, I don't believe that is the case now from what I've been hearing.
I've had RAM problems on a system with 4G of RAM running not much apart from Samba. I don't think that zfsonlinux has changed much since then. ZFS just manages memory differently from anything that was developed for Linux. Changing that would require significant code changes which would be another potential source of stability problems.
The way Debian is going, it is looking like a real option to switch to FreeBSD with a very mature ZFS and to give up on Linux for some use cases and possibly end up not even having to worry about systemd or other things being pushed in to Debian by Red Hat people ever again. I am very sure that these issues will drive many AWAY from Linux in general and Debian in particular!
Systemd wasn't pushed in to Debian by Red Hat or anyone else. The Debian technical committee decided that systemd was the best option. After that decision there were a lot of threats and abuse by some people with obvious mental health problems. But such people don't matter when it comes to making a decision because they lack the intelligence or sanity to contribute to Debian in any way. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 1:33 AM, Russell Coker wrote:
Filesystems are getting increasingly complex due to the increasing demands on them. It takes a lot more work to develop a filesystem than it used to.
That's fine, but they still need to be developed responsibly and without the *problems* of 3.17 in recent times and other issues that get pushed out too quickly or without proper testing. It seems that the whole development is suspect to me.
I've had RAM problems on a system with 4G of RAM running not much apart from Samba. I don't think that zfsonlinux has changed much since then.
Forget Linux, FreeBSD with ZFS ... that's quite different, more stable and with no RAM issues.
ZFS just manages memory differently from anything that was developed for Linux. Changing that would require significant code changes which would be another potential source of stability problems.
ZFS on Linux. Unfortunately, the license issues are a problem with Linux which leads to other issues, but not so with FreeBSD.
The way Debian is going, it is looking like a real option to switch to FreeBSD with a very mature ZFS and to give up on Linux for some use cases and possibly end up not even having to worry about systemd or other things being pushed in to Debian by Red Hat people ever again. I am very sure that these issues will drive many AWAY from Linux in general and Debian in particular!
Systemd wasn't pushed in to Debian by Red Hat or anyone else. The Debian technical committee decided that systemd was the best option.
I've read that it is Red Hat employees moonlighting, but that's not first hand. Still I think that the decision to go systemd is going to do Debian a great deal of damage.
After that decision there were a lot of threats and abuse by some people with obvious mental health problems. But such people don't matter when it comes to making a decision because they lack the intelligence or sanity to contribute to Debian in any way.
Too many people are aggrieved by the change to be just your *bad* type of people here. There is no doubt in my mind that systemd and how it has been handled by Debian is a complete disaster. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
That's fine, but they still need to be developed responsibly and without the *problems* of 3.17 in recent times and other issues that get pushed out too quickly or without proper testing. It seems that the whole development is suspect to me.
The BTRFS developers seem responsible to me. If you use Oracle Linux or another distribution with a similar support policy then you won't get the 3.17 code that's under development now.
I've had RAM problems on a system with 4G of RAM running not much apart from Samba. I don't think that zfsonlinux has changed much since then.
Forget Linux, FreeBSD with ZFS ... that's quite different, more stable and with no RAM issues.
Not interested in BSD.
Systemd wasn't pushed in to Debian by Red Hat or anyone else. The Debian technical committee decided that systemd was the best option.
I've read that it is Red Hat employees moonlighting, but that's not first hand. Still I think that the decision to go systemd is going to do Debian a great deal of damage.
I haven't noticed any influence from Red Hat people, apart from the fact that when they make Fedora work better than Debian we want to copy them. I don't think that there will be any problems in Debian related to systemd that compare with having to deal with all the assholes.
After that decision there were a lot of threats and abuse by some people with obvious mental health problems. But such people don't matter when it comes to making a decision because they lack the intelligence or sanity to contribute to Debian in any way.
Too many people are aggrieved by the change to be just your *bad* type of people here. There is no doubt in my mind that systemd and how it has been handled by Debian is a complete disaster.
Fortunately I'm not interested in your opinion. I'll keep working on making systemd work better in Debian. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 11:02 AM, Russell Coker wrote:
Fortunately I'm not interested in your opinion. I'll keep working on making systemd work better in Debian.
As usual you bring out the worst in me like no-one else seems to be able to do, so F U and your opinions too. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 9/10/2014 11:02 AM, Russell Coker wrote:
Fortunately I'm not interested in your opinion. I'll keep working on making systemd work better in Debian.
As usual you bring out the worst in me like no-one else seems to be able to do, so F U and your opinions too.
Why don't you find some distribution that is going to stick with an older init system and contribute some code to it? To make this clearer, if you aren't going to contribute then your comments on mailing lists aren't of any use to anyone. Lots of people want to tell others how to do things, but if they don't have the money to pay someone or the skill to do some work then it doesn't matter. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 12:51 PM, Russell Coker wrote:
Why don't you find some distribution that is going to stick with an older init system and contribute some code to it?
Perhaps I will move to FreeBSD someday, but in the meantime it seems that it will be possible to run Jessie sans systemd ... so that will buy me time.
To make this clearer, if you aren't going to contribute then your comments on mailing lists aren't of any use to anyone. Lots of people want to tell others how to do things, but if they don't have the money to pay someone or the skill to do some work then it doesn't matter.
There are more ways to contribute, opinion is just one way and it should be appreciated like any other type of contribution -- unless the opinion is misplaced and not indicative of a reasonable number of users; given that so many people share my opinion on systemd, then it sure is not misplaced. Those that support systemd are wiping their feet on sysvinit and deciding that no opposing opinion matters, full stop. systemd is a debacle, good luck making it workable for yourself and others whom believe it is the /right/ way forward irregardless to popular opinion of most users -- including the silenced [moderated posts? thread] majority whom care like myself. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 9/10/2014 12:51 PM, Russell Coker wrote:
Why don't you find some distribution that is going to stick with an older init system and contribute some code to it?
Perhaps I will move to FreeBSD someday, but in the meantime it seems that it will be possible to run Jessie sans systemd ... so that will buy me time.
If sysvinit works well enough for you in Jessie then why complain?
To make this clearer, if you aren't going to contribute then your comments on mailing lists aren't of any use to anyone. Lots of people want to tell others how to do things, but if they don't have the money to pay someone or the skill to do some work then it doesn't matter.
There are more ways to contribute, opinion is just one way and it should be appreciated like any other type of contribution
No, it's just annoying. Technical analysis of the features and relative merits of different software has some value. Opinion is useless.
-- unless the opinion is misplaced and not indicative of a reasonable number of users; given that so many people share my opinion on systemd, then it sure is not misplaced. Those that support systemd are wiping their feet on sysvinit and deciding that no opposing opinion matters, full stop.
It doesn't matter how many people are wrong. We have technical problems to solve. That's the thing about science, your opinion doesn't change how things work.
systemd is a debacle, good luck making it workable for yourself and others whom believe it is the /right/ way forward irregardless to popular opinion of most users -- including the silenced [moderated posts? thread] majority whom care like myself.
Install it and it just works. The only problem I've seen with systemd is the journal file being excessively fragmented on BTRFS. As you don't use BTRFS that won't be an issue for you, but if you did then you could just configure systemd to limit the size of it's journal (which is a good idea anyway). -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 1:44 PM, Russell Coker wrote:
systemd is a debacle, good luck making it workable for yourself and others whom believe it is the /right/ way forward irregardless to popular opinion of most users -- including the silenced [moderated posts? thread] majority whom care like myself.
Install it and it just works.
For some, not for everyone -- that's why you are still trying to make it work by your own admission???
The only problem I've seen with systemd is the journal file being excessively fragmented on BTRFS. As you don't use BTRFS that won't be an issue for you, but if you did then you could just configure systemd to limit the size of it's journal (which is a good idea anyway).
I've heard of one case where an auto-mount USB device that wasn't connected at boot time caused systemd to fail to boot the OS, even though the file system on the USB device wasn't significant for the boot process at all. There are more systemd issues, but most of all, the so called ills of sysvinit are due to poor [errors] configuration and not a failing of sysvinit itself. People often mocked Debian for being stale for the stable installations ... give me stale with sysvinit any day, it works very well -- don't force packages to depend on systemd, it is not wanted, nor warranted; fix any apparent configuration issues [that's all they of the issues that exist] with sysvinit and you don't have any need for systemd. Upstream, for gnome and network-manager, well they need to remove reliance on systemd and fix their own issues relating to configuration with sysvinit. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 9/10/2014 1:44 PM, Russell Coker wrote:
systemd is a debacle, good luck making it workable for yourself and others whom believe it is the /right/ way forward irregardless to popular opinion of most users -- including the silenced [moderated posts? thread] majority whom care like myself.
Install it and it just works.
For some, not for everyone -- that's why you are still trying to make it work by your own admission???
Not sure what you mean by this. If you are referring to BTRFS optimisation, the alternative is poor performance when such files are accessed sequantially. But that's usually only done for backups and an alternative option is to exclude them from backups. If you are referring to other general development work the thing you need to know is that any software that works well does so because lots of programmers work on it. Software doesn't magically work by itself.
The only problem I've seen with systemd is the journal file being excessively fragmented on BTRFS. As you don't use BTRFS that won't be an issue for you, but if you did then you could just configure systemd to limit the size of it's journal (which is a good idea anyway).
I've heard of one case where an auto-mount USB device that wasn't connected at boot time caused systemd to fail to boot the OS, even though the file system on the USB device wasn't significant for the boot process at all.
Did you file a bug report?
There are more systemd issues, but most of all, the so called ills of sysvinit are due to poor [errors] configuration and not a failing of sysvinit itself.
Using cgroups to track daemons to allow reliable shutdown is one feature that solves significant problems with SysVInit.
People often mocked Debian for being stale for the stable installations ... give me stale with sysvinit any day, it works very well -- don't force packages to depend on systemd, it is not wanted, nor warranted; fix any apparent configuration issues [that's all
When a package depends on systemd it does so for a technical reason. No-one is putting in gratuitous dependencies.
they of the issues that exist] with sysvinit and you don't have any need for systemd. Upstream, for gnome and network-manager, well they need to remove reliance on systemd and fix their own issues relating to configuration with sysvinit.
I don't use NetworkManager. The Gnome developers have reasons for using systemd, feel free to read debian-devel or any other mailing list where such things are discussed. On Thu, 9 Oct 2014, "Peter Ross" <Petros.Listig@fdrive.com.au> wrote:
From: "Russell Coker" <russell@coker.com.au>
Technical analysis of the features and relative merits of different software has some value.
For a FreeBSD user it is annoying if a well-known Unix/Linux desktop environment gets "Linuxalized" via systemd etc. It is obviously harder to port it to other than Linux if you think of systemd during development in the first place.
What does Gnome do that is so hard to port to non-systemd? Also there's nothing stopping you from just porting systemd to BSD. I think that upstream don't want to take the patches, but that's the same situation as OpenSSH...
The init scripts are grown in nearly half a century and are well-thought through.
Apart from the majority of scripts that have grown without being well thought through. Consider the startup process for MySQL as one of many horrible examples.
In substance, a daemon start/stop script looks the same under all kinds of Unix. A postfix start/stop scripts runs under any kind of Unix/Linux so - minimizing the work to integrate it in any kind of distribution.
The actual start/stop of the Postfix "master" process is the smallest part of it (in Debian at least). Most of it is about maintaining the chroot environment. Admittedly that chroot stuff would also apply to systemd, but your claims of Postfix scripts being the same on all kinds of Unix are obviously wrong.
For a physical server I wait for the hardware when booting, the OS initialisation only take seconds.
A jail is running more or less immediately. The gain will be in millisecond range.
Other people get different results.
[This is opinion] The history of Linux daemons close to the hardware (udev, hald, policy-kit, dbus, kdbus) as well as filesystem layout (procfs,sysfs) does not convince me.
The history of all the alternatives shows the benefit of udev.
It all feels half-baked (sometimes even a bit narrow-minded, "I need this for me here now", and there are huge egos involved it seems) and I am not confident about quality and security of the code which is redone every few years and with competition between different approaches (and with this, splits in attention and effort).
Except that it's not being done every few years. We're talking about a change in default that's once only in the history of distributions such as Debian. On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
This is the type of arguments that supporters of Dubya used to use. Anyone who disagrees is "divisive". -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 6:10 PM, Russell Coker wrote:
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au>
The only problem I've seen with systemd is the journal file being excessively fragmented on BTRFS. As you don't use BTRFS that won't be an issue for you, but if you did then you could just configure systemd to limit the size of it's journal (which is a good idea anyway).
I've heard of one case where an auto-mount USB device that wasn't connected at boot time caused systemd to fail to boot the OS, even though the file system on the USB device wasn't significant for the boot process at all.
Did you file a bug report?
It wasn't me, I read about it on debian-user some time before the moderated/filtered posts was implemented. There are that many threads and posts on systemd [predominantly negative as you must know] .... I'm afraid that one might have gotten lost if nobody acted upon the issue.
There are more systemd issues, but most of all, the so called ills of sysvinit are due to poor [errors] configuration and not a failing of sysvinit itself.
Using cgroups to track daemons to allow reliable shutdown is one feature that solves significant problems with SysVInit.
That sounds reasonable, but there are normal K scripts in sysvinit that should handle it just as well.
People often mocked Debian for being stale for the stable installations ... give me stale with sysvinit any day, it works very well -- don't force packages to depend on systemd, it is not wanted, nor warranted; fix any apparent configuration issues [that's all
When a package depends on systemd it does so for a technical reason. No-one is putting in gratuitous dependencies.
So, how in the hell did gnome survive before systemd? Also, network-manager ? Just to pick two packages.
I don't use NetworkManager. The Gnome developers have reasons for using systemd, feel free to read debian-devel or any other mailing list where such things are discussed.
I wonder if those reasons are significant or just excuses to support systemd lazily. XFCE and KDE don't need systemd do they? Why should gnome?
What does Gnome do that is so hard to port to non-systemd?
Why did gnome go down the systemd track anyway? They didn't need it before systemd existed.
Also there's nothing stopping you from just porting systemd to BSD. I think that upstream don't want to take the patches, but that's the same situation as OpenSSH...
Lots more work to port things when things have un-wanted dependencies, which for all we know, may be artificial in order to drive systemd forward into /acceptance/ when it would otherwise lean more towards rejection.
The init scripts are grown in nearly half a century and are well-thought through.
Apart from the majority of scripts that have grown without being well thought through. Consider the startup process for MySQL as one of many horrible examples.
So, fix how MySql starts, don't impose the whole mess of systemd on the world, just fix MySql... that would surely be simpler.
The actual start/stop of the Postfix "master" process is the smallest part of it (in Debian at least). Most of it is about maintaining the chroot environment. Admittedly that chroot stuff would also apply to systemd, but your claims of Postfix scripts being the same on all kinds of Unix are obviously wrong.
I couldn't care less, make it work for any startup system -- in this case, fix Postfix so that it can startup without issues with any type of system startup/shutdown components.
For a physical server I wait for the hardware when booting, the OS initialisation only take seconds.
A jail is running more or less immediately. The gain will be in millisecond range.
Other people get different results.
Maybe, but I would bet that many would have no trouble with standard sysvinit startup if they optimized it as they could.
Except that it's not being done every few years. We're talking about a change in default that's once only in the history of distributions such as Debian.
A significant change that the majority of ordinary users DO NOT want.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
This is the type of arguments that supporters of Dubya used to use. Anyone who disagrees is "divisive".
What is divisive is the moderation / filtering of the Debian-User list to support the very strong stance taken on systemd vs sysvinit in particular, which is clearly against the will of the people ... Debian Users in this case. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
This is the type of arguments that supporters of Dubya used to use. Anyone who disagrees is "divisive".
What is divisive is the moderation / filtering of the Debian-User list to support the very strong stance taken on systemd vs sysvinit in particular, which is clearly against the will of the people ... Debian Users in this case.
Debian-user is not for arguing about Debian design decisions. Not many DDs even bother reading it. Filtering out off-topic mail and people who are abusive is a good thing. While Debian is a democracy in some ways, it's not one in which you get a vote. DDs get to vote. Contribute code, apply to become a DD, and then you'll get a vote. On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Sure, but Russell didn't remember what he wrote and to which I was referring.
I know what I wrote, determining what you are referring to is the difficult part.
Anyway, it's clear to me at this time that systemd is turning out to be a problem of the scale of Windows 8.
Apart from the fact that any given version of Windows only has one GUI with no choice. While the people who create distributions of Linux can choose which version of init they want to use. It seems that all the major distributions are going to systemd, but non-programmers think they know better.
Perhaps that's not fair, but perhaps it is ... only time will tell. I know that I don't want to be wasting my efforts on something that is destined to become a bad part of history and I hope that systemd goes that way, the sooner, the better.
Fortunately you aren't wasting any efforts as you aren't putting any effort into developing a distribution.
In effect, if I was able to, and I know that I can't, then I would be saving Russell plenty of wasted time; of course I could be wrong and it wouldn't be the first time -- but I'm not enjoying how this is panning out as a Debian supporter.
The best way to save me time would be to stop saying silly things about Debian development. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 11:10 PM, Russell Coker wrote:
The best way to save me time would be to stop saying silly things about Debian development.
The more I read, the worse it gets, perhaps you need to be reading more on debian-user to have a chance to understand the issues since you don't consider my input useful. A.
Russell Coker <russell@coker.com.au> writes:
What does Gnome do that is so hard to port to non-systemd?
IIRC, at least initially, the feature that had a hard requirement on systemd was serving multiple independent, concurrent user sessions (keyboard/video/mouse) from a single workstation.
On 10 October 2014 10:27, Trent W. Buck <trentbuck@gmail.com> wrote:
Russell Coker <russell@coker.com.au> writes:
What does Gnome do that is so hard to port to non-systemd?
IIRC, at least initially, the feature that had a hard requirement on systemd was serving multiple independent, concurrent user sessions (keyboard/video/mouse) from a single workstation.
My understanding is it isn't so much "hard", but somebody has to write the interfaces to work without systemd. I believe this is the point of the systemd-shim package in Debian: https://packages.debian.org/sid/systemd-shim Sometimes people have a misconception that this is part of systemd due to the name; it isn't. It is the reimplementation of the interfaces systemd provides without using systemd. In the past, IIRC, it has suffered from neglect; I assume it is ok now though (I don't care, I intend to use systemd). My understanding is when people have complained that package XYZ requires systemd, it is often because systemd-shim needs more work - e.g. it doesn't implement all the required interfaces. -- Brian May <brian@microcomaustralia.com.au>
To make this clearer, if you aren't going to contribute then your comments on mailing lists aren't of any use to anyone. Lots of people want to tell others how to do things, but if they don't have the money to pay someone or the skill to do some work then it doesn't matter.
And that's why people give up and use Windows. Microsoft doesn't care about your opinions or helpful suggestions either, of course, but at least nobody expects them to. And when someone asks for help, Microsoft might be unhelpful at times, but at least they aren't hostile and tell you that you and your opinions don't matter. James
On Thu, 9 Oct 2014, James Harper <james@ejbdigital.com.au> wrote:
To make this clearer, if you aren't going to contribute then your comments on mailing lists aren't of any use to anyone. Lots of people want to tell others how to do things, but if they don't have the money to pay someone or the skill to do some work then it doesn't matter.
And that's why people give up and use Windows. Microsoft doesn't care about your opinions or helpful suggestions either, of course, but at least nobody expects them to. And when someone asks for help, Microsoft might be unhelpful at times, but at least they aren't hostile and tell you that you and your opinions don't matter.
Andrew never asked for help. He asked me and all the other Debian developers to do things his way. He thinks that he knows better than us how to design a distribution of Linux. Try telling MS how to design the next version of Windows and see how far you get. Note the significant negative reviews of Vista and Windows 8 and the lack of interest that MS shows in such reviews. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/10/2014 5:54 PM, Russell Coker wrote:
Try telling MS how to design the next version of Windows and see how far you get. Note the significant negative reviews of Vista and Windows 8 and the lack of interest that MS shows in such reviews.
Actually, with the latest "Windows Next" or "Windows 10", Microsoft are going out of their way to really listen to users ... at least that is story now. They know they screwed up Windows 8 for so many people, so they have back tracked with Windows 10 which has already taken some of the most major problems into account, there is no longer two interfaces to fight over, but one that works more closely to the Windows 7 desktop when using a desktop machine (different on a Windows Phone or table though). The /new/ experience varies depending on the device, but is generally much improved over Windows 8 even though it is only at the preview stage at this time ... user feedback will help drive the changes for the proper release in due course. Does Debian want systemd to be their Windows 8 ? It seems like it. A.
On 09.10.14 18:26, Andrew McGlashan wrote:
On 9/10/2014 11:02 AM, Russell Coker wrote:
..................... I'll keep working on making systemd work better in Debian.
The effort would be better spent fixing /perceived/ problems with sysvinit, quite frankly.
We are all entitled to determine how we spend our own time, and that of anyone whose time we buy. Attempting to dictate how a volunteer developer should work seems to irrationally disregard all concepts of individual freedom, and cast the benefactor as an owned slave. As users, we could reasonably ask for the opportunity to choose between alternatives, though it may be necessary to get off our backsides, and maintain any of the old stuff we want to keep as an option. That would be the test of the validity of our technical opinions, I believe. Erik -- The world is full of willing people, some willing to work, the rest willing to let them. - Robert Frost
On 9/10/2014 7:11 PM, Erik Christiansen wrote:
On 09.10.14 18:26, Andrew McGlashan wrote:
On 9/10/2014 11:02 AM, Russell Coker wrote:
..................... I'll keep working on making systemd work better in Debian.
The effort would be better spent fixing /perceived/ problems with sysvinit, quite frankly.
We are all entitled to determine how we spend our own time, and that of anyone whose time we buy. Attempting to dictate how a volunteer developer should work seems to irrationally disregard all concepts of individual freedom, and cast the benefactor as an owned slave.
Sure, but Russell didn't remember what he wrote and to which I was referring. Anyway, it's clear to me at this time that systemd is turning out to be a problem of the scale of Windows 8. Perhaps that's not fair, but perhaps it is ... only time will tell. I know that I don't want to be wasting my efforts on something that is destined to become a bad part of history and I hope that systemd goes that way, the sooner, the better. In effect, if I was able to, and I know that I can't, then I would be saving Russell plenty of wasted time; of course I could be wrong and it wouldn't be the first time -- but I'm not enjoying how this is panning out as a Debian supporter. Cheers A.
On 09.10.14 19:22, Andrew McGlashan wrote:
In effect, if I was able to, and I know that I can't, then I would be saving Russell plenty of wasted time; of course I could be wrong and it wouldn't be the first time -- but I'm not enjoying how this is panning out as a Debian supporter.
Ah, up till now, the generosity of your efforts was hidden. Still, such certitude reminds me of: Prediction is very difficult, especially of the future. - Niels Bohr ISTM that if neither upstart nor systemd deliver the goods once finished, then a third new offering will arise. Parallel starting of services, and effective handling of events will be provided, one way or another, I expect. Incidentally, if any of your posts on this thread have described a specific showstopper that you have personally experienced in systemd, or can tell us how to replicate, then I have missed it. I'm quite prepared to blow raspberries at systemd too, but would need a real-world reason to do so. Erik
Hi, On 9/10/2014 7:46 PM, Erik Christiansen wrote:
ISTM that if neither upstart nor systemd deliver the goods once finished, then a third new offering will arise. Parallel starting of services, and effective handling of events will be provided, one way or another, I expect.
Perhaps. What makes a monolithic piece of software, like systemd the answer? Traditional Linux/Unix is built around processes that do ONE thing very well and without re-inventing the wheel. Sure we have choices where multiple wheels are available, but usually those wheels can act stand alone from competing wheels without locking in the car to use a specific wheel ... so to speak.
Incidentally, if any of your posts on this thread have described a specific showstopper that you have personally experienced in systemd, or can tell us how to replicate, then I have missed it.
What makes you so sure that I must have personally suffered from the use of systemd? I read fairly widely on matters to do with system administration works that I do for my own servers and servers of other people and clients. Therefore, I have gained some knowledge in relation to systemd and the nightmares that others are experiencing. I am also a user of sysvinit for a significant period of time and find that arguments against sysvinit are shallow and not worthy to cause it's demise.
I'm quite prepared to blow raspberries at systemd too, but would need a real-world reason to do so.
There is real world experience in other systems that can count as well. The enormity of the systemd change should not be understated. There is often a case for no change or more limited change when change is actually necessary. There is also a place for other modular type solutions to perceived problems of sysvinit as well as /fixing/ the broken scripts that are to blame for pushing forward a replacement when none is really warranted. Have a nice day. A.
I would also like to "me too" this latest post by another on debian-user list: On 9/10/2014 8:41 PM, Tomasz Kundera wrote:
I'd like to say "me too" as the shortest opinion. Dealing with local networks it is absolutely not important how much time the boot takes. Most machines works all the time. During maintenance reboots I can wait a few seconds more. But the complete lack of simplicity and transparency is horrible. Binary logs are horrible, too. Logs are mostly needed when some troubles arises. In that situation they should be accessible as easy and fast as possible. Often there will be no possibility to start a dedicated binary log analyzer. You need only "more" and "sed" to deal with text logs. systemd with no possibility to stay with SystemV is a horrible mistake.
That embodies a fair bit that is wrong with systemd, certainly by itself, it enough to make many [most?] people prefer to avoid the trials and tribulations that will await them with systemd if at all possible. Of course, I use "less" instead of "more" as it is far more versatile, that is a very good transition to a better option; which cannot be said of systemd. I would also work with vim, awk, grep, zgrep, zcat and other tools, but these only work on non binary logs (excluding the /binary/ status of gzipped files). A.
On 9/10/2014 10:47 AM, Andrew McGlashan wrote:
On 9/10/2014 10:40 AM, Andrew McGlashan wrote:
Hi,
$ sed 's/s.st.md/the Rabbit of Caerbannog/' ....
The more I read about the use of this *special* package, the more I understand how deep this is as a disaster. If you think otherwise, keep reading, the horror stories are there for everyone to see on the debian-users list [and other places], even if new horror stories are /hidden/ from view by moderation and/or filtering! When you too are convinced that the package is a disaster, then you might have read enough -- until then please keep reading and to any DDs out there with a conscience, please make sure a GR gets up to address this ASAP or there will be a mass exodus of users when they are forced to live with this package at some time in the future -- for many, in the meantime, they'll manage to avoid it, at least until they can't possibly avoid it. The default gnome desktop is going to make it harder to ignore and much more likely to provide many more horror stories. I can't be more blunt than that. THIS IS A COMPLETE DISASTER WAITING TO HAPPEN. Cheers A.
On 09.10.14 23:40, Andrew McGlashan wrote:
If you think otherwise, keep reading, the horror stories are there for everyone to see on the debian-users list [and other places], even if new horror stories are /hidden/ from view by moderation and/or filtering!
Er, Andrew, have you taken your frog pills today? Most of your posts on this thread have had little or no information content, and the latest hyperventilation is no exception. May I ask a couple of questions, please? a) What should we read if the "horror stories" are hidden/moderated or whatever? There won't be any there then, will there? b) If there is any attribute of systemd which is genuinely horrible, then do you think that you have the capacity to render a rational description of how to replicate the abomination? c) Since systemd is a sysV init substitute, it ought to be manageable to build debian with the substitution reversed, given the hordes who ostensibly support your cause. If none of them will lift a finger to help the cause, then they are passengers, with the passenger's right to get off the bus if it isn't going their way. d) Is changing to another distro, which does not use systemd, likely to prove fatal, or even make your hair fall out? And if the distros all change to systemd, then how "horrible" can it really be? Of the various vague attempts to be scary, the dire warnings of "binary logs" thus far seem to be the most solidly irritating potentiality. But how slow can the log decoder possibly be? And then the log is text, innit? It's spring. Plant a pumpkin. Make a scary mask. It'll enhance your sales pitch 500% - minimum. Erik P.S. Oh, I get it now. You're advertising _in_favour_ of systemd, by piquing our curiosity with fake pseudo-scariness, to make us eager to try it. It's working on me. :-) -- The universe contains any amount of horrible ways to be woken up, such as the noise of the mob breaking down the front door, the scream of fire engines, or the realization that today is the Monday which on Friday night was a comfortably long way off. - Terry Pratchett, _Moving Pictures_
On 10/10/2014 12:19 AM, Erik Christiansen wrote:
On 09.10.14 23:40, Andrew McGlashan wrote:
If you think otherwise, keep reading, the horror stories are there for everyone to see on the debian-users list [and other places], even if new horror stories are /hidden/ from view by moderation and/or filtering!
Er, Andrew, have you taken your frog pills today? Most of your posts on this thread have had little or no information content, and the latest hyperventilation is no exception. May I ask a couple of questions, please?
Do what you want, I'll just provide a couple more links and I'm done [for now], I'm too tired and with a lack of time and resources to deal with all the issues that are likely to pose problems with systemd. http://draketo.de/light/english/top-5-systemd-troubles http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rag... http://boycottsystemd.org/ http://distrowatch.com/weekly.php?issue=20140908#qa - possibly most balanced and non-anti systemd reference, but still worth a read. Lots of discussion here too: [make of it what you will, make up your own mind, -right now, my mind is made up -- avoid systemd at all costs where possible] https://news.ycombinator.com/item?id=7222313 I'm sure if you look widely enough, you will find plenty of pros as well as plenty of cons, but with my research, the cons far outweigh the pros by a great deal. Add to that the moderation/filtering taking place on Debian Users mail list and you can be very sure that loads of problems aren't being allowed to see light of day in reporting. A.
On Fri, 10 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
I'm sure if you look widely enough, you will find plenty of pros as well as plenty of cons, but with my research, the cons far outweigh the pros by a great deal. Add to that the moderation/filtering taking place on Debian Users mail list and you can be very sure that loads of problems aren't being allowed to see light of day in reporting.
http://en.wikipedia.org/wiki/Confirmation_bias Debian mailing list filtering is to stop abuse not bug reports. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 10/10/2014 1:01 AM, Russell Coker wrote:
On Fri, 10 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
I'm sure if you look widely enough, you will find plenty of pros as well as plenty of cons, but with my research, the cons far outweigh the pros by a great deal. Add to that the moderation/filtering taking place on Debian Users mail list and you can be very sure that loads of problems aren't being allowed to see light of day in reporting.
Pot, kettle, black -- right back at you Russell, time and time again. A.
Trying to very quickly appease your request. On 10/10/2014 12:19 AM, Erik Christiansen wrote:
a) What should we read if the "horror stories" are hidden/moderated or whatever? There won't be any there then, will there?
Google is often your friend, there are still many systemd threads on DU list -- and systemd has been around long enough for much information to be found, both positive and negative, even if the weight is strongly on the negative side.
b) If there is any attribute of systemd which is genuinely horrible, then do you think that you have the capacity to render a rational description of how to replicate the abomination?
Not being able to look through simple plain text log files is very significant. A failure of any single part of systemd could easily mean you have an non-bootable system. Aren't those two things significant enough? systemd is encroaching on far too many aspects of system operation and the developer team for systemd is reportedly just two people, one of which has great interest in Red Hat. Add to the fact that gnome depends on systemd and Debian is moving back to gnome desktop default and you know where this is all heading. It looks like it's time to escape Debian -- or at least in the not too distant future.
c) Since systemd is a sysV init substitute, it ought to be manageable to build debian with the substitution reversed, given the hordes who ostensibly support your cause. If none of them will lift a finger to help the cause, then they are passengers, with the passenger's right to get off the bus if it isn't going their way.
There is madness, one of the posts that I linked to previously expressed the concerns of a Linux kernel developer with all his difficulties in using systemd, read that and then conclude that systemd is ready for the masses .... then I'll say you are deluded.
d) Is changing to another distro, which does not use systemd, likely to prove fatal, or even make your hair fall out? And if the distros all change to systemd, then how "horrible" can it really be?
The question is why are [most] going that way? Not all distros are, there are still exceptions as highlighted in the distrowatch newsletter that I linked to. A real, but short term alternative is to move to Debian kFreeBSD, but even that is mentioned on the list as a possible dead end in the not too distant future due to support issues -- those issues will be magnified if maintainers need to keep non systemd operational for the kFreeBSD builds; you can see it dropping off very quickly. That leaves going full on to FreeBSD or some other BSD alternative to escape the problems and dangers of systemd. Oh and with Debian, if you aren't running at least stable in Wheezy, then you better have an x86 based machine with squeeze-lts or you won't get updates .... even those updates with squeeze-lts are done by a team that doesn't include Debian Security -- not saying that team is not good, but it's more of a risk than running Wheezy and Jessie isn't ready yet. There may be Wheezy-lts, but only time will tell on that. The days of having a non systemd Debian distro are really quite numbered unless DDs start to understand the risks and problems and get a GR through to remove the track to systemd ASAP. If you want to get newer than Wheezy, well you'll have Jessie [upcoming stable version to replace Wheezy] with the new default desktop being gnome (re-instated) and you know who mostly maintains gnome [Red Hat] and with gnome, you almost definitely must have systemd for it to work with Debian. If you don't want gnome and don't want systemd, then you will have choices in Jessie by the look of it, but who knows if the any later releases will remove a choice to run a non systemd system -- we can see it coming, time to jump off the band wagon or plan to do so before it is too late and you end up running a completely unsupported OS. That is, unless a GR gets up and stops this disaster train from going forward with Debian. Old stable in plain squeeze is no longer supported, next best is squeeze-lts unless you can upgrade to Wheezy.
Of the various vague attempts to be scary, the dire warnings of "binary logs" thus far seem to be the most solidly irritating potentiality. But how slow can the log decoder possibly be? And then the log is text, innit?
If you have an non-bootable system and then you need to rely on a Live boot to try and discover the issues, then time is of the essence and parsing binary log files, even with good tools is going to be a problem. Your downtime is quite likely going to be significantly longer if you can't find the right log file extracted from the binary logs to give you the answers you need to resolve the issues at hand.
It's spring. Plant a pumpkin. Make a scary mask. It'll enhance your sales pitch 500% - minimum.
Haha. Take this seriously, if all Linux distros go systemd, it will be like a black box to many and whilst it might work well overall, there will be more than enough troubles to seriously make it not worth the effort, let alone the risk of running systemd on production systems. If your use is just as a hobby, then this is all a moot consideration, however if you rely on systems for DNS, mail, web and/or other services, then you are putting your systems at too much risk with systemd -- it is not worth that risk in my view, given all that I've read about the issues and problems. If you want to profit from consulting services, then going systemd might be a good income stream for you, that is if your clients can afford the high cost of maintenance due to systemd installation and the real potential problems. Today, it's bad enough trying to get Xen working on some machines, that's without the added burden of systemd ... and yes, it is much more added burden and much more risk that things won't work for one reason or another and you are relying on one large binary that wants to handle everything critical to the system. A.
On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 9/10/2014 7:46 PM, Erik Christiansen wrote:
ISTM that if neither upstart nor systemd deliver the goods once finished, then a third new offering will arise. Parallel starting of services, and effective handling of events will be provided, one way or another, I expect.
Perhaps. What makes a monolithic piece of software, like systemd the answer? Traditional Linux/Unix is built around processes that do ONE thing very well and without re-inventing the wheel. Sure we have choices where multiple wheels are available, but usually those wheels can act stand alone from competing wheels without locking in the car to use a specific wheel ... so to speak.
You may be thinking of GNU/HURD. Linux has always had a monolithic kernel because it performs better.
I'm quite prepared to blow raspberries at systemd too, but would need a real-world reason to do so.
There is real world experience in other systems that can count as well. The enormity of the systemd change should not be understated. There is often a case for no change or more limited change when change is actually necessary. There is also a place for other modular type solutions to perceived problems of sysvinit as well as /fixing/ the broken scripts that are to blame for pushing forward a replacement when none is really warranted.
But when developing software real-world experience in developing such software counts for a lot. I've been a DD for ~14 years. I know how Debian works. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Thu, Oct 09, 2014 at 07:46:36PM +1100, Erik Christiansen wrote:
ISTM that if neither upstart nor systemd deliver the goods once finished, then a third new offering will arise. Parallel starting of services, and effective handling of events will be provided, one way or another, I expect.
that's the problem with systemd - once it takes over, this "third new offering" will never happen because in order to have even a chance of success it will not only have to do init's job, it will have to do dozens of other unrelated tasks. and it will have to do them *ALL* from the very first version. craig -- craig sanders <cas@taz.net.au>
Hi, On 10 October 2014 09:25, Craig Sanders <cas@taz.net.au> wrote:
On Thu, Oct 09, 2014 at 07:46:36PM +1100, Erik Christiansen wrote:
ISTM that if neither upstart nor systemd deliver the goods once finished, then a third new offering will arise. Parallel starting of services, and effective handling of events will be provided, one way or another, I expect.
that's the problem with systemd - once it takes over, this "third new offering" will never happen because in order to have even a chance of success it will not only have to do init's job, it will have to do dozens of other unrelated tasks. and it will have to do them *ALL* from the very first version.
I'm no expert on all this, but I stumbled across something which looks interesting: uselessd http://uselessd.darknedgy.net/ --- uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design. uselessd is still in its early stages and it is not recommended for regular use or system integration, but nonetheless, below is what we have thus far. ... --- Thanks, John
On 10 October 2014 09:25, Craig Sanders <cas@taz.net.au> wrote:
that's the problem with systemd - once it takes over, this "third new offering" will never happen because in order to have even a chance of success it will not only have to do init's job, it will have to do dozens of other unrelated tasks. and it will have to do them *ALL* from the very first version.
I believe systemd has a modular design, you don't have to enable everything. e.g. if you want to continue using ifupdown or network-manager or anything else, you can continue to do so. You can use systemd without systemd-networkd. -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> writes:
I believe systemd has a modular design, you don't have to enable everything.
e.g. [...] You can use systemd without systemd-networkd.
According to https://bugs.debian.org/730059 you can't use systemd without using its klogd. (You *can* use it with a syslogd, tho.)
On Fri, Oct 10, 2014 at 11:25:27AM +1100, Brian May wrote:
On 10 October 2014 09:25, Craig Sanders <cas@taz.net.au> wrote:
that's the problem with systemd - once it takes over, this "third new offering" will never happen because in order to have even a chance of success it will not only have to do init's job, it will have to do dozens of other unrelated tasks. and it will have to do them *ALL* from the very first version.
I believe systemd has a modular design, you don't have to enable everything.
e.g. if you want to continue using ifupdown or network-manager or anything else, you can continue to do so. You can use systemd without systemd-networkd.
an individual may be able to choose to disable some of systemd's features, but a systemd-replacement can not because it can not know which features (if any) other people choose to disable. at the moment, this problem is less than obvious because we're still in a transition phase - most people are still using other programs for the functions that systemd is taking over. it's a lot easier to switch to software that gradually, through feature-creep, replaces dozens of other programs than it would be to, when systemd is ubiquitous, replace systemd with dozens of other programs all at once. i.e. the transition to systemd is likely to be one-way, impossible or immensely difficult to revert. craig -- craig sanders <cas@taz.net.au>
I had been emailing Don Armstrong, a DD, about my concerns. One very worrying aspect of that was the choice was either systemd or upstart; there should have been a third option to continue entirely with the status quo of sysvinit -- that third option wasn't a consideration. So we are damned no matter which choice as many don't like upstart either, although I am not sure it is as big a problem as systemd though. When the tech ctte voted, it was 4 for upstart, 4 for systemd and then it was decided by, I believe, the chairman whom chose systemd. Such a huge change as this is should require almost unanimous support .. at least 75% ... otherwise, in my view, the change should not go ahead. If it divides the tech ctte almost 50/50, then there is no doubt it is going to divide the whole Debian community to a great extent. We really must have a DD put forward a GR to get this mess sorted. A.
I had been emailing Don Armstrong, a DD, about my concerns.
One very worrying aspect of that was the choice was either systemd or upstart; there should have been a third option to continue entirely with the status quo of sysvinit -- that third option wasn't a consideration.
Got a citation for that? Everything I've read is that the vote was for one of 5 choices: " D systemd U upstart O openrc V sysvinit (no change) F requires further discussion " And that there was only one vote for the status quo, and that person voted for further discussion in preference to that. (https://lists.debian.org/debian-ctte/2014/02/msg00281.html) James
On 10/10/2014 8:50 PM, James Harper wrote:
I had been emailing Don Armstrong, a DD, about my concerns.
One very worrying aspect of that was the choice was either systemd or upstart; there should have been a third option to continue entirely with the status quo of sysvinit -- that third option wasn't a consideration.
Got a citation for that?
Everything I've read is that the vote was for one of 5 choices: " D systemd U upstart O openrc V sysvinit (no change) F requires further discussion "
I've read so much, unfortunately alot more negative -- I was wrong, you are right. Thank you.
And that there was only one vote for the status quo, and that person voted for further discussion in preference to that.
(https://lists.debian.org/debian-ctte/2014/02/msg00281.html)
This post has made quite a difference in my understanding and views going forward: http://0pointer.de/blog/projects/the-biggest-myths.html - consequently, I am now *much* less concerned about systemd troubles. I am still not happy about how the DU list is being handled, but that isn't systemd itself. They need a more open discussion list, such as luv-talk, where almost anything goes and ideas / views / opinions can be openly discussed without fear of moderation and/or filtering of conversations that may or may not be relevant or applicable to the general user base and without a dictator like ruling to hide things under the carpet as if they were never said. Cheers A.
On Fri, 10 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
I had been emailing Don Armstrong, a DD, about my concerns.
This discussion has included 3 DDs. The only one who has any concerns about systemd is Craig, and he believes in the way things are run in Debian.
We really must have a DD put forward a GR to get this mess sorted.
But none of the 1000+ DDs want to. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Erik Christiansen <dvalin@internode.on.net> writes:
Parallel starting of services [...] will be provided, one way or another, I expect.
This is done by default on Debian 7 under sysvinit. insserv generates dependency DAGs in /etc/init.d/.depend.*, and startpar uses them to start services in parallel. But I'm sure the systemd advocates already knew that. :-)
Incidentally, if any of your posts on this thread have described a specific showstopper that you have personally experienced in systemd, or can tell us how to replicate, then I have missed it.
I'm not even using systemd and this one got me yesterday: http://bugs.debian.org/762007 1. systemd responds to "debug" in /proc/cmdline by printing SO MUCH CRAP that the system became unusable[0]. 2. kernel devs got annoyed and treat everything after " -- " specially. 3. since debian-installer also used " -- " as a separator[1], it has to be patched for 3.16+ and everyone (me) using that separator has to be retrained. Granted, this will be worked around before it hits stable, and the change in behaviour is minor. When I actually start using it, then I'm sure I can have just as much fun debugging cyclic dependencies in booting off ro NFS as I did with upstart six years ago. [0] exactly the same behaviour as upstart exhibited in 2008, incidentally. [1] to mean "arguments after this should be used during install AND after install", cf. arguments like priority=low and theme=dark, which are passed only to the installer.
Hi, <With my Oracle Linux Product Manager Hat ON/> On 9 Oct 2014, at 1:08 am, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Heck, even Oracle declared it production ready quite some time ago, yet we are still seeing issue after issue --
We are? I just did a query on our internal support request and bug queue and there have been no btrfs issues reported by customers in the past 9 months running our latest Unbreakable Enterprise Kernel Release 3 (3.8.13) on Oracle Linux 6. Yes, there are some issues upstream, but by and large they're extremely edge-case issues that you wouldn't expect to see on production-ready servers running Oracle Linux. Cheers, Avi
Hi Avi, On 9/10/2014 7:35 AM, Avi Miller wrote:
<With my Oracle Linux Product Manager Hat ON/>
;-)
On 9 Oct 2014, at 1:08 am, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Heck, even Oracle declared it production ready quite some time ago, yet we are still seeing issue after issue --
We are? I just did a query on our internal support request and bug queue and there have been no btrfs issues reported by customers in the past 9 months running our latest Unbreakable Enterprise Kernel Release 3 (3.8.13) on Oracle Linux 6.
Yes, there are some issues upstream, but by and large they're extremely edge-case issues that you wouldn't expect to see on production-ready servers running Oracle Linux.
I would bet that /most/ people using Oracle's version of Linux are doing so for the "one choke" reason and those running Oracle databases are storing the data files outside of BTRFS. I wonder just how much BTRFS is actually used on Oracle Unbreakable Linux; yes it is there, but I would bet that it isn't used significantly on Oracle Linux servers. I also subscribe to lists on BTRFS and there is so much noise, that I don't have time to read the posts alot, I read the odd ones that look interesting though. However, the result of all the posts coming through, gives the very strong suggestion to me that BTRFS is far from production ready. Cheers A.
participants (10)
-
Andrew McGlashan -
Avi Miller -
Brian May -
Craig Sanders -
Erik Christiansen -
James Harper -
John Mann -
Peter Ross -
Russell Coker -
trentbuck＠gmail.com