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