Re: Effectively criticizing decisions you disagree with in Debian
On Mon, Sep 22, 2014 at 11:46 AM, Reco <recoverym4n@gmail.com> wrote:
> Hi.
>
> On Mon, 22 Sep 2014 09:12:38 +0900
> Joel Rees <joel.rees@gmail.com> wrote:
>
>> I will acknowledge that there are some things that we could do to
>> improve the current (sysv) init in debian.
>>
>> * 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.
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.
Likewise, run-levels don't really work well for me as a way to adjust
which services/daemons are running.
>> 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?
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.
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.
(And, I am aware that I still haven't put together a general set of
scripts for allowing ordinary users to add a limited number of
arbitrary groups and invite specified users to join, to allow
non-admin users to use the permissions model to set up meaningful
limited-access directories within their own public folders.)
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: