Re: let's talk about SLIM

[Mark H Weaver]

ng0 <address@hidden> writes:

> It seems to me as if SLIM can be dropped once we
> have something else in place. Would you agree?

It would be good to keep a display manager service that is lightweight
in terms of both resource usage, runtime-dependency closure, and
build-dependency closure.  I'm not attached to SLiM, but I would not
consider the existence of a GDM service to be sufficient grounds for
removal of SLiM.

Apart from the needs of those on older hardware, or those who wish to
build everything locally from source code, I'm not sure if we've ever
successfully built GDM on a non-Intel system.  GDM depends on mozjs-17,
which I've never managed to build on mips64el-linux, and it fails on
armhf-linux too.  Fixing mozjs on mips64el-linux is probably not
trivial, and yet I'm happily using SLiM on my Yeeloong, which is still
the only non-Intel GuixSD system as far as I know.

> The big pro for this is that it is dormant for a
> considerable long time now.

It's a mistake to assume that software that doesn't see frequent
releases is problematic.  If a program or library does its job well and
doesn't have a pile of unfixed bugs, there may not be a need for more
releases.  qmail's last release was in 1998, and yet I would trust in
its security and correctness more than just about anything else.  TeX's
last release was in January 2014, and it obviously works extremely well.

Personally, I'd be much happier with a working system that could be
audited and not have the audit become stale before its completion.  The
amount of code churn in my systems is so great that it's infeasible for
me to audit all of the changes coming down the pipe.  I find that very
uncomfortable.

       Mark