Throughout the countless years of research on this blog a common
thread always comes up: Some features and toggles are often hidden
under mountains of hubris that nobody understands. It could be because
the software is under-or-badly documented, that it’s “too-flexible” and
made to handle cases that never materialize, or just that people don’t
capt what they’re dealing with and never bother looking under the hood.
These software are crying to have better interfaces!
Here are two quotes that embody this classic concept:
The downside of this attitude (which is a close cousin to “mechanism, not policy”) is a tendency to assume that when the highly configurable and expressive interface is done, the job is finished… even if the result is almost impossible for anyone else to use without lengthy study. The flip side of configurability is an urgent need for good defaults and an easy way to set everything to the default. The flip side of expressivity is a need for guidance — be it in the program or the documentation — on where to get started and how to achieve the most commonly-desired results. — Henry Spencer
Finally, a note about user-interface design for nontechnical end-users. This is a demanding art, and Unix programmers don’t have a tradition of being very good at it. But with the ideas we’ve developed from examining the Unix tradition, it is possible to make one strong and useful statement about it. That is: when people say a user interface is intuitive, what they mean is that it (a) is discoverable, (b) is transparent in use, and (c) obeys the Rule of Least Surprise. Of these three rules, Least Surprise is the least binding; initial surprises can be coped with if discoverability and transparency make longer-term use rewarding. — esr in taoup
There are three ways to handle this these days (see also): The mindset of keeping everything vanilla-default all the way, the reproducible-containerized/immutable pristine approach, and the let’s RICE it fun.
I believe that some features and configs are often powerful and expressive and need to be exposed in other ways to reach their full potential. I’ll list a few projects that I think would benefit from this. Obviously, these might have been tackled in one way or another with some obscure partial solutions, but I’ll still throw the hook for anyone to latch on.
FontConfig
Fontconfig has an amazing and extensive configuration
format in which you can match fonts and edit their properties
(see
and fonts-conf(5)). Yet, I’m pretty sure most people aren’t aware that
this is possible and that there’s a set of such confs pre-installed on
their machines to make their fonts legible (/usr/share/fontconfig/).
Today, font-related interfaces are limited to displaying the list of
installed fonts along with a demo of what they look-like in different
sizes, that’s about it.
The project fontweak tried to tackle this and make this more discoverable. However, it’s limited and doesn’t give a global view of what is actually happening.
…Would that be useful to an average user, probably not. Are we average users, probably not.
Audio & Restore List
Audio servers, pulseaudio and pipewire, are smart
enough to remember the last volume used on which devices
and for which audio stream, sinks and sources (see also
this and
this).
However, that information is hidden and almost inaccessible by most
people. The average sound control GUI, such as pavucontrol, only displays
devices and streams and there’s no way to know in advance what volume
will be used when plugging a headset or starting a video. It might
blow your brain from the shock wave, or you might think there’s some
issue since you can’t hear anything.
I tried my hands at this for pulseaudio in the past in the project
pa-resto-edit. Yet, it’s
quite limited and doesn’t work on pipewire.
While at it, this is still my audio
setup,
and it’s still hard to achieve, but getting easier with pipewire
and tools such as qpwgraph and jack-plumbing.
It consists of 3 nodes that are virtual path connected to my headset
by default:
- Multimedia Node
- VoIP Node
- Notification Node
Let’s also remember the dreadful ALSA configurations, which probably nobody understands fully. Like many software, the final configuration it uses is an amalgam of countless smaller ones it finds on the system. I’ve made a script aconfdump to display it, however it doesn’t answer nor gives a clear view of how to edit it and what happens.
…Would those be useful to an average user, I guess the restore stuff would, the rest maybe not. Are we average users, probably not.
Mimetype to Application
Common file managers, such as Thunar and Nautilus, have a limited scope of
what they can do when it comes to associating files to programs, and how
Mimetypes are handled. What they do is mostly list the few xdg-settings
get default-<whatever>. Creating a new Mimetype/file-extension,
registering an application and associating it with a few mimes, or even
trying to find what they are currently handling, is a painful experience
(see).
Fortunately, the mime database has an oldschool editor, MIME
Editor, it’s
very basic but it sort of does the job (if it’s available in
the distro or even runs). As for the application to mime mapping
and a global view, I’m not aware of any existing solution, even
though once upon a time, Nautilus had something called Nautilus
Actions which
could somewhat be counter-used to discover mime handling.
On that note, we also need a novel way to interface with binfmt. In
fact, systemd has binfmt.d which is a layer on top that can also be
used to register new file types and map them to handlers.
…Would this be useful to an average user, I think it would, but it might not be intuitive. Are we average users, probably not.
Journald & systemd Services
Journald has its flaws, but as far as binary logs go it’s fine. What
most people fail to comprehend is that it is a fixed columns/fields
linear storage to search into (see systemd.journal-fields(7)). Hence, what
tends to happen instead is that they randomly type things until they work,
or memorize a single command line trick such as --unit <service> --reverse.
A few software try to make this more apparent, but none makes clear and brings forward the idea of fixed fields to search into. For example kjournaldbrowser from KDE, and qjournalctl. Furthermore, they all struggle to display user/session logs vs global logs.
In the systemd space, unit configuration and unit management is something
that is often clunky but not so bad on the command line. Similarly, tools
such as systemd-manager,
which I’ve patched to support session and system units, are somewhat
filling the gap to make it more approachable.
…Would this be useful to an average user, I think a good journald interface would be nice. Are we average users, probably not, but I don’t think I can remember all the fields of journald.
Nice & Control Groups
So, nice(1) doesn’t work anymore on most Linux OSes
(see), it needs
a revamp. Yet, the issue about rewriting it is that the interaction with
cgroups (v1 and v2) is messy. At this point it’s like some advanced
physics where it makes sense at a localized spot, but it gets too complex
when you consider a global view of what’s happening.
Indeed, the project CGroup
Manager tries to
display cgroups related options in a “top-like” interface. But, it’s
barely standing and working since the project is unmaintained, and it
doesn’t cover most use-cases.
…Would this be useful to an average user, I don’t think they even
heard of cgroups, nor would be able to make sense of them, yet it’s an
integral part of resource allocation and control. Are we average users,
probably not.
Polkit
Policy Kit, aka polkit, is an awesome concept in the desktop landscape:
having standardized actions and services that can be implemented by
anyone, triggered through an indirect bus, and having a centralized policy
enforcer that makes sure the caller is allowed (see).
However, the rules that polkit has are, like many of the software we
mentioned, scattered and gathered around the system. Furthermore, it’s
not as simple to create new actions and rules for the stuff that’s already
present (even though some of it is in JS and lots of people know JS).
There is a project that gave it a try, Polkit
Explorer/polkitex,
but it’s only a rudimentary interface on top of pkaction(1). It’s
tough to search for alternatives as the results will be polluted with
polkit agents instead of explorers and managers.
…Would this be useful to an average user, I guess it could be comforting or confusing, with all the different conflicting security mechanisms on Unix-like systems. Are we average users, probably not.
sudo
Everyone has heard of sudo, it has even entered the every
day language of hackers around the world. Still, I’ve yet to
meet face to face (I did online) someone that could explain
how to configure the sudoers file and what’s possible
with sudo config. Who can explain the output of sudo -ll
(see)
or which plugins are currently installed and what they do?
The sudoers file contains default global settings, aliases (variables),
and matching rules to decide which users can do what and how. It would be
nice to have an easier editor for it than just visudo. I tried finding
some online, but adding sudo to any search query doesn’t seem to make
it more relevant.
…Would this be useful to an average user, I think they’d only use it
to bypass sudo altogether. Are we average users, probably not.
udev rules
I’m not going to bother you too much with udev rules, let’s just say
it’s like most other things mentioned in this article: too many scattered
confs that are joined. The only way to visualize this Turing complete
spaghetti is with systemd-analyze cat-config udev/rules.d. Similar to
fontconfig and sudo, it has matching patterns and actions to perform
upon match, or properties to set (or branching with goto and labels,
see udev(7)).
There’s the perse tool but it’s only used to set permissions on devices.
…Would this be useful to an average user, definitely not. Are we average users, probably not.
iptables & route management
Let’s finish with a dream idea: A better interface, like a GUI similar
to qpwgraph but for creating and managing network routes and firewall
rules. We all know how painful the ip command is on Linux and how
ruthless the jargon of iptables/netfilter is. In practice, this
should somewhat be manageable if we can visualize the packet flow within
netfilter just like we can visualize sinks and sources in the audio
space along with different “filters” along the way.
Nevertheless, we do have GUIs and interfaces to make iptables more approachable, but it’s often to hide things, and they don’t really have a discoverability aspect to them. A few mentions: ShoreWall, MicroFW, Firestarter, firewalld, Gufw, and so many others.
Many software are on the opposite spectrum of the issue I talked about: they’re highly discoverable and have multiple tools to interface with them, but people still find them confusing or refuse to touch them. In that category I’d love to mention many of the freedesktop projects, D-Bus interfaces, XDG-Portals, among others.
That’s it, it’s the end of this pseudo-listicle that doesn’t even have
pictures. It goes to say that, as with any listicle, we can always add one
more entry. Feel free to discuss the topic on the web, you definitely
have your own examples, or found solutions to things I’ve written about.
Either take it as pure nagging, an opportunity to dive into one of these
topics, or as a call to action.
Enjoy your day!
If you’ve read my article and want to comment, please add (v) at the
end of your comment so that I know you’ve actually read it and you’re not a bot.
Cheers!
If you want to have a more in depth discussion I'm always available by email or irc.
We can discuss and argue about what you like and dislike, about new ideas to consider, opinions, etc..
If you don't feel like "having a discussion" or are intimidated by emails
then you can simply say something small in the comment sections below
and/or share it with your friends.