added article
cool programs someone should make
This commit is contained in:
parent
1f9c3c9bb2
commit
3de7050a9c
@ -5,3 +5,5 @@
|
|||||||
## Articles
|
## Articles
|
||||||
|
|
||||||
[Size in loc of common software](commonsizes.html)
|
[Size in loc of common software](commonsizes.html)
|
||||||
|
|
||||||
|
[Programs I would like to see made/remade](makesoftware.html)
|
||||||
|
49
src/makesoftware.md
Normal file
49
src/makesoftware.md
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
# 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 controvercial one, here are my reasons I
|
||||||
|
would like to see a new init system on the table:
|
||||||
|
|
||||||
|
1. Other options suck
|
||||||
|
- systemd is botne 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.
|
Loading…
Reference in New Issue
Block a user