|
|
|
Title: Programs someone should make
|
|
|
|
Author: Alessandro Mauri
|
|
|
|
|
|
|
|
# Programs that I'd like to see made/remade
|
|
|
|
Most small utilities have already been made, and most big programs are perhaps
|
|
|
|
too big even for a small team, moreover old software has a lot of historical
|
|
|
|
bloat, so here's a list of programs that I would like to see made/remade and
|
|
|
|
perhaps that I will make.
|
|
|
|
|
|
|
|
## A proper init system
|
|
|
|
Yes I know, starting strong with a controversial one, here are my reasons I
|
|
|
|
would like to see a new init system on the table:
|
|
|
|
|
|
|
|
1. Other options suck
|
|
|
|
- systemd is botnet bloat bigger than 90% of every other linux
|
|
|
|
project out there
|
|
|
|
- runit is fine but it lacks support for oneshots, easy user services
|
|
|
|
and targets/dependencies
|
|
|
|
- openrc slow development for a slow init with an unintuitive service
|
|
|
|
model (similar to a shell script but worse)
|
|
|
|
- s6 written in "skarnet C" is a massive and unintuitive mess that I
|
|
|
|
don't have the time to study
|
|
|
|
|
|
|
|
2. All other options do somethings right and others not so much so a new init
|
|
|
|
that takes inspirations from both the critiques and praise of previous projects
|
|
|
|
could really shape the path for a better init system
|
|
|
|
|
|
|
|
3. It's fun to make systemd enthusiasts seethe
|
|
|
|
|
|
|
|
## A simple sound server
|
|
|
|
Okay this is an idea of mine but hear me out: linux already has a great sound
|
|
|
|
interface used (directly or indirectly) by all programs that need sound ALSA.
|
|
|
|
Compatibility layers from pulseaudio to alsa already exist and most software
|
|
|
|
has direct support for it.
|
|
|
|
Most of the work that pulseaudio (as other sound servers) does is route audio
|
|
|
|
from one place to another but this can also be done within ALSA with some clever
|
|
|
|
configuration, the problem being the application needs to restart to honor the
|
|
|
|
changes.
|
|
|
|
|
|
|
|
So a simpler sound server based on ALSA would just be composed of a PCM and
|
|
|
|
a daemon (possibly not) that takes the sound being sent to it and routes it to
|
|
|
|
other PCMs or cards with the ability to change the routing live. This system
|
|
|
|
would allow for everything pulseaudio does, for example:
|
|
|
|
|
|
|
|
- resampling would work creating a PCM using dmix
|
|
|
|
- audio mixing would work creating a PCM using a software mixer plugin
|
|
|
|
- etc.
|
|
|
|
|
|
|
|
The benefit is that such system would have a negligible impact on the CPU as
|
|
|
|
the complexity of the routing determines the work that the server would do,
|
|
|
|
as a normal user would just use the server to switch sound cards on the fly
|
|
|
|
the performance impact is near zero.
|
|
|
|
|
|
|
|
## An alternative to fprintd
|
|
|
|
Libfprint is good enough, it currently is the only open source way to access
|
|
|
|
fingerprint sensors, but the only two programs that I know use it are
|
|
|
|
fprintd (from the same devs) and fingerprint-gui, both are not good.
|
|
|
|
Fprintd could have been great as it is simple and implements a PAM module, but
|
|
|
|
it requires polkit for some unknown reason, as for fingerprint-gui try to get
|
|
|
|
it working.
|
|
|
|
|
|
|
|
How should the alternative work? Kinda like fprintd but with just 2 components:
|
|
|
|
- A fingerprint database manager to add, remove, modify and verify fingerprints
|
|
|
|
- A PAM module for authentication
|
|
|
|
Everything else can be done with a combination of those two components and shame
|
|
|
|
shell glue, you don't really need anything else.
|