X.Org Server Systemd Integration Proposed

[ncopa]

People used to be proud of having their code pander to the lowest common denominator? Because there is a reason why systemd doesn't work on BSDs, and it's the lack of proper kernel features required for the functionality.

The problem is not that they don't agree with those values (fewer features for better portatbility). The problem is that they intentionally try make things hard for those who disagree with their values, their vision and their terms.

[GreatEmerald]

The problem is not that they don't agree with those values (fewer features for better portatbility). The problem is that they intentionally try make things hard for those who disagree with their values, their vision and their terms.

No they don't. They don't go out of their way to make it easier for those who disagree, yes, but that's a different thing entirely.

[ncopa]

Can you please provide a link to quantitatively tested use case that backs up your issue with latency?

Why would any bother do such tests when low latency is not a design goal for pulseaudio?

from http://jan.newmarch.name/LinuxSound/Sampled/PulseAudio/:

Low latency is not a design goal, so it is unsuitable for professional audio.

Pulse Audio is designed for Consumer Audio which has other priorities/values. Pretty good explained here:

http://0pointer.de/blog/projects/when-pa-and-when-not.html

[ncopa]

No they don't. They don't go out of their way to make it easier for those who disagree, yes, but that's a different thing entirely.

Let it put it this way then: They are pretty good at standing in the way for those who disagree and encourages others to do the same.

[GreatEmerald]

Let it put it this way then: They are pretty good at standing in the way for those who disagree and encourages others to do the same.

You'd have to provide a source for that claim. And if they do, it's usually for a good reason.

[jrch2k8]

Let it put it this way then: They are pretty good at standing in the way for those who disagree and encourages others to do the same.

i think the problem radicate in the fact most people don't have the background needed to understand why systemd do what it does, so they tend to whine about thing they probably won't ever touch in their life for whatever reason they read for any random troll here and there which 99% of the time are totally wrong.

so in the end they blame systemd for the lazyness of other init systems devs.

facts:

1.) CGroups was declares a security bug by kernel devs: only systemd devs responded to the call to find a proper and secure solution (PID1 in 205+)
2.) consolekit is dead for more than a year!!! blame systemd because they are the only ones around proposing an far superior solution that even canonical has to accept for thecnical reasons
3.) network init at early boot stages is a bloddy hell of a mess/bonding is like calling satan to your home!!! blame systemd ofc for fixing it and then lay control to networkmanager later in the boot process, blame you lennart you so evil
4.) journal is binary OMFG, lennart is the devils spawn!!! ohh wait syslog still works perfectly fine(give lots less info than journalctl) and it never started that early in the boot process or stay alive during shutdown process or have a nice dbus API or give easy search functions(without 2 pHD in grep/sed engineering) and never played well with other log Systems like rsyslog and never was standard among distros(rsyslog/syslog/syslog-ng/etc)
5.) Dbus in kernel OMG the heaven will fall!!! ohh, wait basically every linux app on existance uses dbus and the kernel didn't like the idea because lennart poisoned their corn flakes but because kernel IPC is quite obsolete and slow and porting dbus to a lower layer will allow for way more performance and security plus regular apps won't even notice and kernel deis can take that train and improve a lot of subsystem suffering from IPC performance issues, well WTH lets blame lennart either way
6.) etc,etc,etc,etc blah blah blah lets go political besucase i can't understand any of the above, just to not look stupid

[profoundWHALE]

Whatever shall we do if the userland becomes coherent rather than the total clusterfuck it is currently.

Oh the tragedy.

The sarcasm in this post was so delicious that I swear I could taste it.

[dee.]

Can you please provide a link to quantitatively tested use case that backs up your issue with latency?

That's a derail and I don't need to. It's a well known fact among anyone working with audio on Linux, and you can test this at home, easily. Install any of the Linux audio softwares (Ardour, LMMS, Qtractor, all are open source and GPL-licensed, take your pick) and try to use it through PulseAudio. You don't even need a MIDI keyboard, try loading up any kind of instrument and playing with it a virtual keyboard. With PulseAudio, there are noticeable latencies which make playing in realtime a sheer impossibility.

You can try to tweak the PA settings any which way you want, you can't get the sound working glitchlessly with reasonably low latencies. Maybe you can get it to run "good enough" if you're lucky enough to have hardware that works well with PA, but it's not "good enough" for everyone. Now try the same with ALSA or Jack (if you use ALSA, you have to make sure it's routed to bypass PA, otherwise there will be no difference with PA) and you'll see a world of difference. I can easily get around 6ms latencies with ALSA, and that's without doing any tweaks or using RT kernels - with PA it's not even in the same order of magnitude.

PulseAudio is simply not designed for audio work and does not work well in that area. ALSA is a kernel-level system, so of course talking directly to it gives low latency. Whereas, something like Jack is designed by audio professionals, for the very purpose of facilitating low-latency audio. And it's kind of amazing really, Linux can actually be used as a superior proaudio workstation OS, when you choose and setup your hardware correctly - with a RT kernel + Jack, you can get latencies lower than on any other platform, including OS X. And Jack provides a modular design (real modular, not systemd-modular, hehehehe I'm trolling) that's quite unique in the realm of audio systems - it allows you to route audio between applications with very low latencies, so you can create a virtual sound setup in the same way you'd create one with actual hardware synths. Linux is actually quite capable in the realm of proaudio.

There's a reason why PulseAudio isn't being used by audio applications or audio professionals. And it's not "omg lennart let's boycott this because lennart". It's because PA simply isn't up to the task. Sure, it may be fine for normal desktop use and I never claimed anything different. But that doesn't translate to audio work where the requirements are different.

The best of both worlds approach - for hobbyist, non-proaudio-use - is to use PA with a Jack backend, where PA can be used to support things like desktop, music players etc. and it outputs via Jack, while audio applications can talk to Jack directly. This is something I've been meaning to set up myself (I'm lazy, shut up).

[mrugiero]

I think what dee. basically meant was that there is no solution that works for every use case. And I think he is right. But again, if systemd is an optional dependency only, I think there is nothing to complain about here, and I seriously doubt the X guys are that moronic to make it a hard one, I hardly believe they are morons at all.

[JX8p]

Good but not enough, I want:
- OSS, alsa and pulseaudio systemd integration
- X11, Wayland and Mir systemd integration
- KDE, Gnome, XFCE, E19, Mate, LXDE and Unity systemd integration
- More systemd integration in the kernel (better if systemd makes part of it)
- OpenRC, Sysvinit and Upstart systemd integration
- Steam OS and Valve games systemd integration
- gmail systemd integration
- polkit, consolekit, PAM, dbus, udev and eudev systemd integration
- systemd as default requirement for any GNU/Linux (this case user must use systemd) and optional for GNU/Hurd and *BSD (this case the user can choose between using or not)
- Raspberry Pi support

Well, let's do some feature request in bugzilla!!!
Systemd is all good!!! It's better than Linus projects (I think people call it "Linux").

Not enough. Systemd will not be complete until Lennart adds an email client.