Re: let's talk about SLIM

[Adam Van Ymeren <adam@vany.ca>]

On August 27, 2017 2:08:42 PM CST, Mark H Weaver <mhw@netris.org> wrote:
>ng0 <ng0@infotropique.org> 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

OpenBSD started a fork of xdm named xenodm which might be interesting to look at and port to GNU.