Lennart Poettering On The Open-Source Community: A Sick Place To Be In

[ssokolow]

tsched=0

you are welcome?

Correction: Nope, that didn't work. Still getting crackle/buzz when trying to play audio from DOSBox or the copy of Wine 1.2.x I need to keep around for old Windows 3.1 games like BrickLayer.

Fiddling with the fragment size and count in daemon.conf modifies the characteristics of the noise, but I haven't been able to discern anything which might suggest a way to make things better rather than merely different and I'm fast approaching the point where it'd be better return on investment to bite the bullet, rip PulseAudio back out, and waste my time trying to figure out how to dump the default asound.conf for my soundcard so I can specify the primary soundcard without having to reinvent everything badly.

(After all, having working audio is better than having crackling audio with hotplug support and per-application volume control that I never use anyway.)

[prodigy_]

For the n-th time

Your mistake is grabbing the cheese^W^W^Wexpecting that systemd fanboys might eventually listen to the voice of reason. They won't because it's a religious thing. You challenge systemd superiority = you're wrong by definition.

[Cyber Killer]

Correction: Nope, that didn't work. Still getting crackle/buzz when trying to play audio from DOSBox or the copy of Wine 1.2.x I need to keep around for old Windows 3.1 games like BrickLayer.

You might have a too small buffer set in dosbox, something like here

[ssokolow]

You might have a too small buffer set in dosbox, something like here

Nope, I figured it out. A bug report on Launchpad listed "change rate=22050 to rate=44100 in your DOSBox conf" as a workaround and, sure enough, a fixed 22050Hz sample rate was the common factor between my DOSBox and my Windows 3.1 games running under Wine.

I confirmed that having DOSBox output 44100Hz audio worked under PulseAudio, but the Windows 3.1 games don't let you set their output format so I started investigating PulseAudio's resampling functionality.

Sure enough, switching PulseAudio back to the default src-speex-1 resampler fixes the problem at the cost of letting PulseAudio consume the CPU cycles I was trying to save in the first place.

In other words, the problem is that PulseAudio's src-linear and src-sinc-fastest resampling modes are either unusably fragile or flat-out broken.

[TheBlackCat]

Cgroups is not a systemd feature, is a kernel feature. you could make your own program to manage it, with or without systemd or even an init system. For the n-th time: systemd adds nothing new, no new features, it's worthless on itself.

So the features are not new because someone could, theoretically, write their own program to do the same thing? Are you kidding? The feature that systemd offers in this case is that you don't have to write your own cgroups manager.

[asdfblah]

So the features are not new because someone could, theoretically, write their own program to do the same thing? Are you kidding?

http://lwn.net/Articles/575672/

For many, that management daemon may well be the systemd init replacement, but there are distributions (notably Ubuntu) and users who will want a different choice. To that end, Serge E. Hallyn is working on an alternative cgroup management daemon that he calls "cgmanager".

Your fanaticism is showing.
(and this is what your beloved bullshitter leader thought about that article: https://plus.google.com/+LennartPoet...ts/au5ZsAY1vh3 , kind of like you do here)

The feature that systemd offers in this case is that you don't have to write your own cgroups manager.

You are telling me that to use one particular kernel feature, I have to buy poettering's product as a whole?

Are you kidding?

[TheBlackCat]

http://lwn.net/Articles/575672/

So there may be alternatives available some time in the future. Great. But that doesn't change the fact that it is, nevertheless, a systemd feature, and systemd was the only one offering that feature at the time that distros decided to switch to it.

You are telling me that to use one particular kernel feature, I have to buy poettering's product as a whole?

No, and I never said anything remotely similar to that. What I said, is that managing cgroups is a systemd feature. It is not the only software that could possibly offer that feature, but it was the only one doing so when projects that wanted the feature decided to use it.

[TeamBlackFox]

Poettering is probably more powerful than Torvalds at this point. If Torvalds quit merging code from RedHat, then they'd simply fork the project as Linuxd. Daemonise the entire OS while you're at it! Meanwhile, Poettering continues to push his brain-damaged products onto people. OSS4 is superior to both ALSA and PolishAudio, especially when using SDL-coded applications, and it lacks the annoying sound latency issues of both ALSA and PolishAudio ( Because it is easy to make fun of Poland, so why not? ) but that is never going to be the default.

I think that Poettering would be a REALLY good Windows developer, but he'd have to learn C# and .NET then. And that is what he has done in effect with most of his applications - reimplemented Windows concepts as programs. Systemd is basically the entire default service lineup for Windows. It also takes some annoying traits from Windows, such as the wonderful use of binary stacks for storing logs. The Registry is cack as it is, and that is effectively an entire OS in binary stacks.

The Linux kernel has been hijacked from its original intent - from a POSIX compliant, open source kernel, to a Windows or Mac desktop replacement. However, the fundamental differences between Windows, Mac and the UNIX family and clones is so divergent that none of them should, ideally, intersect. Consider that Windows and Mac have their own centralised configuration stacks, the Registry and the /Library. The closest blood descendants of the Bell Labs UNIX don't have this, they instead use plain text config files located in the directory tree for their application. Some versions such as AIX have tried to do this their own way, using smit for example, but in practice you soon realise it is faster to open vi and edit the config file manually, especially for users like myself with symptoms of RM injury, which is aggravated by excess mouse use. People like Poettering have tried to make GNU/Linux into an open source version of Windows, and fail continuously at this goal for a few reasons:

The components were never designed for this purpose
The components will never be unified ( BSD is userland, kernel, shell and utility unified, systemd is userland-only, therefore it remains a disjointed, monolithic yet modular mess, and the Linux kernel isn't tied to GNU, so it won't ever be unified )
The components lack proper quality control and usability that you find in a commercial OS.

As GNU/Linux continues its fall from grace, I'm wondering what the future holds. OS X fell from grace during the POWER - Intel transition and the Leopard-Snow Leopard, Windows was never graceful.

Beyond criticisms of PA and Poettering, I now close with my grievances against the infamous systemd:

It is a mess, with a supervisor and init system occupying PID 1 ( security risk, if there is a bug in the supervisor framework, init can be taken offline or used to compromise the entire system )
Monolithic, despite having separate binaries
Everything said here http://ewontfix.com/14/ and here http://boycottsystemd.org
Buggy and tied to specific kernel versions
Manned by unprofessional and coercive developers.

[Luke_Wolf]

The Linux kernel has been hijacked from its original intent - from a POSIX compliant, open source kernel, to a Windows or Mac desktop replacement.

Oh Really?

From: [email protected] (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: <[email protected]>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki

Hello everybody out there using minix -

I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I’d like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I’ll get something practical within a few months, and
I’d like to know what features most people would want. Any suggestions
are welcome, but I won’t promise I’ll implement them :-)

Linus ([email protected])

PS. Yes – it’s free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that’s all I have :-(.

[Luke_Wolf]

Or for those who didn't quite get it... Linux was a desktop hobbyist OS for intel 386 AT clones that got hijacked into being an open source POSIX compliant kernel