On Sun, Jul 10, 2011 at 03:15:33PM -0400, Jon Masters wrote: > On Sun, 2011-07-10 at 16:32 +0100, Matthew Garrett wrote: > > On Sun, Jul 10, 2011 at 05:46:18AM -0400, Jon Masters wrote: > > The big kernel lock doesn't suck. It's the way SMP UNIX did things for > > dozens of years, and it's the way countless kernel hackers know and > > love. "Sucks" might be true from the point of view of "hey look at this > > great fine-grained locking I just designed", but it's very much not true > > from the poit of the driver author working on the weekend who's just > > thinking "gee, what the heck is going on, why won't this just work how > > it has done for the past twenty years?". In other words "suck" depends > > on viewpoint. > > I get your analogy, and your point. But there's a key difference. In the > kernel community (which is relatively much smaller), there are > established well documented means by which people find out about things > like BKL removal and act upon it. There is LWN, there is LKML, there is > an expectation that those working on the kernel read these things. We have documentation and we have release notes. There's an expectation that admins pay attention to these things. > There should not be, and there is not, an expectation that Linux users > and admins in the wider world follow distribution mailing lists, wiki > pages, and IRC obsessively. Or read blogs. That isn't how it's done. > It's done through slow, gradual change picked up over time, unless you > want the kind of pain that I believe is coming further down the line. The systemd transition hasn't been rapid, and what we're talking about here is a change in best practices rather than a change in what's possible. Your systemd service file can launch a shell script that execs the daemon. You can stick with a SysV init file instead. But both approaches change nothing regarding the intrinsic fragility of sourcing a freeform shell script as application configuration. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
