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

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.