My personal, unverifiable, unscientific, pulled-out-of-my-rear theory is that the development of life similar to and understandable by our own is sufficiently rare, and the universe so imperceivably large that the countless life that has evolved (we'll just say billions of instances in a suitably chosen near-infinitely-tiny fraction of the universe), just haven't *found* each other for the most part. Perhaps we're just unlucky enough to be located sufficiently far from other life, and there are billions of interactions between billions of similarly evolved lifeforms in some areas of the universe. Maybe heavy interaction between such lifeforms is the norm, and we're just part of the smaller fraction who are pretty isolated. Perhaps we are the front of life spreading into a new area, or the result of life dying off in the same area. But even that is probably overstating our importance.

Going with the above, Earth is definitely special case within a certain area, if we extend that area out until just before the closest instance of the uncountable number of other cases that meet the same criteria. :} It certainly seems to be quite unique within the area that we can currently perceive and understand. Perhaps this will change one day, when we can better understand the universe around us. Or perhaps we'll have died off long before then.

Anyway, that's how I like to look at things.

Short version: Tiny fractions of an imperceivably large universe.

Looks like Apple wants in on the patent extortion rort.

Apple's competitors can pull the same tricks too- I'd fully expect a few "innovation startups" to spring up soon, preloaded with patent portfolios, and start hitting Apple back.

My hope is that in the resulting mess a few senior people in the bigger organisations take notice and figure out that they could make huge savings by spending some of that money on political lobbying instead, get patent laws cleaned up, and pull the fangs from these lawsuits. These organisations have made great efforts to get the cheapest manufacturing, labour, and development costs. It seems strange that they haven't gone for similar savings in the legal area as well.

But I know that I'm hoping for too much.

"Linux and UNIX-like operating systems have followed a particular, if arcane, way of organizing files"

In other news, if somebody doesn't personally understand the reason for something, it is now "arcane".

Personally, I still prefer to have "/usr" on its own filesystem, so I can unmount it if I need to and tidy it up, using the tools in "/bin" and "/sbin". It's not *necessarily* a space thing. I quite like the separation between basic tools, and "everything else". If an "everything else" package install or script or similar stuffs things up, it's nice to be able to fix it in a reasonable environment (which an unmounted "/usr" gets you).

I also don't mind the separation between admin tools, and user tools. I think that covers the "/usr/sbin" versus "/usr/bin" thing.

And there we have it.

1. Copy Fruit code? / Develop own code
2. Copy Crafty code? / Develop own code
3. Customise code / Develop own code
4. Enter tournament / Enter tournament
5. Win tournament / Identify Plagiarism!
6. Oh crap /

Black to play and mate in three.

The cult of gratuitous uptime has always bewildered me.

Eventually, you are going to run into a problem that you do not know how to solve on a live system. Even if you are arrogant enough to believe in your own omnipotence, eventually you are going to run into a problem that *cannot* be solved on a live system. And even if that never happens, a hardware failure is going to bring your system to a screaming halt one day.

Sometimes the problem you are trying to solve will take some time to understand, and you need a solid understanding to plan how to properly fix an ongoing problem. Sometimes you have to hack a quick fix to see you through whilst properly planning your long-term fix.

Sometimes, some clown screws up and takes something out that the live system needed. Sometimes, that clown is you.

If you have been concentrating on keeping your amazing uptime, you have probably been neglecting any verification that your server is even *capable* of correcting booting back up, if you are ever forced into a corner and need to bring the system down. Discovering this, and attempting to fix it mid-crisis, is negligence at its worst. And leaving it to chance based on the belief you are a *nix-God and couldn't possibly be wrong?

Being reasonably confident that you can shut down and bring up a system in a crisis is important. If you're not taking time to do this verification because you think that your excessive uptime demonstrates your hardcore *nix-guru-ness, you're just being negligent.

> but listening to the End User is not one of MS's problems

After reading countless posts regarding inaction and apathy on long-term known bugs in the Visual Studio suite, I too can confirm that listening to the end user is definitely not something that MS consider their problem.

> On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear

What complete nonsense. There are plenty of projects out there that are run by people who care about the quality of their project and are keen to hear about problems with it, and plenty of commercial organisations that won't respond with much apart from "sorry that you've run into a problem, by the way, don't expect a fix". Suggesting that non-responsiveness is the primary domain of open source projects ahead of commercial ones is disingenuous; if anything, I've found the opposite to be true.

Unless people care about it specifically, you will find that it will never expire, as it will be extended every x years, until the heat-death of the universe. Why? Because as time goes by, there's more money locked up in this vault of old works, and whatever forces are there to push through these laws today, they will be there and stronger tomorrow. This will be the case until people care enough to break this lock, or your system of government collapses entirely.

I wouldn't put 2018 in your diary at all.

OverflowingBitBucket likes this.

I'm using a pair of triple- and quad-head PCs as we speak. Linux on both: CentOS 5.3 on one, Ubuntu 9.10 on the other. One ran OpenSuSE 10.2 previously. Two cheap dual-head nVidia cards, their binary drivers. Started with the xorg.conf generated from the nVidia tool. Spent several hours the first time trying to get it going years back, but nowadays just spend about 15 minutes setting it up upon install. Works as one large screen in each case. As such, I just drag things around on the (big) desktop to change displays. The doco supplied with the nVidia drivers is reasonably good and all I really used. Runs 3D stuff fine on each. One is KDE, the other GNOME. Both environments seem to have an awareness of the physical displays as well- if I hit maximise, it'll fill the current monitor. I'm not sure that the Linux ecosystem is really lacking such things.

