systemd (Was Re: tmpfs for strategic directories)

Peter Hutterer peter.hutterer at who-t.net
Wed Jun 2 03:12:23 UTC 2010


On Tue, Jun 01, 2010 at 09:58:37PM +0200, Roberto Ragusa wrote:
> Lennart Poettering wrote:
> > On Sat, 29.05.10 19:48, Roberto Ragusa (mail at robertoragusa.it) wrote:
> >> Well, I really do not want to flame anyone, but please consider that
> >> the guy proposing the change already gave us pulseaudio, which promised the
> >> "it will do anything you do now, just easier" feature too.
> > 
> > Ah, turning this into something personal. Love you too.
> 
> This is not a personal attack and I want to explain.
> You will agree with me that pulseaudio caused a lot of complaints.
> (we do not discuss if motivated or unmotivated, here)
> That bad reputation unavoidably leads to weaker trust in your
> promised guarantees.
> 
> The most painful parts of PA were mainly the underestimation of both
> "peculiar" use cases and impact of issues in related software (e.g. bugged
> alsa drivers). It is only natural to be worried about the same things
> (like lack of customizability) for this new init system.
> 
> You *are* in a worse position than someone else when proposing
> a revolution in some critical part of the system. That's no personal
> offense.
> On the positive side you are now well aware of the risks you
> face, so you will probably play it better than someone else.

Regardless of how this applies in this case, don't forget that
digging your way out of a big mess is a different way to build trust.
Sooner or later we all screw up, knowing how a person handles screwups can
be quite valuable.


> I hope your new init system will be a great success and help you
> clean your name from the PA mess. I honestly hope so.
> 
> >> We then discovered that some _trivial_ things where lost:
> >> - having multiple independent sound cards
> >> - having control of the mixer
> >> - having sound with no user logged in
> >> ... should I also mention latency, CPU usage, stability,...?
> > 
> > You seem to have no idea what you are talking about. But anyway, let's
> > not turn this into a discussion about PA. Don't need another one of those.
> 
> I've been personally been burned by these issues, to the point of
> going 90% of the way of removing PA from the system (I'm currently
> running the unrecommended system-wide instance, I manually restart it
> in some cases, I use often pasuspender and for some things I know
> I have to turn if off completely).
> 
> But I'm still on F10 and I read that pulseaudio has become better.
> Maybe I will be positively surprised when upgrading to F13.

for better or worse, released Fedora versions, especially <= N-1 don't tend
to see a lot of updates. Developer manpower seems to shift quite early to
rawhide and/or upstream and there's a few packages that only see token
efforts once the next release is out.

Staying on a particular release is unfortunately not the solution to get
real fixes into your system.

> >> Linux must NOT be Windows.
> >> Linux must NOT be OS X.
> > 
> > Well I for one think we can learn a lot from the competition. Open your
> > eyes. There's a lot of good stuff in those other OS worlds, particularly
> > in the designs of MacOS X. There's still so much they do better than we
> > do. 
> 
> With "must NOT" I do not mean "we have to be far", I mean "we are not
> obligated to be near".
> 
> In recent times some stupid (IMHO) ideas have been adopted in Linux
> just to copy what others do. Just as examples: the control of desktop
> widgets in KDE4 (functional GUI elements modified by a mouse-over???),
> the fast-user-switching approach (the Unix way is to have
> multiple X servers).

For every "stupid (IMHO) idea" there's people who disagree with the
"stupid", "IMHO" and sometimes even the "idea" part. Long term, all this is
evolutionary and some ideas die off, others prevail.
Unlike in nature, it is steered evolution though and you can help steer away
from ideas you deem bad by talking to the upstream developers. Venting on a
distribution list won't do a lot of difference.
 
Cheers,
  Peter


More information about the devel mailing list