... we're still alive!

[Black Sliver]

for me the beauty of gnu/linux is about modularity, do one thing at a time and do it right.

That's why it is/should be called systemd/linux -- maybe sometime it will be systemd/uboot with boot-to-systemd ... wait ... why stop there? why not integrate a bootloader into systemd?

Debian people had long conversations on systemd, so did Arch

Afaik (one of the) main reason(s) for this is to unify init "scripts", so a vendor can ship them (instead of the maintainer). The fact that systemd does more than that is the main reason why people hate it.
I have my doubts that systemd is the right choice for OSes targeting more than just desktop:
a) dbus - makes sense on a desktop pc, but not on server or embedded,
b) "permission management" (logind, etc.) makes only sense on desktop, imho. Linux' permission system (groups) works nicely for other use-cases.
c) reduced freedom/increased bloat (you can't just use/take/mix the parts you need/want),
d) not suitable for *all* devices (e.g. IoT, WRT, ...),
e) last but not least: despite the fact that performance should be better (multi-core C vs. single-core bash), it wasn't for a single device for me.
*BUT* since Pyra should be a ready-to-use end-user desktop-like device, systemd may/does make sense for pyra's default OS.

I found Pulse audio to be easier to work with once I came to the realization that it works more or less like a professional sound mixing board that has had half of it's capabilities removed.

It's just not good/ready/bug-free enough. I used it since "day one" when Ubuntu forced it on us. It was really bad back then - but often still better than plain alsa or oss.
Anyway, after that I still had my share of problems with it. Being on Arch (rolling, latest pulse), I can say that it's still full of bugs, at least when mixing sound cards or using network streaming. The main difference to professional sound is the magical buffering system. It will increase buffer size on the go, which introduces delays, which leads to Problem 1: mixing different sound cards may (or will?) increase the buffer to unlimitted sizes (e.g. +1 second delay per minute). I fixed this by using PortAudio against ALSA and just "replaying" a sink to a source and Problem 2: when streaming over network, the delay will randomly increase (bad connection?) but the logic to decrease the buffer size seems to be missing. I found no settings whatsoever to fix this. You have to go through ALSA, manage the buffering youself and hope that PA does not insert a magic buffer (TM) between your ALSA stream and your ALSA (hardware) sink.
Anyway, for most use cases pulse is better than ALSA. The idea is good, but it has too many bugs and limitations. Routing *everything* through userspace and mixing *everything* in software (no hardware acceleration) using self-growing buffers defies the idea of a good, low-delay sound card.

 

[Djoga'Ro]

Just call systemd what is/brings - middleware.

 

[Plume]

I would just like to note that most bugs at the beginning of Pulseaudio were due to buggy sound drivers (or whatever PA used) and not Pulse itself.

 

[bzar]

I have a strange sense of deja vu from this conversation. Won't go back into it

 

[rygD]

I have a strange sense of deja vu from this conversation. Won't go back into it

This topic has been pretty popular in many places for the last couple years or so.

 

[ilo_pona]

Not a big systemd (the desktop people have taken over init, wtf year is this?) or pulseaudio fan but if there is a use-case where they would shine, it is a device like this. I've used pulseaudio as a part of WebOS for many years and it has performed well.

I run sysvinit and jack on all my workstations and laptops and could imagine them working well on the Pyra with some effort too though. sysvinit would be better for power consumption. jack is the high end stuff.

 

[Silent-Hunter]

I would like OpenRC, but does Pulseaudio require systemd?

 

[Luke-Jr]

I would like OpenRC, but does Pulseaudio require systemd?

Last I checked, it didn't. But in any case, I sure hope the Pyra won't require Pulseaudio for anything.

 

[EvilDragon]

Pulseaudio builds on Alsa, so you can also disable Pulseaudio and just use Alsa. It just won't be as comfortable anymore.

 

[_jr_]

I suspect that some ports (e.g. a phone suite) won't run without the pa daemon.

 

[Letalis Sonus]

I suspect that some ports (e.g. a phone suite) won't run without the pa daemon.

I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.

 

[fahrstuhl]

I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.

Bluetooth headset support with bluez5 seems to depend on pulseaudio.

 

[_jr_]

I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.

Actually I don't have a clue, but looking at my N900's packages it seems that the voice support is directly integrated into pa (there are also some misc packages that directly depend on the pa daemon, but these may be erroneous).

 

[Z-GRADT]

Anything less than 32 GB is a joke. 16 GB might be acceptable *right now*, but how about 5 years from now? My laptop is older than that.

 

[Silent-Hunter]

Anything less than 32 GB is a joke. 16 GB might be acceptable *right now*, but how about 5 years from now? My laptop is older than that.

Linux is small and efficient, it should work even with 16.

 

[Bosbeetle]

Ah we're in the era where 16 GB is considered small, good to know


I

 

[Neelix]

A while back I needed to get a microSD card for one of my devices. I figured I'd only need a small one, so I asked for the smallest card they had at the store, which I figured would be 2GB. Turned out the lowest capacity they carried was 8GB.

-Neelix

 

[WizardStan]

Anything less than 32 GB is a joke. 16 GB might be acceptable *right now*, but how about 5 years from now? My laptop is older than that.

You realize there are 3 SD slots on it, yes? One internal microSD, and two external full sized SD. 16GB for high speed storage of the OS is more than enough. 4GB would probably be more than enough for the lifetime of the Pyra.
The Pandora only has 512MB and it doesn't suffer under normal use. The actually rare people that need more space for their OS have used SD cards, and on the Pyra that's going to be even easier.

 

[slaeshjag]

The pandora suffers greatly from only having 512 MB internal storage. Just look at the clusterfuck that is the code::blocks PND. Had we had storage to install those tools properly, things would've been an awful lot better.

 

[rygD]

Serious question: Is that normal use? I don't mess with that stuff, so it isn't normal for my use, but I don't know what everyone else does.