From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: let's talk about SLIM Date: Wed, 30 Aug 2017 09:26:21 +0000 Message-ID: <20170830092621.ixhhingujeefwtzz@abyayala> References: <20170826213253.qxyveyztlhao22bu@abyayala> <87pobgkc39.fsf@netris.org> <87inh577xs.fsf@gnu.org> <20170830091841.rbjz4a4gdobinote@abyayala> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="22wmzipnuoz2c4ch" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dmzGc-0000Tx-Ih for guix-devel@gnu.org; Wed, 30 Aug 2017 05:26:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dmzGb-00027w-64 for guix-devel@gnu.org; Wed, 30 Aug 2017 05:26:34 -0400 Content-Disposition: inline In-Reply-To: <20170830091841.rbjz4a4gdobinote@abyayala> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Mark H Weaver , guix-devel@gnu.org --22wmzipnuoz2c4ch Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ng0 transcribed 4.4K bytes: > Ludovic Court=C3=A8s transcribed 2.2K bytes: > > Hi, > >=20 > > Mark H Weaver skribis: > >=20 > > > ng0 writes: > > > > > >> It seems to me as if SLIM can be dropped once we > > >> have something else in place. Would you agree? >=20 > I no longer agree with my own proposed action. But the switch of > the default choice is important. >=20 > > > 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-1= 7, > > > 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. > >=20 > > I agree we should not remove SLiM. I think the question is more about > > the default we want to have. > >=20 > > For people using %desktop-services with GNOME and all that, it probably > > makes sense to default to GDM. > >=20 > > For the lightweight-desktop example, it may makes sense to stick to a > > lightweight login tool. > >=20 > > 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=E2=80=99t investigated though. > >=20 > > Thoughts? >=20 > My main concern indeed is the way keyboard layouts are handled in SLIM > (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D26234). 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). >=20 > > > Personally, I'd be much happier with a working system that could be > > > audited and not have the audit become stale before its completion. T= he > > > amount of code churn in my systems is so great that it's infeasible f= or > > > me to audit all of the changes coming down the pipe. I find that very > > > uncomfortable. > >=20 > > On one hand I sympathize (I don=E2=80=99t use GNOME/KDE/Xfce and have l= ong tried > > to avoid tools depending on the whole Freedesktop stack in my =E2=80=9C= base=E2=80=9D > > 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=E2=80= =99re even > > further away from that goal anyway, GDM or not. > >=20 > > Thanks, > > Ludo=E2=80=99. > --=20 > ng0 > GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > GnuPG: https://n0is.noblogs.org/my-keys > https://www.infotropique.org https://krosos.org --=20 ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org --22wmzipnuoz2c4ch Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAlmmhL0ACgkQ4i+bv+40 hYioLw/9FDWJMKKjMuuMXy3ypWX24jPqjLv7vjgCWYhD9BFe78s1N9SzGJwEWtvt 65EhRPwreAQbIMHhILMNsGB3tZt/Mri4PgblGH73Q6J8K5p/PsHYcjPIiILjbqJM 56TkxknOtJPSd7CxuaIf3Qhp4V+dXn3IZSELBcPDkHdf8apy01MneRsGUe5nE+IA GOD4yXpvfRUjQJGoTR7k9kvXqo2E5iH6PQ6/B0XYm/nW4s0oupTnnxX/yiAcIWwu JhHg1B63k00w19h+ZkgK9kWPP1QHkQpdXDoKhBWDUQGRxOOGgOzr+Sde6eiaWdhp GTWRRwdNCB1H+YUs0F5CNn79XgWXYgPoJdzx41rG2aMnW8z5QSX4LJvPnTz1FZQv AlKXVjmrKxpdu7NMJZy6/jzwcmJGG8PIVHhuuCwuCFXmJ6WEoVYiz8njg4Ypag7s 9DVi0hvtfRCn8kdOH5JYSfxscq+VAlqo4j4tdgCJL2h/fied069kYKQo6e6XEU2T Lh7lsxPGTWnJckYPU01kLhX54VtPrCayQ3nZPFZoiynZx/3X1zCllKfsI3jY6uii kQz/qwV8e5eZOFCxWEzr9O67416t1NmOB34NCCFT719AA5WrPJDBxdP8hKSTOdWy TA5Bg1UH5MZ2vcGpqPyDMk8G5TjLlOyTJzkwyGKK3Jqlolgwpfo= =GW+z -----END PGP SIGNATURE----- --22wmzipnuoz2c4ch--