And why, if its not doing what it was created to do, then, would I keep it around at all? This type of "you can do what you want, but it needs to be this way" crap is why I've stepped out of most online and open-source communities. I can see the "this is how it's done" type of thing for electronics - most of the time there is only one way to do something in electronics...

You know what, fuck it - I'm spending too much time discussing this and not enough time working on the API wrapper-layer I need to create for some paying work. I'll check back Sunday or Monday.

I'm not sure if my experiences are common, but your first point is changing - GoG.com and Steam both have lots of games that work exceptionally well in Linux (in fact, Steam has a whole category of Linux games that is, apparently, over 700 strong and fast approaching 1000).

Your second point, however, seems like it might be accurate. I have not checked the capabilities of LibreOffice's spreadsheet in a while - preferring instead to do my budget and such using Google's spreadsheet tools - but around two years ago I had problems getting a spreadsheet in LibreOffice to properly cascade values through various formula in related cells. This might just have been user error, but the fact that it occurred at all says something.

As I've stated elsewhere, Lennart appears to be or have been lead on two other major projects - PulseAudio and Avahi. Pulse somewhat meets your description, but Avahi does not.

I know you might find this hard to believe, but I was serious when I suggested turning the stated "attempted troll" around on the troll. Sadly, your comment - a mix of an ad hominem and strawman attack - does just the opposite. Please stop - it does no-one any good and consumes time and effort best spent in other places (like paying work).

Agreed. PulseAudio was great when ALSA didn't exist, but since ALSA provides 99% of the same functionality, having it replicated like this is insane. Sadly a number of companies producing non-open programs for Linux rely on PulseAudio, so removing it completely is currently impossible.

