Re: [dev] [dmenu] running shell scripts in dmenu
On Sat, 5 Jan 2019 15:12:41 -0600 Samuel Holland wrote: > For a single-user laptop or workstation, why does there even need to > be a concept of "logging in"? And why do you need 3-4 layers of > shells running in the background to manage your X session? You've got: > - your login shell > - startx > - xinit > - your .xinitrc, if you don't exec your window manager Nice! I really like your setup and I have a laptop in the basement I intend to try this on. The problem is that most of my main laptops are not single-user. My main home laptop I share with my wife, and my work computer I "share" with my official domain login. The idea that I like the most is the udev rule so you don't have to make Xorg +s. It should be doable with just a group, so I could add my wife and I to a group that could run Xorg. Cheers, Sean
Re: [dev] [dmenu] running shell scripts in dmenu
On 01/05/19 13:54, Sean MacLennan wrote: > I almost always run X11... so I want it to startup when I login. > Without a DM, this is how I handle it. For a single-user laptop or workstation, why does there even need to be a concept of "logging in"? And why do you need 3-4 layers of shells running in the background to manage your X session? You've got: - your login shell - startx - xinit - your .xinitrc, if you don't exec your window manager Exactly zero of these are necessary for a proper X session! X is a client-server protocol, not magic. Start a server, start a client, tell it where the server is, and that's it. No shells, no gettys, none of that cruft -- this is suckless, right? This is what I do: 1) I have a udev rule that chowns tty1 to my user, so I can run Xorg without root privileges: SUBSYSTEM=="tty", KERNEL=="tty1", OWNER="me", GROUP="me", MODE="0600" If your Xorg is suid root or cap_sys_admin, you don't need this. But I prefer to not give it privileges it doesn't need. 2) In my user's unprivileged s6[1] supervision tree[2], I have a supervised service that runs Xorg on tty1: Xorg -displayfd 5 vt1 The `-displayfd` argument tells Xorg to write its display number to a file, which is put in an envdir[3] and unsurprisingly named "DISPLAY". The fact that Xorg is independently supervised means it is always running, regardless of which (if any) clients are connected. So if my window manager crashes, I don't lose my session! Another benefit of supervision is that Xorg is always run in the same environment. I could ssh into the box and restart Xorg, and it would be right back on tty1, 100% of the time. 3) Also in my user's s6 supervision tree, I have a service for my window manager. s6-rc[4] handles the dependency on the X server and the DISPLAY environment variable automatically. s6-envdir -fi /run/user/me/env i3 I have similarly simple services for urxvtd, redshift, compton, etc. That way I *always* know at a glance a) if those background processes are running, because s6 will tell me; and b) where the processes are, because it's always the same place -- in the supervision tree. It is simply not possible to have "leftover" processes from a previous session, or to start a service with the wrong environment by starting it from the "wrong" shell. 4) What about passwords? Simple! Have the screen locker start at boot, just like everything else I've mentioned so far. Doing things this way means I get to reuse the same tools for managing my X session as I do for my system services. It also means there's a consistent set of environment variables for all of my processes, and there are no extra shells sitting around. Here's what the process tree looks like (where each of the s6-supervise processes are using a *single 4k page* of RAM, and the s6-svscan's are using about 64k, and absolutely 0 CPU time unless you interact with them): s6-svscan -s [PID 1, running as root] ├─ s6-supervise user-services@me │ └─ s6-svscan -S [running as me] │ ├─ i3bar --bar_id=bar-0 --socket=/run/user/me/i3/socket │ │ └─ i3status │ ├─ s6-supervise xorg │ │ └─ Xorg -displayfd 5 -nolisten local -nolisten tcp -quiet -tst vt1 │ ├─ s6-supervise urxvtd │ │ └─ urxvtd -q │ │ └─ zsh │ ├─ s6-supervise ssh-agent │ │ └─ ssh-agent -a /run/user/me/ssh-agent -Ds │ ├─ s6-supervise s6rc-oneshot-runner │ │ └─ s6-ipcserverd -1 ... [runs oneshots like setting the wallpaper] │ ├─ s6-supervise s6rc-fdholder │ ├─ s6-supervise redshift │ │ └─ redshift -r │ ├─ s6-supervise mpd │ │ └─ mpd --no-daemon --stderr │ ├─ s6-supervise i3 │ │ └─ i3 │ └─ s6-supervise compton │ ... [system services] TL;DR: "startx vs a DM" is a false dichotomy. "Logging in" to a PC is meaningless. Supervision is the *correct* answer to managing a set of long-running processes. Cheers, Samuel [1]: https://skarnet.org/software/s6 (like runit, but much better) [2]: https://github.com/smaeul/rc-user [3]: https://skarnet.org/software/s6/s6-envdir.html [4]: https://skarnet.org/software/s6-rc
Re: [dev] [dmenu] running shell scripts in dmenu
On Sat, 5 Jan 2019 17:09:32 -0200 Caio Barros wrote: > Although I too have a somewhat nostalgic > feeling when typing a command to load the window manager, I don't mind > at all automating it, but for that a DM is not necessary. I almost always run X11... so I want it to startup when I login. Without a DM, this is how I handle it. In your .zlogin or .bash_login or add the following lines: if [ `tty` = /dev/tty1 ]; then startx; clear; logout fi When I login, X11 is started. When I exit X11 (I use Ctrl-Alt-Backspace), I am logged out. Just like a "real" DM. However, if I don't want to start X11 for some reason, just hit Alt-F2 and login. Since you are not on tty1, you will just go to the console. Cheers, Sean
Re: [dev] [dmenu] running shell scripts in dmenu
Hi [2019-01-05 17:09] Caio Barros > > Em sex, 4 de jan de 2019 às 19:42, Markus Wichmann > escreveu: > > > > On Fri, Jan 04, 2019 at 02:17:12PM -0200, Caio Barros wrote: > > > That's it! Yes, I'm unfotunately still runing a display manager: > > > lightdm. I'm slowly getting rid of the bloat [...] > > > > It was never my intention to advise you of how bloated or unbloated your > > system can be. To be honest, I don't know if having a redundant shell > > session hang around is more bloated than an additional program in the > > background. I refuse to run a DM because I have had bad experiences with > > those in the past (namely, that the default X11 configuration would > > crash the machine, but on Debian there was no easy way of preventing the > > system from starting it with a DM installed). But you do you. Whatever > > makes you happy. > > > > Honestly, starting from console and typing in "startx" brings back > > memories of starting up my 486 and typing in "win". Makes the experience > > feel a bit unevolved. > > > Oh, I din't tried to remove the DM because of your advice. That was > something I tried before asking for help and because I wanted it. > > Personally, I feel that without a DM I understand my system better In > that sense a DM is bloat to me and not so much because of memory usage > or redundancy of sessions. Although I too have a somewhat nostalgic > feeling when typing a command to load the window manager, I don't mind > at all automating it, but for that a DM is not necessary. If you are interested in something very light that saves you some typing while still lets you choose sessions (if you happen to have more than one), TDM[0] has been working quite well for me. Cheers, Silvan [0] https://github.com/dopsi/console-tdm
Re: [dev] [dmenu] running shell scripts in dmenu
Em sex, 4 de jan de 2019 às 19:42, Markus Wichmann escreveu: > > On Fri, Jan 04, 2019 at 02:17:12PM -0200, Caio Barros wrote: > > That's it! Yes, I'm unfotunately still runing a display manager: > > lightdm. I'm slowly getting rid of the bloat [...] > > It was never my intention to advise you of how bloated or unbloated your > system can be. To be honest, I don't know if having a redundant shell > session hang around is more bloated than an additional program in the > background. I refuse to run a DM because I have had bad experiences with > those in the past (namely, that the default X11 configuration would > crash the machine, but on Debian there was no easy way of preventing the > system from starting it with a DM installed). But you do you. Whatever > makes you happy. > > Honestly, starting from console and typing in "startx" brings back > memories of starting up my 486 and typing in "win". Makes the experience > feel a bit unevolved. Oh, I din't tried to remove the DM because of your advice. That was something I tried before asking for help and because I wanted it. Personally, I feel that without a DM I understand my system better In that sense a DM is bloat to me and not so much because of memory usage or redundancy of sessions. Although I too have a somewhat nostalgic feeling when typing a command to load the window manager, I don't mind at all automating it, but for that a DM is not necessary.
Re: [dev] suckless html to markdown (text)
I'm afraid pandoc won't be considered suckless by most of the list, but I would double Nick's recommendation: pandoc is the only tool that eventually worked reliably for my tasks. Escpecially in corporative environment, I appreciate that I can convert accross formats,even to docx and import to / export from google docs. Actually, I prepare also my talks with a chain of [markdown and tex mix] --pandoc--> pdf unless they are reasonably simple to fit in `sent`. --s
