let's talk about SLIM

let's talk about SLIM

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

It seems to me as if SLIM can be dropped once we
have something else in place. Would you agree?
The big pro for this is that it is dormant for a
considerable long time now.

If so, I could spare myself the time to fix our
slim-service to make it functional with tcsh.

I think it only work (tested) with zsh and bash,
maybe even fish.
tcsh needs another login_command for SLIM as we
have this in tcsh:

tcsh --help | grep "act as login"
-l              act as a login shell, must be the only option specified

This is not just a tcsh issue. So I have something I am about to try,
but: is it really worth it? In my opinion: No.
Only if we keep Slim around for a long time.

To be clear: I'm not asking for tcsh support, I'm just trying
to make it easier for shells which aren't Bash to give their
users the freedom to use them without too much work on their
own. The login manager is part of a bigger picture.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: let's talk about SLIM

[Mark H Weaver]

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

Re: let's talk about SLIM

[Adam Van Ymeren]

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.

Re: let's talk about SLIM

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Sun, Aug 27, 2017 at 04:08:42PM -0400, Mark H Weaver 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.
> 

It apparently built once on armhf¹. As far as getting it to build on
mips64el, I got my patch for building it on aarch64 from opensuse²

¹ https://hydra.gnu.org/job/gnu/master/mozjs-17.0.0.armhf-linux/all
² https://build.opensuse.org/package/show/openSUSE:Factory/mozjs17

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: let's talk about SLIM

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> 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.

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’.

Re: let's talk about SLIM

[ng0]

[-- Attachment #1: Type: text/plain, Size: 3392 bytes --]

Ludovic Courtès transcribed 2.2K bytes:
> Hi,
> 
> Mark H Weaver <mhw@netris.org> skribis:
> 
> > 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?

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
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: let's talk about SLIM

[ng0]

[-- Attachment #1: Type: text/plain, Size: 3833 bytes --]

ng0 transcribed 4.4K bytes:
> Ludovic Courtès transcribed 2.2K bytes:
> > Hi,
> > 
> > Mark H Weaver <mhw@netris.org> skribis:
> > 
> > > 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?
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: let's talk about SLIM

[Bernd S.]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

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 <mhw@netris.org> skribis:
>
>> 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.
>
> 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’.

[-- Attachment #2: Type: text/html, Size: 3746 bytes --]

Re: let's talk about SLIM

[Adam Van Ymeren]

"Bernd S." <Rs1R8ng1@protonmail.ch> writes:

> I also agree that the replacement should be something really lightweight and independent,
> I really like the suggestion of OpenBSDs xenodm for example.

I did a quick test trying to build xenodm on GuixSD.  I believe the code
has some OpenBSDisms in it, as it doesn't compile out of the box.

I may try to do a real port later, but if anyone else wants to poke
around, this _incomplete_ package definition should get you started.  It
includes all the dependencies I could pick out after skimming
configure.ac


------------------------------------------------------------------------------
(use-modules (guix)
             ((guix licenses) #:prefix license:)
             (gnu packages pkg-config)
             (guix cvs-download)
             (guix build-system gnu)
             (gnu packages xorg))

(package
  (name "xenodm")
  (version "0.1")
  (build-system gnu-build-system)
  (source
   (origin
     ;; This is incomplete, but it would be great if we could fetch the source straight from cvs.
     (method cvs-fetch)
     (uri "anoncvs@anoncvs1.ca.openbsd.org:/cvs")
     (sha256
      (base32
       ;; Obviously this isn't the right hash, but it stops things from complaining
       "0000000000000000000000000000000000000000000000000000"))))
  (inputs
   `(("libxmu" ,libxmu)
     ("libx11" ,libx11)
     ("libxau" ,libxau)
     ("libxinerama" ,libxinerama)
     ("libxft" ,libxft)
     ("libxrender" ,libxrender)
     ("libxpm" ,libxpm)
     ("libxext" ,libxext)
     ("libxt" ,libxt)
     ("libxaw" ,libxaw)
     ("libxdmcp" ,libxdmcp)))
  (native-inputs `(("pkg-config" ,pkg-config)))
  (home-page "http://xenocara.org/")
  (synopsis "Fork of the old xdm program, done by the OpenBSD people.")
  (description
   "xenodm is a lightweight simple display manager for X11")
  ;; I think this needs to be updated.  I believe OpenBSD additions are BSD licensed, not x11
  (license license:x11))
------------------------------------------------------------------------------

Throw this in a file named guix.scm and run

$ guix environment --pure -l guix.scm

and you can try to build it.

Re: let's talk about SLIM

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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.
>
> 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.

I agree that GDM is a better choice for most users, and should be the
default.  I ask only that we retain a lightweight and portable display
manager service as an alternative.

     Thanks,
       Mark