On 11/16/2014 6:40 AM, Klistvud wrote: > Dne, 21. 10. 2014 04:06:23 je Marty napisal(a): >> On 10/20/2014 03:45 PM, Patrick Bartek wrote: >>> After much vitriolic gnashing of teeth from those opposed to systemd, >>> I wonder... What is a better alternative? And it can't be sysvinit. > > Why not? I do not see sysvinit -- or any other legacy init system, for > that matter -- as contradicting the following: > >> Whichever one the user wants is the best. The users should decide, >> individually and collectively. The distro should be the testbed for >> new ideas, with users trying out and choosing solutions that work best >> for them. Debian should not make that choice for users. "Upstreams" >> should not make that choice for Debian. > > I'll second that. There has been much gnashing of teeth and talking > about forks and pitchforks on this list. Instead of talking of > catastrophic upheavals, such as systemd or forking, why not talk of > refreshing/refurbishing/maintaining sysvinit and other existing systems? > After all, we probably wouldn't be dealing with this hot systemd potato > now had sysvinit been maintained intensely, actively, and with adequate > manpower through all these years. Instead, it has been left more or less > bitrotting on savannah (kudos to the few maintainers working on it > despite the hostile stance of the Linux community), and this major > upheaval is now the result. >
The problem here is lack of time and/or skills. I would love to help, but I already have my plate full. Additionally, I've done device drivers and applications, but never dealt with init systems. There would be a big learning curve. And then there is the politics of being accepted by the DD community. Maybe some people don't think it's too bad - but I get enough politics in real life that I don't want to deal with it in a volunteer position. Most of the qualified people I know are pretty much in the same position. >> >> This is official Debian Policy but some people seem upset about it. > > Exactly. Instead of all the ire, sysvinit & alternatives are in dire > need of some love. Instead of reinventing the square wheel, much of this > misguided energy could be directed toward patching up the old wheels > which, after all, had been serving us -- and serving us well -- for the > last 20 years. > So why, instead of spending all this time on a new init system didn't developers already familiar with sysvinit work on it? Systemd wasn't one person alone. >> I hope this just a misunderstanding that gets cleared up after the >> dust settles and everyone starts talking again, instead of just >> yelling at each other. > > Ditto. I hope some defectors come back to Debian and realize that if > they give Debian/upstream packages some work, many bitrotten packages > may be reinstated into Debian main, without having to make a blend/fork > or whatever. For the benefit of us all. > I don't think this is going to happen. I know a lot of people who are looking at another distro, or even helping with a fork. This includes me. And when I find a distro I like, I won't be coming back. The others feel the same way. I don't change distros very often; it's a lot of work to test new systems before placing in production. And then there is the learning curve. >>> So, what would you all propose? For a server? Or for a user desktop? >>> Or something that fulfills both scenarios? And why? >> >> We all should be able to propose our ideal solution with a reasonable >> expectation that if it's a good idea, and somebody does the work, it >> could be adopted and help other people, without being unduly hindered >> by a software bundle laying exclusive claim to PID 1. > > 1. Reviving the existing init systems. Modernizing them, making them > into true, interchangeable drop-in replacements of each other, which do > the task assigned, and do it well. Each of them accomplishing at least > the common subset of tasks an init system is supposed to provide. > That would be great, but it's not going to happen. The TC has already indicated systemd is going to be the default, and packages are already beginning to require systemd. I predict more and more packages will require systemd as time goes on. > 2. Complementing them with existing or new tools (again, drop-in > interchangeable replacements of each other) which build on them and > provide the next layer. For example, the kernel autofs facility provides > very nice automounting and could be deployed to the majority of desktop > installs (instead of being just an optional package, as it is now), thus > making the various automount daemons of the various desktop > environments/file managers virtually superfluous. As a further example, > the former udev (prior to being merged into systemd) has already been > forked and could/will serve us well for years to come. And so on. > This would also be great. However, who's going to spend the time building these replacements? Maintaining/upgrading sysvinit is minor compared to this job, and even that couldn't be done. > We don't need another Windows, > We don't need to know the way /home > All we want is life beyond the Thunderdome > I agree here. Unfortunately, after the TC's decision, it looks like Debian (along with a lot of other major distributions) is headed this way. I think you have some great ideas. However, I just don't see the desire/manpower to fight the Debian hierarchy. We've already lost one long-time developer; I expect others will follow. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468bb14.3030...@gmail.com