As far as I know, Pulse Audio is the only other major project that Lennart Poettering has been the lead developer for that has been shown to be broken in major ways for any length of time. Another of his projects is Avahi, which appears to work perfectly and not have any major problems. To point at his decision with PulseAudio to try and mimic the MacOS and Windows sound systems - and the repeated breakages introduced by that code until quite late in its lifetime (and after it's functionality was no longer actually needed) - and claim that it proves he does not and cannot write good code or control the scope of a project is a smear. You need more than one previous time something has happened to link to its current incarnation to show a pattern.

Yes, systemd is growing wildly and doesn't seem to be constrained to just being an init-system (instead actually replacing some system services that modern linux userlands expect to see) but twice can be a coincidence. (Three times, however, is "enemy action")

With the way systemd has consumed other projects - like udev - and has become a required dependency of others - ISTR that this is true of at least one part of Gnome as of Gnome 3.14 (oddly said part does not, AFAIK, have a non-systemd counterpart even though it possibly could) - the ability to choose a different init for Linux is becoming restricted.

In truth there is an idea I saw somewhere on the net in the last couple of months about a way to fix a lot of the problems - percieved or otherwise - with systemd. It involved having a very small, almost impossible to screw up program running at PID 1 that redirected reparent attempts off to another process and had stuff like the management of starting/stopping daemons as a third process. At no point would that setup require having any daemon or system service built into it.

However... I am not a skilled enough programmer to think I could make a good attempt at such a system, though I'd be willing to contribute to such, even if it is for reviewing code for quality and acting as one of the voices of reason against bad ideas that might be suggested.

I have used a T61p, a T400 and am now using a T510 - all have had PulseAudio installed because of Skype or another program that required it. I have not had a problem with it on these systems at all. All three of those ran OpenSUSE 12.3, Fedora 19 or Fedora 20. The problem here might be that the hardware does things that Pulse doesn't expect, which throws off whatever heuristics or simple selection code PA might be using. I know that with the Dell Inspiron 1420 I had about 7 years ago there was an issue where PA would act up if I plugged in headphones while the machine was plugged in and then unplugged the machine and pulled the headphones. That issue was strange, but it might have similar roots to what has been asked about here. I'd suggest contacting the Debian folks and possibly the PA folks themselves, as this issue would be of interest to both groups.

It very well could be, but why not ignore the trolling or turn it on it's head by actually answering the question and not getting into deep discussions or flame wars about the creator of the software in question?

(Note: as I've said in another comment, I have a philosophical difference of opinion with Mr. Poettering, but I refuse to attempt a smear campaign - even though I might have contributed to one in the past, I've come to the conclusion that it's not worth my time)

Nah, I've had similar problems with PulseAudio in the past. Sometimes it's a vendor configuration issue and sometimes it's just that Pulse tries to be smart and fails at it. When I have no need for PA (never, these days, since it is required by Skype) I don't install it because of those problems I've had in the past. Lately I've been using Fedora 19 and Fedora 20 and have not had a problem. Nor have I had a problem with it running a recent OpenSUSE or an "alternative" distribution like Sabayon.

Calling someone asking a question like this a "smear campaign" against Linux - or, as another commenter has done, a "smear campaign agaisnt Lennart Poettering", well... I have a philosophical disagreement with Mr. Poettering over how systemd is consuming all kinds of other projects in the name of faster boot times. But I will not attempt to smear him, except to say that the way systemd has turned into something similar to the bloated beast that is the Windows 'svchost.exe' makes me think that the age of the classic Unix "do one thing and do it well" is over in Linux-land.

Sometimes complexity is required to make things simpler down the road.

I cannot see this being the case here. I read a bit on the net a week or so back (think it was on the 'boycott systemd' website) that actually pointed out that the existing init system is a lot more complex than such a key part of the system needs to be. An init that does nothing but start one other process and then makes sure to notify of any processes needing reparenting or reaping on a specific Unix or Network socket to whatever process is listening would be better.

Why? Because then the system would be modular and survivable - the process handling being the "orphaned process parent" could be separate from the "reaps zombie processes" part of the system. The part that handles actually starting up system services and making sure they are running will be separate from either as well.

This is a clear separation of duties, simplifies all the different parts of the code to make them easier to check for correctness and ensures that it would take something going monumentally wrong for the system to crash because something happened that tried to "kill init".

I could, probably, write the basis of this entire system myself in a month or so of concentrated coding but would first have to start with an equally long period of research and planning to make sure I knew exactly how the parts were to interact, how to make sure that the orphaned processes were properly reparented, etc...
While I could probably find the time to do this, I do not, currently, have the time to do this and there are certainly people out there with more skill at writing important system code like this than I am.

(Come to think of it... Before I spotted this post and had an unnatural urge to respond, I recall someone mentioned Solaris' SMF as being similar to my proposal. Which means that at least 3 (at least somewhat) well educated people think that this separation of duties into multiple modules is a good thing)

Every Android device I have has USB debugging turned on and is set to allow ADB connections to my other machines and I can do a "logcat" or even "adb shell". This does not help when the device gets stuck somewhere in the boot process and just hangs (and I have had this happen). This also does not help when the device has decided that it is no longer going to allow USB connections. It also does not help when the device freezes and nothing is shown in "adb logcat" and an "adb shell" hangs.

The fact that I can later go in and get a copy of the log, however, does help immensely.

When I try to start a service and it does not start the reason why should be logged in the system log or the programs own log file. I should not have to use commands to communicate with the init process to find out the reason. Whats more is that the error messages I have seen when I have had to interface with systemd have been singularly unhelpful and in one case actually pointed me in the wrong direction when looking into a solution. Now this may not be different from if the data had been logged to the system log or an applications logfile, but I have seen much more helpful errors from systems using sysvinit or upstart. I have, admittedly, also seen similarly unhelpful messages from those two, but at least those messages were stored in a place and a format that would (hopefully) survive a panic or oops - and even be much more easily reconstructed if the file is damaged.

I have nothing against replicating logs over a network or other connection and I have nothing against having to go and download those logs manually over FTP, TFP or even using SCP. But by doing things like storing the logs in a database instead of as a flat-text file you ensure that my job of finding out what went wrong and working to stop that from happening again just got harder because I need yet another tool to read the logs.

It does not matter what Apple does - there is tight controls on the system and code contributed to Darwin might never see life as part of the actual Mac OSX released by Apple.

The init process in Unix and Linux is a very special thing - if it ever crashes, so does the whole machine. It is the first process started by the Kernel after it finishes initializing the system and mounting the root filesystem and is the "parent" of any process that deliberately orphans it's child-processes before exiting itself. It is also in charge of "reaping" any zombie processes. With each addition to its duties the area for an error to happen increases, which increases the risk that the system will just suddenly crash.

This is a problem that people lambasted Microsoft for from the birth of Windows through it's transition to a 32 bit system and still continues to this day for an extent - that they had one piece of the system doing a lot of work and having a wide surface for errors but still critical for everything to work properly. I am loathe to praise Microsoft for anything, but I must praise them for this - they have been moving away from that and I have actually found Windows 7 to be pleasantly stable - to the point of actually being able to recover from the graphics drivers crashing and managing to recover and re-load and re-initialize the system without losing any data. They have turned things around and begun to compartmentalize things to an extremely high degree - lowering the amount of code in each component, raising the ability of their programmers to actively find and fix the bugs during development and lowering the chance that a user will actually hit one of those bugs.

That compartmentalization and modularity (of the userspace, at least) was a hallmark of the design of Unix - each piece did exactly one job and did it well - as well as being as small as possible to reduce the amount of space there was for an error to be in. Yet with this "systemd" we see Lennart Poettering leading the charge to turn that around in order to save some small fraction of time during the boot process. That he created "Pulse Audio" - which appears to have flopped severely and, at least for me, was the cause of a lot of problems (not just for me - I remember finding thousands of people finding that problems were being solved when they got rid of Pulse Audio when I first started having those problems) - seems to be lost on people.

No, one mistake does not make everything someone does wrong, but in this case sacrificing simplicity and modularity so you can "do the boot process faster" is a wonderful idea. Extending the system that does that so it subsumes some of those processes it used to start in parallel for a faster boot time is just idiocy. What's next? Am I going to find that I can send a "draw an ASCII art of a kitchen sink" command to systemd and have it take over the current TTY to do just that?

If systemd was just a system for organizing the boot process, adding some complexity to simplify much more and making sure that daemons providing services get run in parallel to boot the systems boot time... Well, I'd have absolutely no objection to it. Instead it has subsumed separate projects and forced people to fork them or recreate them if they do not want to use systemd. Further, it appears that people that don't like systemd but like Gnome will soon lose the option to run new versions of Gnome because several key components of Gnome now have a hard dependency for systemd or one of it's sub-projects. Open Source is supposed to be about choice and by forcing people to use something that they might not want to that choice is being taken away.

So, with all the sarcasm I can muster, all those systemd supporters out there and it's creator have my hearty applause for doing something that goes against one of the key tenets of the Open Source movement. Bravo! You've successfully taken away something from people that you claim to be supporting. What a show of hypocracy!

Simply connecting to the same swarm does not mean you are acting in concert with any given other member of the swarm. In fact, you can only interact with a relatively small portion of a large swarm at any given time.

In this case, however, there is no proof that any of the Does were even *ONLINE* and in the swarm at the same time, regardless. Due to large amounts of legal precedent from other cases (there are several pages of precedent cases quoted in the motion) it is clear that for you to be considered "acting in concert" with another member of the swarm you have to have actually exchanged parts of the file(s) in question with them. In this case there is zero proof that the Does "acted in concert" as the law requires.

And anyway, the burden on the defense that any of these "joined" 'John Doe' copyright cases places on the defendants - in effect causing there to be a separate "mini-trial" within the overall trial for each separate defendant... To put it simply, there is no guarantee any of the Doe's in any of the cases will be using the same defense. This will place an (and this is a legal term) "unfair burden" on the defense if a given case remains joined.

But thats besides the point. The "joined Doe Case" is used for an ex parte expedited discovery period so that the plaintiff can then attempt to gain an out of court settlement from the defendents. They then dismiss the "Joined" case and file separate actions against each of those defendants that refuse the settlement offer. And since it is not a "sure thing" they don't want to do that - because the only identity you can get by serving a subpoena on an ISP is that of the account holder - who cannot be proven to have been the actual "criminal" in the case. In fact, it could be a "Significant Other", child, relative, friend or even neighbor of the account holder. Hell, in the case that the account holder has either an unsecured network or one secured with an easily broken security system (such as WEP) the actual "criminal" in the case could have been a complete stranger sitting outside the account holders house in the dead of night.

Because of the numerous possible defenses that can be argued by each individual defendant, separate cases should - technically *MUST* - be filed instead of a joined case like the one in question. These points are actually made in the motion and they make so much sense that I can see the case severed and the subpoena's on Does 2-5 quashed. (with any information gained via those now quashed subpoenas destroyed and made illegal to be acted upon)

In case you have not read the motion, please do it before posting. Its shameful to not have all the facts available when you attempt to argue something.

Nope. A swarm is nothing like a conference call, because you aren't interacting with every member of the swarm, but just a few members at a time - restricted by how many connections your bandwidth can actually handle at a given time. Regardless, the reported "offenses" are so separate in *TIME* that there is no guarantee that the Doe's in this case were actually online and part of the swarm at the same time as each other. Even if they were the chance that they actually shared parts of the movie between each other is so low as to be nil.

You really should read the documents linked to - they might be in legalese, but it is close enough to english for just about anyone to follow. And it does explain things simply enough for anyone to be able to understand them. Yes, there is an explanation for how a BitTorrent swarm works in the actual motion and it was written in such a way as to be understandable by any of the legal professionals - including the judge in the case.

And regardless of whether or not "participating in the same swarm" is a legal theory that holds water and fulfills the requirements of the rules, well... There is the fact that these "joinders" benefit only the plaintiffs in the case and create hardships for the joined defendents that break the required "fairness" of the legal system. (Yes, the legal system is supposed to be fair - surprising, no ?) So the joinder should be undone anyway :)

Again, read the actual motion. These arguments are covered in depth and explained in excruciating detail inside it. To tell the truth, I will be surprised if this motion doesn't go through. Doe #4 has a *LOT* of legal precedent on his side :)