I'm not 100% sure which features are apparently lacking? Is it just keyboard shortcuts to move a window from one physical screen to another? That'd certainly be useful, though I can already do this with a mouse. I know that the keyboard shortcut list is lacking in GNOME, and more options in KDE couldn't hurt either. Perhaps that's what it's about.

Brilliant. :) You missed your calling in marketing. ;)

> HAHa you owned him hard.

For sufficiently low values of "owned", I'm guessing.

> "if the application is not performing its' stated task, to provide audio playback, then it is a bad design."

> ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?

> wow, way to paint yourself into a corner, skippy.

Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things.

It is very clear that petrus4 was *not* saying the words you are trying to put in his mouth. It is clear that he is referring to the fact that since PulseAudio is having such widespread trouble performing its core functionality (playing sound) across so many systems, it is badly designed. And I completely agree with this position, personally. A well-designed system would not have so many problems.

Oh, and as for "bug reports" mentioned above, they're not a cure-all, nor an appropriate thing to suggest as a response when buggy and incomplete software is shoehorned into distributions. I'm also not going to waste my time putting together bug reports for PulseAudio specifically when the general attitude is as I stated in my original post- ie. everything-but-PulseAudio is to blame. Don't try to push the responsibility for a chain of poor decisions onto the people affected by them. I'll submit bug reports to the projects that I think will do something useful with them.

And to close- I will clarify that one reason I find the PulseAudio design so poor is that it simultaneously assumed and relied on all applications and drivers being perfect, such that it could be treated as a drop-in replacement. Which clearly didn't work- and really never had a chance to do so. I can't think of one half-competent person who would design a system with a vast culture of interacting applications with this assumption. By my words, I'm *not* saying or implying that the PulseAudio designers are incompetent, I am just baffled that they approached the design and integration of their system without taking this properly into account. I'm wondering what influences led to this decision. I'm guessing somebody with the know-how was pressured in some way for a deliverable. Anyway, PulseAudio integration leads to a gigantic regression in audio functionality in distributions. A properly-designed system would not cause this. Smash-it-all-and-let-people-pick-up-the-pieces isn't a solid design methodology. Oh, and let me be very clear. I am more than qualified to comment on this aspect of the design. So let's leave off any "not expert enough" arguments, okay?

Anyway, I'm done. What does such an argument achieve anyway? I'll save my positive contributions for the day when I see the PulseAudio developers and distribution integrators say: "Um, sorry guys, we sorta screwed up. What's the best way forward?"

> Where 'abject denial' is defined as documenting the issues and workarounds - https://fedoraproject.org/wiki/Bug_info_PulseAudio#Playback_problems.2C_crackling_or_skipping - and fixing them (most of the issues of this kind were fixed by kernel fixes in the last six months)? Wow, it's like a whole new vocabulary world out here.

You can choose to remain wilfully ignorant in order to make your point, or you can actually take into account the rest of the post you are replying to. I highlighted the general attitude around PulseAudio. Re-read the paragraph starting with "The order of the day...". I have seen examples of each of these things. Have you? If not, you can even find most of them in the article! Are you so tied up in PulseAudio advocacy that you really can't see these things happening?

Anyway, discussion has mostly moved on from here. My position on this whole thing is very clear. I'll drop a reply or two to another couple of posts you've made in this thread that caught my eye, and then I think I'll leave it at that.

> ... but you have absolutely no right to go commenting on the fundamental architecture and design of PA itself for all the reasons QuoteMstr listed.

I choose not to remain silent on issues that are being repeatedly denied and deflected, despite being widespread. Why on earth should I? Oh- and I have plenty of experience working on systems that have had to interact with hideously-bad systems before, and compensate for their deficiencies. I could go into them, but why? You wouldn't consider it "good enough" if I did, because they weren't *specifically* related to audio.

> In open source you have to ...

> ... they keep on walking to the M$ or Appl store.

One: Stop being so arrogant as to assume you can lay down the rules as to what someone must do, while trying to champion your cause by flying the "open source" banner. Two: Stop trying to associate a broken audio subsystem with "open source" and "Linux versus Microsoft/Apple" in order to bolster the argument and gather numbers. You want to chat about these topics some time? Fine. But let's not pretend that PulseAudio problems are about either of these.

You're trying to attack my credibility rather than my content, implying I have said or done things that I have not, suggesting I have no right to comment in the first place, and to top it all off fall back to emotional arguments by trying to associate things with established Slashdot darlings. Do you honestly not expect to be called on so many logical fallacies, on Slashdot of all places?

Are you sure you're not just the same guy, just posting anonymously this time?

I think I'll post this one sans Karma bonus.

> My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified. You couldn't tell whether OpenAL or set BLASTER is the better API, and you're just throwing around big words in lashing out at being bitten by a bug. What you should be doing instead of foaming at the mouth here is filing real, helpful bug reports, helping track down problems, and generally trying to do something. Lambasting the PA developers for not "getting the core functionality right" when you couldn't even tell me what the hell the core functionality is is definitely not in the helpful range. How much did you pay for this crap again?

This will be my last reply to you.

You do not have to be an expert on a particular area in order to point out glaring problems that an enormous number of people are having, much like you do not have to be a chef to point out that your dinner is terrible.

You have absolutely no idea of my experience in this area, and you are making some very poor assumptions.

And pulling out the whole "it's free, so take what you're given" thing is ludicrous, and coincidentally the precise point at which I stopped taking you seriously.