Re: let's talk about SLIM

[ng0]

ng0 transcribed 4.4K bytes:
> Ludovic Courtès transcribed 2.2K bytes:
> > Hi,
> > 
> > Mark H Weaver <address@hidden> skribis:
> > 
> > > ng0 <address@hidden> writes:
> > >
> > >> It seems to me as if SLIM can be dropped once we
> > >> have something else in place. Would you agree?
> 
> I no longer agree with my own proposed action. But the switch of
> the default choice is important.
> 
> > > 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?
> 
> My main concern indeed is the way keyboard layouts are handled in SLIM
> (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26234). As a default
> this is not good.
> However it is easy to switch the default selection of a login tool,
> but the default choice should be one that makes it easy to select one
> or multiple keyboard layouts from a list.
> The default is what most people will use for GuixSD. And if they can
> no longer type in the password the way they've set them up in the
> installer or on tty after boot because the default login manager they
> selected is written this way, they will be quick to disregard as a

Something I forgot to correct from the original sentence I intended
to write:
s/disregard/regard it

> decision Guix made.
> The default choice represents "the Guix preference" (for the time it was 
> made).
> 
> > > 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’.
> -- 
> ng0
> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> GnuPG: https://n0is.noblogs.org/my-keys
> https://www.infotropique.org https://krosos.org



-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

signature.asc
Description: PGP signature