I agree as well that SLiM should be replaced as the default display manager, for one because of the problems mentioned, and also because it is no longer maintained.
I also agree that the replacement should be something really lightweight and independent, I really like the suggestion of OpenBSDs xenodm for example. I do not think that gdm would be a good base default option, it should rather be used as the default for using %desktop-services with Gnome, as already suggested. > Hi, > > Mark H Weaver <[email protected]> skribis: > >> ng0 <[email protected]> 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. > > I agree we should not remove SLiM. I think the question is more about > the default we want to have. > > For people using %desktop-services with GNOME and all that, it probably > makes sense to default to GDM. > > For the lightweight-desktop example, it may makes sense to stick to a > lightweight login tool. > > One grief I have against SLiM is that it lacks i18n support. If lightdm > fixes that, I would recommend it instead of SLiM in the > lightweight-desktop example. I haven’t investigated though. > > Thoughts? > >> 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. > > On one hand I sympathize (I don’t use GNOME/KDE/Xfce and have long tried > to avoid tools depending on the whole Freedesktop stack in my “base” > system), but on the other hand, I think we have to realize that (1) no > single individual can audit more than a tiny fraction of their system, > and (2) when it comes to running a full desktop environment, we’re even > further away from that goal anyway, GDM or not. > > Thanks, > Ludo’.
