💾 Archived View for anachronauts.club › ~voidstar › pinned › keyblade.gmi captured on 2023-04-19 at 22:47:23. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-07-16)

-=-=-=-=-=-=-

keyblade: my suckless, pure-wayland arch laptop

unfortunately, i can't do _all_ of my day-to-day computing on 6502 machines from the eighties, so i also maintain a dell xps 13 9360 named "keyblade".

disclaimer: this post is probably really boring. go read my other stuff instead.

at first i planned to run freebsd on keyblade, but the lackluster wifi / laptop support, as well as the molasses boot times (even with 13.1) turned me off (although i am now eyeing my desktop pc as a possible freebsd host).

now i'm running arch, with a custom wayland desktop environment i'm cobbling together from various open source components. i'm diving deep into suckless territory, which means: minimal features, minimal code, minimal dependencies, minimal surprises, no hand-holding, no runtime configuration (if you wanna customize it, you gotta modify the code).

so far i'm running pure wayland, without even using the x-wayland server. the only GUI software i've needed so far (outside of my terminal emulator and the aforementioned custom desktop environment) is firefox. i've been doing everything else in the terminal.

installation

i installed by building a chroot manually.

i configured five partitions: EFI (1G), SWAP (16G), ROOT (50G EXT4), SRC (50GB EXT4), HOME (384GB EXT4). the SRC partition is mounted to `/usr/local/src`; it's just a place for me to keep code long-term. i'll use it for custom packages. i want to keep HOME and SRC separate from ROOT, so that i can re-build ROOT if i need to without losing the other two.

i'm not crazy about the partition scheme, i may re-do it. physical partitions are inflexible, a swapfile would be more slick than a partition, and i might want to look at btrfs or zfs.

i use `mkinicpio` to build a unified kernel image, and `efibootmgr` to add that as an efistub boot entry directly in my firmware -- no bootloader at all. i made the boot as quiet as possible, and disabled any splash screens. i am not using `plymouth`.

typography and colorways

my statusbar, launcher, and terminal all use operator mono (patched with nerd font icons), because i _adore_ the italic fixed-width cursive ligatures. and because, frankly, i need to get my money's worth.

i use the base16-eighties colorway in my shell and text editor, via chriskempson/base16-shell and chriskempson/base16-vim. for gtk3 apps, i'm using the dark variant of the default adwaita theme.

package management: morganamilo/paru

i am using an aur management overlay called `paru`. for the most part, you use it just like `pacman`, and it builds packages from the aur if `pacman` can't find anything.

there are a few packages i've either written myself or heavily customized from the aur. i keep these in `/usr/local/src`. for now, i'm just installing them with `makepkg -fic`, but it would be nice if i could integrate with `paru` so that it re-builds my custom packages (if needed) during system updates. i'm not sure if this is possible.

edit: i've learned that paru downloads packes from the aur into `.cache/paru`, and that it is common to download a package before installing it via `-G`, make edits to the package, and then install via `-S`. so i should remove the stuff i've installed manually and move my custom packages over there.

i try to be conservative with installing packages, and i frequently check the list of explicitly installed packages, pruning things i no longer need.

login manager: fairyglade/ly

`ly` is a text-mode login manager, which is great because it doesn't weigh down the boot process and (unlike `getty`) provides a convenient ui for choosing which session you'd like to boot into. this allows me to easily choose either a bare tty console or my full desktop environment when logging in.

also, it has a great minimalist look.

compositor: djpohly/dwl

`dwm` (the "dynamic window manager") is a suckless tiling window manager. it keeps windows arranged in tiled layouts, so that they're always visible. it supports multiple workspaces for when you don't want all your windows in a single view. windows can be shuffled around and tagged to arbitrary workspaces, layout panes can grow or shrink, and it has modes for free-floating windows and full-screen view. and it is entirely controlled by keybindings. dwm is less than 2k lines of C in a single file.

`dwl` is "dwm for wayland". in otherwords, a wl-roots based compositor that provides all the layers i need, with a codebase that fully satisfies the suckless philosophy and an identical `config.h` file. my favorite feature is workspace tagging, which allows a single window to exist in multiple workspaces. i've also applied `vanitygaps.patch`.

