Knowing the alternative tuigreet (https://github.com/apognu/tuigreet), there won't be much of a difference between a video and the given screenshot. You have a prompt, you enter username and password and your Wayland compositor/X session starts up.
The last release of Ly was on 3 Feb 2020. More than two years ago. I would rather use your solution (which is also written in Rust).
The thing display/login managers have going for them is they allow certain configuration before logging in, or they show certain information before logging in. Whatever you want to configure or display depends (mostly on preference). Thinking about it, I am not sure I need anything. I mean, all I do is type sway.
How does this work? I'd think that auto-login is a convenience that reduces security, and disk encryption would only be meaningful with some factor of authentication?
You need to enter the key to decrypt the disk during the boot process, so having another password just to login is slightly unnecessary unless you have multiple users on the device
1- Tangential, Why "login manager" is called display manager in Linux-speak?
2- Isn't it better to use a login manager that is 1- graphical and 2- uses the same GUI tech as your DE (for example gtk for xfce/gnome and qt for KDE) so the actual GUI apps could be hot-loaded in memory and the initial cold-runs of programs could be faster?
I'm interested in trying this out with i3. I've only just started using i3 and the default lightdm display manager (on NixOS) looks and feels out-of-place with it. Ly seems to be a logical next step.
1: You can login and not start up a display (e.g. when you SSH into a box). The login manager is seperate from the display manager. You don't necessarily have to have a display attached.
2: The display manager starts up a window manager, which figures out where to draw your apps. X11 or Wayland is the underlying tech that KDE, Gnome, etc, uses to manage displays/windows.
Ly draws straight to the terminal, which I'm pretty sure is faster. And it allows some flexibility when running multiple window managers. I've found having multiple window managers installed can be a little unstable. SDDM didn't like it, but it works pretty good with Ly.
> 2- Isn't it better to use a login manager that is 1- graphical and 2- uses the same GUI tech as your DE
A text only login manager could spare some more resources on small systems, since once the desktop environment has been loaded it keeps running anyway.
I use LightDM and XFCE for example, and if I look at LightDM memory consumption, the amount although not huge is neither trivial; I guess small embedded devices would benefit from this.
I made a quick survey of text-based display managers a couple days ago. Ly looks fantastic, but I went with tbsm, which had almost no dependencies and was super simple to get going.
25 comments
[ 5.6 ms ] story [ 82.5 ms ] threadThe thing display/login managers have going for them is they allow certain configuration before logging in, or they show certain information before logging in. Whatever you want to configure or display depends (mostly on preference). Thinking about it, I am not sure I need anything. I mean, all I do is type sway.
https://youtu.be/JwudRbgLTNQ?start=438
I'm not using one for a long time, thanks to disk encryption and auto-login.
How does this work? I'd think that auto-login is a convenience that reduces security, and disk encryption would only be meaningful with some factor of authentication?
2- Isn't it better to use a login manager that is 1- graphical and 2- uses the same GUI tech as your DE (for example gtk for xfce/gnome and qt for KDE) so the actual GUI apps could be hot-loaded in memory and the initial cold-runs of programs could be faster?
Thanks for the project. Seems clean.
If yes to both, you could have your bashrc (or you shell's equivalent) start X and i3 on a TTY login?
https://wiki.archlinux.org/title/Xinit#Autostart_X_at_login
regardless if textmode or framebuffer,
and simply do upward arrow & enter,
since whatever starts your session is the last entry in shell history anyways :-)
This way there is less surprise/annoyance with flickering/crashing X,
like you could have when starting X unconditionally after login,
which could happen after you modified something to test.
On another console, to not spoil the history for that upward arrow & enter thing ;-)
Which works regardless of shell/WM/DE/OS/whatever, at least it does so for me.
You're assuming everyone using Linux uses a DE.
2: The display manager starts up a window manager, which figures out where to draw your apps. X11 or Wayland is the underlying tech that KDE, Gnome, etc, uses to manage displays/windows.
Ly draws straight to the terminal, which I'm pretty sure is faster. And it allows some flexibility when running multiple window managers. I've found having multiple window managers installed can be a little unstable. SDDM didn't like it, but it works pretty good with Ly.
A text only login manager could spare some more resources on small systems, since once the desktop environment has been loaded it keeps running anyway. I use LightDM and XFCE for example, and if I look at LightDM memory consumption, the amount although not huge is neither trivial; I guess small embedded devices would benefit from this.
https://github.com/loh-tar/tbsm
http://loh-tar.github.io/tbsm/
http://uggly.bytester.net