Live data from Hacker News

Systemd: The Biggest Myths

0pointer.de

91–100 of 118 posts

Re: Systemd: The Biggest Myths

#91
post #88

Earlier quoted context omitted.

Yes, you should be an expert of the field to critique it. Otherwise you are talking about thing that you don't know yourself.

You don't need to be an expert in the culinary arts to determine the tastiness of a dish.

I don't like the taste of the food because I don't like the cook. Is that what are you defending? Secondly, you have to be an expert or at least knowledgeable to certain extent to talk about ingredients and style of cooking. Throwing 15 ingredients in a heated pan doesn't make you an excellent cook. Just because you can taste something delicious doesn't mean you will know everything about the that food.

Re: Systemd: The Biggest Myths

#92

Earlier quoted context omitted.

You seem to be implicitly claiming that one only earns a right to critique the usability of a given piece of software if one is also capable of debugging and enhancing that software. Do you really believe that?

Yes, you should be an expert of the field to critique it. Otherwise you are talking about thing that you don't know yourself.

A user having problems with a piece of software should NEVER have to be an expert in the field to critique it.

Re: Systemd: The Biggest Myths

#93
post #88

Earlier quoted context omitted.

You don't need to be an expert in the culinary arts to determine the tastiness of a dish.

I don't like the taste of the food because I don't like the cook. Is that what are you defending? Secondly, you have to be an expert or at least knowledgeable to certain extent to talk about ingredients and style of cooking. Throwing 15 ingredients in a heated pan doesn't make you an excellent cook. Just because you can taste something delicious doesn't mean you will know everything about the that food.

This premise is flawed. There are certain ingredients that one just doesn't enjoy. If a dish is cooked with those ingredients, you won't like it regardless of the quality.

That's pretty much where my analogy falls apart, so I'm ditching it.

Whether I'm capable of contributing to a project that does not, in its current state, suit my needs has nothing to do with whether I'm in a position to contribute to that project.

This is especially true when there is an alternative that I'm already accustomed to using.

Re: Systemd: The Biggest Myths

#94
post #32

Earlier quoted context omitted.

Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days). However, I run Linux in three locations and here's where systemd fits for me: 1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init…

Learning new tools is bad?!

Sure.

Learning a new tool which doesn't teach you anything new except how to use this particular tool, is mildly bad. That wasted your time.

Re: Systemd: The Biggest Myths

#97

Earlier quoted context omitted.

I don't like the idea of anyone running mission critical services from their homedir.

Why not?

I think a lot of the benefits you get by running services on separated paths, as special-purpose users, ... is that you minimize side-effects provoked by work on other parts of the system.

For data shared by sevaral users, I very much prefer some separate /data/service/instance/... structure. Also much easier to allocate sane directory permissions.

Re: Systemd: The Biggest Myths

#98

Earlier quoted context omitted.

I also find it telling how he closes the ticket asking everyone to go upstream and use PulseAudio's ticket system ( http://www.pulseaudio.org/ticket/606 ), which gives me this error: ------------------------------- Internal Server Error TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION' -------------------------------- That kind of sums up.

He doesn't run a bug tracker any more?

PulseAudio bug tracking moved to the freedesktop.org Bug Tracker: https://bugs.freedesktop.org/describecomponents.cgi?product=...

I don't know whether existing open bugs were moved over at the time though.

Re: Systemd: The Biggest Myths

#99
post #61

Earlier quoted context omitted.

Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.

"I seriously doubt that many of those actually do anything reasonable with audio." Actually, serious audio work on Linux is done with JACK. PulseAudio is completely inadequate for serious audio work.

You're stating it as if it were a shortcoming of PulseAudio. PA is inadequate for most audio work, because the latency is too high -- which is a feature.

Latency vs. CPU usage is always a compromise. To achieve low latency, you need very small buffers for "rendered" audio, and lots of well-timed copy operations to the audio hardware. To just play some audio files efficiently, you want large buffers, because then fewer copy operations are necessary.

Here's a better explanation by Lennart Poettering: http://0pointer.de/blog/projects/when-pa-and-when-not.html

Re: Systemd: The Biggest Myths

#100
post #81
post #59

Earlier quoted context omitted.

Poettering gets things wrong more than once, and Draxinger could have stomped him, if he were a little bit more informed on the details.

Can you chime in and inform us where is Lennart wrong and how? I (and probably many others) would LOVE that.

I'm not going to watch this cringeworthy thing again, but i can remember than he insisted that dbus was useful and that we need a gnome session in our login manager. That would be enough to proof the point.
Post reply on HN