dwl is _just_ a window manager, though. it doesn't come with any dock, launcher, start menu, taskbar, or anything like that. never fear, though. there's plenty of other great software to fill those roles.

status bar: raphi/somebar, raphi/someblocks

`somebar` is a "dwm-like bar for wayland". it sits at the top of my screen and shows which workspace and layout i have active, and the title of the current window. on the right edge of the bar is an empty area; any application can change what is displayed here by writing to a named pipe at `${XDG_RUNTIME_DIR}/somebar-0`.

`someblocks` is a script scheduler; it's sort of a miniature version of `cron`. you configure some number of "blocks" (which are really just shell scripts that output to stdout) and each block updates at defined intervals. one can also force an update for a block on-demand by sending a real-time signal to `someblocks`.

these two work together: whenever a block is updated, someblocks update's somebar's status area. this setup is equivalent to using `dwmblocks` with dwm on X11. it essentially gives me a "tray" area to display a clock, volume, battery, and wifi status.

something i'm working on but haven't quite finished is a somebar-equivalent of `statuscmd.patch`, which would allow me to actually click on specific blocks and have that trigger scripts.

launcher: scoopta/wofi

`wofi` is a wayland clone of `rofi`, which is itself a (significant) superset of the suckless `dmenu`.

dmenu is a simple, powerful concept: read lines of text from stdin, then display (in the middle of the screen) an interface for selecting one of the input lines -- then print the selected line to stdout. this means scripts can use this as a gui for multiple-choice options. i basically only use the dmenu mode of wofi.

wofi is not suckless-style software, and contains a lot of features i don't want. ideally, i'd like to be using _just_ dmenu-for-wayland. but so far there the only clone i've found only supports horizontal layout.

aside from using wofi in a few scripts (like as a gui for connecting to wifi networks), i also have a keybinding in dwl to use wofi as a launcher. so it's like my start menu.

overbar: francma/wob

`wob` is a wayland clone of the suckless `xob`, the "X11 overlay bar".

i absolutely love how absurdly simple yet versatile this program is: read a number from 0 to 100 from stdin, then display (in the middle of the screen) a simple rectangle, with the center filled in to the specified percentage. it disappears after a moment.

this pairs beautifully with systemd socket activation. systemd can create a named pipe, and automatically launch wob whenever any input is received on the pipe.

i've integrated this with the scripts that run whenever i change the volume or brightness to give me on-screen real-time display of the new levels.

terminal: dnkl/foot

`foot` is a fast, low-dependencies wayland-native terminal emulator. it supports true color, freetype fonts, unicode, and sixels. it has a server mode. it's basically exactly what i need and nothing more.

the one downside is that it uses its own terminfo definition file, which means if i connect to a server that doesn't have foot installed, i get an uncooked shell. there's a compile flag i can set if i build from source, though, which will cause it to use xterm-256 instead.

text editor: neovim/neovim

i've been a long-time casual vi/vim user for lightweight editing. i know many of the navigation commands, and i'm pretty comfortable with mode-switching. now it's time to get more serious, because i want to do my coding and writing in the terminal.

i'm using neovim, with vim-plug. the only plug i've installed is base16-vim, and tied it in with my base16-shell installation.

to be honest, as i learn the key bindings more deliberately, i'm finding that the binding scheme seems inconsistent; especially the use of shift as a modifier. sometimes shift seems to do the same action in the opposite direction, but sometimes it does the opposite action on the same target. and sometimes the actions' keybindings are pneumonics related to their direction (like f for forwards) which causes their shift-modified behavior to make no sense with the pneumonic.

i'm eyeing emacs. it comes on high recommendation from ~sage.

conclusion

as far as linuxes go, i'm liking arch. the aur and the arch wiki are both phenomal resources. i've enjoyed building this system manually, bit by bit, learning new things each step of the way.

i must admit, i like package management much better on freebsd. adding additional ports trees, or adding your own modifications, feels much more elegant with something like `synth` on freebsd compared to the way `paru` does things on arch. also, browsing ports locally feels like walking through a toy store.

i'd sort of like to package up my custom arch like a downstream distribution, with an installer image and curated `/etc/skel` and everything so that i can deploy this as a base setup to a few devices in my house.

comments