I had tracked down several recordings of that Radiohead concert at the Hammerstein Ballroom a year or two ago. It's a great mix of songs from The Bends and OK Computer.
Due to the nostalgia, it gets frequent replay this time of year, especially while I'm working. It's a big warm hug from my past.
For the full effect, I usually play it in `mpv` with the 'crt-lottes' shader from https://github.com/hhirtz/mpv-retro-shaders, under #MLVWM, with `xsnow`.
Also, with the days getting shorter/colder, tying myself to my desk for longer periods of time for #Twitch #streaming is making me less active. That's not going to be good for my #physical or #mental #health. So, I'm trying to figure out how I can still do some streaming, probably specific to #OpenBSD & #MLVWM implementation tasks (I'd like to squeeze @unna work in there too), but without losing the needed accountability/doubling or tiring myself out too much from being "on". It's a journey! 8/8
@inlovewithpda @ebassi I don't use Gnome and I'm still in #X11 land on #OpenBSD and my #MLVWM window manager, so I'm just "thinking out loud" here...
Do Gnome apps reliably "do the right thing" if sent a SIGTERM, e.g. confirming quit and/or prompting to save unsave changes, as necessary? If so, maybe write a script (triggered on super-q) to get the PID for the frontmost window's process and then `kill -TERM -p $PID` it?
@jmcunx @osnews (Not necessarily clarifying for you, just anyone who may happen upon this discussion.)
CDE is just in ports, not in #OpenBSD base. There is no default #DE, only the #fvwm #X11 #WM. There are plenty of other DEs in ports though, including KDE/Gnome, and some #Wayland support.
That said, as maintainer of #MLVWM, I'm a fan of these earlier WMs & DEs.
I've released a minor update to my #xpomodmenu #X11 collection of utilities (a menu, timer window, and 'bell' daemon) which provides basic #pomodoro functionality. It's wrapped around @seninha's #pomod (you'll want my latest patches for it) and #xmenu tools:
https://github.com/morgant/xpomodmenu/releases/tag/0.3.1
What's changed? Reduced flickering of the timer window.
I maintain this for my own use under #OpenBSD with #MLVWM and doubt it's of interest to anyone else.
@sotolf @rl_dane @rozodru @paul My understanding is that libinput is also heavily tied to udev, which is part of systemd. Not ideal for #Linux distros that don't want to use #systemd, plus other OSes like #OpenBSD have had to put in a ton of effort to try to work around all the deeply-ingrained Linux/systemd-isms.
Folks have asked me to add #Wayland support to #MLVWM, but it'll really just have to be a separate project.
@stilla #MLVWM, the Macintosh-Like Virtual Window Manager — maintainer here! — with my #mlvwmrc configuration files project (small portions use `xdotool`, `gxmessage`, `maim`, and `slop`), `zutty`, `ffssb`, `mpv`, `xload`, `xmem`, `stalonetray`, a few of @seninha's utilities, plus some of my own custom "Menu Extras" & tools (primarily sndio-related):
While I've been trying to work outside as much as possible now that the weather is nice (for my mental health and to utilize my solar generator), today was chilly and started off rainy, so I was able to get a #Twitch stream in. I worked on some #MLVWM & #mlvwmrc scripting to try to knock out some updates to my #OpenBSD APM (Advanced Power Management) Menu Extra:
I had tried this quite some time ago, but _finally_ figured out that #xclock on #OpenBSD _does not_ default to using XRender, despite what the xclock(1) manual states. With the `-render` option enabled (or via X resources), I was able to put together a quick 1995 #AppleWatch analog clock face theme for #MLVWM #mlvwmrc:
https://github.com/morgant/mlvwmrc/blob/master/.mlvwm/Xresources/xclock
This also introduces how I'll handle X resources in mlvwmrc (see the README.)
So, with my new found understanding of monitoring CPU steps & speeds under #OpenBSD, I have now updated my mlvwmrc-openbsd-apmd #MLVWM #mlvwmrc MenuExtras with options for showing the current CPU speed scaling level (the way it used to work) or the current highest CPU/core speed. I've also added an indicator to both modes to designate when the CPU is boosting above the standard CPU speed:
https://github.com/morgant/mlvwmrc-openbsd-apm/releases/tag/0.2
[4/4]
I keep the #X11 #xload & #xmem graphs swallowed into my #MLVWM menu bar, plus have some custom #mlvwmrc configs for apm(8) details, including the current CPU speed. However, the CPU speed I have been using, essentially `sysctl hw.cpuspeed`, is really just the current CPU speed step that #OpenBSD is using.
My old dual-core i7 is 2.2GHz, but has a maximum boost of 3.2GHz, but I had no idea whether or how OpenBSD would actually boost. So, I set to see if I could better observe & identify. [2/n]
My brain & body have been doing a _lot_ of healing this year and I'm extremely thankful to be closing out the year in a manageable state. Both still need stamina building, but I haven't found a good, dead-simple #X11 #pomodoro #timer app for use with #mlvwm. Standing on the shoulders of @seninha , I present to you an #mlvwmrc #MenuExtra for #xpomod:
https://github.com/morgant/xpomodmenu
I spent far too much time on it last night & this morning, but my productivity will benefit from it.
In what little spare time I've had over the last month, I've put together a new `ffssb2mlvwmrc` utility which will generate #mlvwm configurations (styles and a menu) for #FFSSB (#firefox-specific site browsers):
https://github.com/morgant/ffssb2mlvwmrc/
This makes it a lot easier as I use more site-specific browsers due to the 8GB RAM constraints of my 2015 MacBook Air workstation, plus has been a good test-bed for automating configuration generation in #mlvwmrc.
@osnews @thomasadam I also use #xmem on my 2015 13in MacBook Air (i7) workstation running #OpenBSD and #MLVWM (swallowed into the menu bar alongside xload) since it only has 8GB of non-upgradeable RAM. It's got a fast SSD, so swap isn't a total killer. Swapping will cause slight audio/video jitters, so I just make sure xmem doesn't show any blue before I jump on a video call.
The other day, while thinking about some improvements I want and need to make to various #OpenBSD utilities of mine (some for #MLVWM integration), I was wondering if it's possible to programmatically determine if a user had the appropriate doas.conf(5) rules to permit them to execute specific commands with doas(1)? Upon investigating, the answer was a resounding "Yes!" (using `doas -C /etc/doas.conf <cmd>`.
EDIT: NO, DEFINITELY NOT! Permissions were broken on my machine for some reason.
1/N
@mms@emacs.ch I am! I use `mlclock`, `xload`, `xmem` "swallowed" into my #MLVWM menu bar. I also use `stallonetray` to embed "system tray" icons in the menu bar. I _much_ prefer using & writing small, purpose-built #Xorg #X11 applications, integrating, and replacing them as/if necessary as opposed to re-implementing the functionality.
Now I can get back to trying to get a Linux VM running under OpenBSD's vmm/vmd with VNC for testing/troubleshooting #MLVWM.
There was recent discussion of the utility of #clang `scan-build` on the #OpenBSD ports@ mailing list:
https://marc.info/?t=172462394800001&r=1&w=2
I was unfamiliar with it, so decided to give it a run #MLVWM's ancient #C #X11 #Xorg code to see what it revealed. I've spent the past few days knocking the bugs down from 29 to a final 7 which I don't intend to address right now:
https://github.com/morgant/mlvwm/issues/48
Icepic called it with, "I think [it] would find a lot of super easy bugs
if we ran it over generic 1995 C code."
Setting up an #AlpineLinux #VirtualMachine under #OpenBSD using vmm(4)/vmd(8) for #MLVWM testing and pleasantly surprised to find that it installs & uses doas(1) by default! Of course, it seems to automatically configure the new user with #doas permission to run as root because it's in "wheel", which seems a bit too loosey-goosey to me after all this time on OpenBSD.
