On Tue, Sep 23, 2014 at 08:22:05AM +0900, Joel Rees wrote: > >> * Get rid of run levels. > > > > And the reason for this change is? Runlevels are good where they are, > > even if you don't use them. > > Well, openbsd doesn't have runlevels, and it gets along just fine. > > openbsd does have some things that look sort-of like run levels, and > might have been more mnemonically "named", but not run-levels.
OpenBSD (and all *BSDs for that matter) never used SysV init in the first place. If you need to compare Linux's sysvinit with something similar, you need to compare it with Unix System V Release 4 derivatives, not BSD ones. For example, Solaris 9 (last one that used SysV init), which had runlevels just like Linux has. > The "targets" part of systemd would actually not be such a bad idea, > as an optional package/daemon not running at pid 1, for those who need > the functionality and can get along with the paradigm and choice of > vocabulary/grammar. I would have called it something else, and I'm not > sure I'd have used the dot notation, but a different paradigm works > better for me. 'Targets' defined as arbitrary groups of daemons are OK for me too. They're just unnessesary for the most of the tasks I'd need them. > Likewise, run-levels don't really work well for me as a way to adjust > which services/daemons are running. I'll try to draw an analogy - lack of desire to understand the design of sysvinit (and Unix philosophy in general) is one of the corner design principles of all 'modern FreeDesktop standarts', not-to-be-named-pid1-process-which-name-starts-with-s in particular. "I don't need it = nobody needs it" is one of the things that look awfully bad to the third-party spectator and can lead to very curious design perversions. > >> systemd, cgroups, and dbus are a package. Not so much in the sense of > >> a debian package, rather in the sense of three components of a > >> social-engineering project. Get one in, and it needs the other, so of > >> course it has to come in, and then you have a functional group that > >> require each other and are each others' excuses. And they give the > >> impression of momentum, so busy project leaders think they can depend > >> on them. > > > > You're wrong here. Cgroups are just glorified Linux-specific shell > > limits. There's nothing in them that requires usage of s*stemd or dbus. > > I think you are saying that there is an implementation of cgroups > independent of systemd? Yup. In fact, I use such implementation on daily basis in Debian Wheezy with good old sysvinit. I really don't understand what's so special about it as cgroups are kernel facility introduced in 2.6.32 IIRC. > Well, the original cgroups, maybe not. I need to look at the original > more carefully, but I would worry about things like how well cgroups > is integrated with the pre-existing quota functionality, and whether > there would be user/admins who would shoot themselves in the foot > thereby. There're no 'original cgroups' or 'new cgroups'. There're just cgroups. They change as kernel change, that's the way all kernel interfaces evolve. > One thing I'll examine closely is whether cgroups tries to extend the > permissions model or tries to work within it. Extending the > permissions model is a no-no in my book. No, that's the thing that cgroups don't touch. Limit cpu usage for the group of processes - sure. Limit i/o for the said group - yep. Limit memory or swap - it can do it too. Restrict (not allow) an access to a certain block or char device - you bet. Tag all network packets with a certain tc tag - and that's it. Reco -- 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/20140923160345.GB20670@x101h
