Re: Effectively criticizing decisions you disagree with in Debian
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
Reply to: