Another Init System: Sinit - The Suckless Init System

[pal666]

The idea is probably to make a pure suckless.org OS, which would mean using sbase and ubase rather than coreutils.

For compilers, I think GNU binutils + gcc will stay for a while, but there was some interesting mention of the "ucc" compiler on the suckless.org mailing list some time ago.

obviously they don't need any compilers, they will just use hex editors

[soupbowl]

I am a fan of suckless tools, I am interested in what they do with this init.

[Nelson]

I'll fix that for you: init=/bin/sh There you go!

Personally I need an init system that will:

• Reliably boot the computer to a desktop fast and without starting up everything but the kitchen sink.
• Reliably start the services I need and their dependencies.
• Suspend/resume/shutdown fast and reliably (without hanging services/network/NFS/...).
• Doesn't start seven instances of a service before it is needed (if ever!).
• Restart services reliably when they hang or when changing configuration.

I can personally attest that neither SysV init nor Upstart will fulfill these simple requirements. From a distance it looks like SystemD actually might - and even simplify a lot of the Unix legacy cruft in the process.

Even though Lennart Poettering might not be the most diplomatic person (neither are a lot of people on these forums!), he actually seems to have the will and talent to bring Linux into the present. Compared to simple raw Alsa, PulseAudio actually works for me and provides some of the needs of a modern desktop (multiple inputs/outputs, mixing, Bluetooth headsets, ...).

Why is it so many people are so keen to talk trash about something they can just choose not to use - and before they likely even know what they are talking about?

Upstart gets close... SystemD does pretty much have the ability to do all that and then there is the added benefit of having very nearly the same "startup file" for every distribution that uses it. And it supports cgroups.

Are there any good examples of some issues caused by these tools that are "too complex" or just a general fear of complexity. I've used both upstart and systemd a fair amount and I can't point to anything being broken. If upstart properly managed depends, it's remarkably good and fairly simple, it's just not 35+ years old.

[intellivision]

I'll fix that for you: init=/bin/sh There you go!

Personally I need an init system that will:

• Reliably boot the computer to a desktop fast and without starting up everything but the kitchen sink.
• Reliably start the services I need and their dependencies.
• Suspend/resume/shutdown fast and reliably (without hanging services/network/NFS/...).
• Doesn't start seven instances of a service before it is needed (if ever!).
• Restart services reliably when they hang or when changing configuration.

I can personally attest that neither SysV init nor Upstart will fulfill these simple requirements. From a distance it looks like SystemD actually might - and even simplify a lot of the Unix legacy cruft in the process.

Even though Lennart Poettering might not be the most diplomatic person (neither are a lot of people on these forums!), he actually seems to have the will and talent to bring Linux into the present. Compared to simple raw Alsa, PulseAudio actually works for me and provides some of the needs of a modern desktop (multiple inputs/outputs, mixing, Bluetooth headsets, ...).

Why is it so many people are so keen to talk trash about something they can just choose not to use - and before they likely even know what they are talking about?

OpenRC fulfils the criteria of all of the points you have addressed, with the bonus that it can boot Linux, Hurd and FreeBSD derived OS's and still supports Linux only features such as CGroups.
I'd also like to point out that people are still encountering latency issues with Pulseaudio, especially with gaming and audio production work.
A more sane choice would be to use ALSA + JACK or simply use OSSv4 instead.

[Annabel]

Am I late guys?

https://www.gnu.org/software/dmd/

[mrugiero]

OpenRC fulfils the criteria of all of the points you have addressed, with the bonus that it can boot Linux, Hurd and FreeBSD derived OS's and still supports Linux only features such as CGroups.
I'd also like to point out that people are still encountering latency issues with Pulseaudio, especially with gaming and audio production work.
A more sane choice would be to use ALSA + JACK or simply use OSSv4 instead.

PulseAudio was never meant to be low latency, and low latency is not that important for consumer audio, which is what PA aims for. For professionals, there's JACK. Actually, I think you already explained this very same subject in another thread, so it surprises me you mention that when you know already those issues are there by design and not by accident.

Am I late guys?
https://www.gnu.org/software/dmd/

Yes, you are. It was mentioned in the first or second post of this thread.

[dee.]

Actually, I think you already explained this very same subject in another thread, so it surprises me you mention that when you know already those issues are there by design and not by accident.

That was probably me.

And I have to clarify. Even though PA is designed for "consumer use", it still has some problems even in the use cases it's designed for. I've encountered problems caused by PA that had nothing to do with latency or audio work - even in tasks as "simple" as playing back Flash video or even local mp4/avi/etc videos on VLC. If it's truly meant for "consumer use", then it needs to fix the issues of usability - regular consumer users are not going to want to dive into cryptic config files or do esoteric math with buffers and sample rates just to acquire glitch-free audio playback. And I speak from experience because all this was necessary for me just to get PA working somewhat decently, without constant glitches.

And there's still one issue that I simply can't fix - to be fair though, I'm not entirely sure whether this is caused by ALSA or PA. The audio output port randomly switches between headphones/analog output, and every time I change volume I have to make sure I change both volumes because otherwise I get irritating volume jumps in the audio stream. I've looked into this but there doesn't seem to be any fix available for it.

[mrugiero]

And I have to clarify. Even though PA is designed for "consumer use", it still has some problems even in the use cases it's designed for. I've encountered problems caused by PA that had nothing to do with latency or audio work

Oh, yeah, I'm aware it has other problems. I was just pointing out that latency was intentionally left out because other issues were the priority. I had my share of problems with PA, specifically a pet project of mine never had its audio working on Linux, allegedly because of PA (it worked alright in Windows, and as it used OpenAL, both builds had the same code path). At least, that's what I could gather from bug reports for other applications.

If it's truly meant for "consumer use", then it needs to fix the issues of usability - regular consumer users are not going to want to dive into cryptic config files or do esoteric math with buffers and sample rates just to acquire glitch-free audio playback. And I speak from experience because all this was necessary for me just to get PA working somewhat decently, without constant glitches.

Fully agree.

And there's still one issue that I simply can't fix - to be fair though, I'm not entirely sure whether this is caused by ALSA or PA. The audio output port randomly switches between headphones/analog output, and every time I change volume I have to make sure I change both volumes because otherwise I get irritating volume jumps in the audio stream. I've looked into this but there doesn't seem to be any fix available for it.

That one is weird.

Besides it's problems, nobody said it was perfect. The one to brought the subject up said it provided *some* of the modern desktop needs, and I only said it's focus is in consumers, so the latency problems will not be fixed, and one should not expect that to happen, just that. The other problems should eventually get fixed.

[gens]

Why is it so many people are so keen to talk trash about something they can just choose not to use - and before they likely even know what they are talking about?

indeed
i suppose you use the suckless init system
that was designed from the ground up to be simple and to standards

i guess you also agree with the suckless philosophy, that software should suck less (be less bloated, in general)
if you do, welcome