You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
alemauri.eu/src/makesoftware.md

66 lines
3.1 KiB

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.