Bullshit flash has severe overhead it can't get around by default. Playing videos in a regular program is far more efficient.
As for h264 itself, most of the animosity to it would be gone the moment software patents are deemed invalid in the US (that whole, you shouldn't be able to patent math business).
Windows 64-bit works perfectly, looks fantastic, and plays all the media I want (including Flash) without shitting the bed like Ubuntu 64-bit does.
Does anything else besides flash bugger up for you? if so what. I find general media playback far better on linux than to windows. But flash is nasty.
I find most tiny distro installs like ubuntu severely wanting in many ways, but usually they are ok for people who just want to watch movies and use firefox.
Easy solution is to just download the flv's automatically from firefox (things like DownloadHeler will do this) and then use mplayer or some other decent media player to play it back.
I have a modern quad core machine, and fullscreen flash videos take up a whole core still with occasional stutter or tearing.
Also I have had the npviewer.bin process (flash) use up to 40% of my systems memory (6 gig total, so 2.4gig in use) that, is just crazy, there is no justification for it.
Yes, the transistor count on CPUs will grow faster than GPUs, until it won't be so big of a leap. We're obviously not there yet, but we're headed that direction.
You're kidding right, all process shrinks will due is enable gpu makers to use MORE transistors to themselves, and gpu's have been growing in transistor count relative to cpu's for quite some time.
but with entirely separate dies glued together, it really doesn't matter.
so, assuming you're going to stick a modern six core die to a 480 die, would you care to explain how you are going to dissipate enough heat before they fry eachother from being in such close proximity?
There is enough trouble cooling the gpu alone in the high end, what with their up to 200 watt thermal dissipation these days. Adding a second heavy heat creating part right next to it is begging for trouble.
Your mistake is you think advances in process won't be used to make better gpu's, they will.
Every user is different and wants to do different things with a PC. These usually need different packages: my GB of extra stuff differs from your GB of extra stuff.
you will find 90% of what people get is the same, so why not include that 90% and greatly reduce the amount people on average need to download and give a larger base for easier program deployment?
Hell taking the 700mb is enough for everyones basic install to it's extreme we should all just do net installs.
And when the revision that a given app requires is newer than the version that was current when some popular distro froze, that causes trouble. For example, a lot of dedicated servers leased from providers such as Go Daddy will be running 8.04 for quite a while, and depending on PHP 5.3 would exclude 8.04 until this bug [launchpad.net] is fixed.
Again with the windows analogy, I'm not going to try and run crysis on windows 3.1 am I? or alsa on linux 2.0
Commercial programs take time to make, and generally don't depend on beta'ish apis, which generally means whatever libs they are using have been shipped for one to two release cycles.
I don't see how new releases not supporting distributions that have not had updates in 1-2 years is an issue at all.
But how can an application publisher be sure that distributions have 1. those libraries or language interpreters and not their alternatives (e.g. a Qt-centric distro not including GTK+) and 2. new enough versions of said libraries or language interpreters (e.g. PHP 5.3 not 5.0), without having the./install shell script inside the tarball try to figure out what distro you're on and run either apt-get or yum to ensure it?
QT and gtk+ are the main toolkits in use everywhere, why not include both is the whole point. As mentioned most of the problem stems from distros who don't. As mentioned I've had both installed for the last 8 or so years, and when I install things it is an extreme rarity to need a new library.
As for whether compatible libs are installed this is solved by the way shared objects are handled, those with compatible api's and functionality tend to have the same name, those that don't get a new revision, and the old ones are still included in distros for backwards compat.
Even though I've never used gnome on this machine I've had the desktop environment and it's libs installed from day one just in the off chance something I may like needs it, the extra disk space needed is miniscule.
After a bit more research, I just discovered that Ubuntu also comes on DVD according to this page [on-disk.com]. But a lot of end users have the CD version.
This is because this is the way ubuntu wants it, go to the main ubuntu page, click 'download ubuntu' do you see any mention of a dvd at all? you have to actively hunt it to get it. If anything it should be the opposite with the lesser functionality gimped version being the option.
The collection of all packaged software and all language packs for one of the major desktop distros (e.g. Ubuntu, Debian testing, Fedora) would take far more than 4 GB. Therefore a full repository would span more than 1 DVD.
Of course the entire repository would take far more space than a dvd, I'm not talking about the ENTIRE repository, just a significantly larger (5x or so) subset, the largest common denominator of packages. Having done installs that way over the last ten years the majority of people never need more, for those that do it's very little.
Or more realistic in this case, Windows XP SP2/3 vs. Windows 7. We can assume that SP2/3 is analogous to RHEL/CentOS, with fairly obsolete software that has had security fixes backported, and Windows 7 is like a fairly recent Ubuntu or Fedora.
You missed the analogy, it wasn't concerning age it was concerning available functionality out of the box. Any distro that is limited to 700mb install iso is gimped by default, and with my usual setup would require gigabytes of yum/apt-get downloads.
You will NOT be seeing a gtx480 equivalent in your cpu die any time soon.
From a thermal and 'oh dear god so many transistors' perspective it's pretty much impossible since as process improvements occur the gpu's just use more transistors to suit.
Fpu's were a drop in the bucket compare to modern decent gpu's
with static glibc, libstdc++, Xlib, GTK+, and the like, would be huge.
Those aren't the kind of libaries you'd be static linking, they've been a pretty safe assumption for at least the last five years. It's the small esoteric packages that few people have by default that you would.
And because it would have to include its own GTK+ themes for people who happen to use a distro built on Qt or FLTK or something and don't have any GTK+ themes installed, it wouldn't be styled to fit in with the rest of the distribution even if it does use GTK+, and it would stick out like a sore thumb as much as the Windows version of GIMP does.
The problem are distros that don't ship both qt and gtk+ and themes for both. Usually this comes from having severe data constraints imposed by the use of silly 700mb isos
On an Internet connection with a 5 GB per month transfer allowance, downloading a CD image takes 14% of your monthly allowance, while downloading a DVD image takes almost all of it. Ubuntu comes on a CD instead of a DVD because Canonical wants it to be popular even in countries where home Internet connections are rate-limited in such a manner.
So install media should be forever limited to 700mb for these people? That is ridiculous. In such instances it would be easier and cheaper to get the discs by snail mail. There is something very elegant about having almost all the software you will ever need in one nice disc, and almost never having to install things for dependencies.
An example would be like comparing writing software for windows 95 vs windows 7, sure if I really want some functionality that is in seven to be used in windows 95 (depending on what it is of course) I could probably use it in 95, but reimplementing (or in linux's case rebundling through static linking) it all would be a severe exercise in pain that there is no point putting yourself through just so your os install can stay tiny.
We don't expect microsoft to fit vista, office, sql server, visual studio, on one disc, hell vista and mac os x alone have an install dvd. Why gimp linux installations with install media requirements that were only realistic for a basic os (without even any useful software) over a decade ago?
Chromium does this, and the package manager ends up unable to package security holes that are eventually discovered in the dependencies. That's why Chromium isn't in Fedora.
Yes I know this, and this is precisely why it is a bad idea to do it like windows does. But you people would prefer this to having to rely on central repos for packages (well if not I don't see why you'd be bitching about the way repos work)
The command line does, unless you use an on-screen keyboard. What "shit" are you talking about, other than simply presenting a wizard listing things that correspond to all the common options for./configure?
How many people actually change their configure parameters that are normal users? configure auto-detects what optional packages are installed and compilees accordingly. I have what two constant commands to type in as opposed to several next and tickbox dialogs which can vary depending on program. Consistent constant shorter cli is easier in this regard.
But this leaves the problem of not having a compiler and the right -dev packages installed. Should the wizard try to detect whether it's running on Ubuntu or Fedora and run the distribution's counterpart to sudo apt-get install build-essential some-library some-other-library first? And should it come with full forked copies of the source code to these libraries, with all their (as of yet unknown) security holes that the package manager can't patch?
No it shouldn't try this, because for end users it would simply be easier to deploy the.tar.gz static compiled thing as per earlier. Compiling if it fails should only be a nice option. Also a large problem I find with things like this are distros like ubuntu that only distribute a minimum of packages on a cd iso, a full fedora dvd install has far more packages and you'll almost never run into packages missing. With the install still coming under half the size of what vista is.
Obviously doing it "right" means that the WoG people have intimate knowledge of lots of environment variations
Not really, it is very common to only have 32-bit packages and 64-bit, most of the abstraction is done by SDL and the like.
I'd rather have a CDE-style thing do the heavy lifting for me.
And people like me and most of everyone else who uses linux would not be downloading your 500mb hello world script for something we could do in a matter of kilobytes. You're welcome to deploy things how you wish, but it's a sign of sloppiness.
Download a statically compiled.tar.gz from the site that has all of it's own dependencies
Download source, './configure' 'make' 'make install' (and before you say 'this is beyond the end users capabilities, they have to go through more shit with installshield so saying so really is an insult to their intelligence.)
Particularly since people really don't seem to get why this is a problem.
Because it really isn't? (if you distribute your closed source etc app the proper way)
- I should be able to install an application QUICKLY and easily. There's no reason why "installation" should be more complicated than "copying/extracting the binaries to wherever I want them to go".
You can, take the proprietary game world of goo for example, you extract the.tar.gz and click on the world of goo script and bam, you are playing.
- I should not be dependent on some third party to get around to porting each version of software to my flavor of Linux. When a new version of Wireshark or VLC or whatever software comes out, I should be able to install it *quickly and simply* without waiting on package maintainers to get around to it (even if some are very responsive)
You aren't, either download the statically linked compiled version from their site and extract and use, or better option get the source, extract,./configure make THEN simply use.
Along with the above, I shouldn't be in a state where I can no longer easily install applications because I'm using a somewhat older distribution (and packages are no longer being maintained for that version)
You just lose the ability to do things as easily as yum install *package* or apt-get *package*... you still have the ability to install the newer things yourself just as you wanted in your first two points. Oh wait, doing so for each updated package you want is more of a pain.. which is why we have packages and maintainers in the first place.
- Although the option should be there, it should never, ever, ever, ever, ever, ever, ever, EVER be considered "acceptable" to expect users to compile an application to install it (and all the potential headaches of getting that to work, including hacking make files, dealing with dependencies, patching the software, actually doing C++ debugging, etc).
While I completely agree users should never have to patch software, debug etc. To claim an end user can't simply type './configure' 'make' 'make install' is insulting to their intelligence.
I could make a similar argument that windows users shouldn't have to continually click next and setup settings for their installshield apps, since that is significantly more painful and inconsistent than simply compiling a linux app.
Balloon up my applications with static libraries. Please. The trade-off in system administration headache would pay for itself 100s of times over.
Having a static library version downloadable from upstreams website is a handy thing, but to propose that every integrated repo app should use static libraries is quite frankly retarded.
Administering/installing applications on a windows system is an order of magnitude more effort than on linux as it is. Your complaint boils down to 1. it doesn't do it the (inefficient) way windows does by default. 2. I don't know how to package software for linux (This has been solved by other people)
If the people packaging the closed source app do it right, like what world of goo did, you extract a.tar.gz wherever you want and click on a program and it works.
If you are using any strange libraries include the so's with it so you give people the option of using it or the dynamically linked libs.
For regular programs, this tool is rather useless compared to somebody who packages their stuff well.
Are you trying to say MySQL or Postgresql are equal to Oracle in performance, reliability, or documentation?
I'm saying that oracle is becoming more and more irrelevant, as some high scale deployments of other software shows.
Some licensing schemes with oracle can wind up costing companies almost a million dollars per year. That equates to quite a few extra full time employed database administrators.. which would more than be able to make up for any perceived lack of documentation etc.
There really are very few scenarios left where you actually need oracle for your database.
Because you are working with a company that would not hesitate to fuck you over the moment it was convenient or the moment you stopped paying up.
You are entitled to your masochism, but to most here working with oracle now would be akin to being a partner with microsoft of the 90's, sure, on paper you're working together.. expect to get fucked over (except with oracle they wouldn't do it technically, just 4-6 digit licensing fees you weren't expecting).
Programmers on the versions of the ARM platform without a MMU do OK today without that happening.
Name a platform that is not embedded or does not have all of the software being run on it at once from a single software developer (ds etc do this).
Even if your own code is awesome if the user is loading random shit that can write to your memory locations you're boned anyway.
The difference back then is the multiple programs were attempting to run without the OS being capable of letting them do so properly.
Oh the os would let them run, just so happens it would let them screw each other up too if one of the programs were badly written, which is impossible to save against unless you have an mmu.
Any program that causes a segfault on a modern pc would cause serious crashes in unrelated programs/the machine in general without an mmu.
A hardware interface can have copyright protections? this is news to me, we'll have to get on to all those people who write open source drivers without specs and tell them they can't because the hardware is copyrighted/sarcasm
Reverse engineering is legal, catch is of course almost anything can be deemed illegal when you face a company that is willing to spend billions on lawyers.
At first we'll just start to see iMac like desktops but with restrictions and os akin to the iPad, because customers like the 'simplicity' etc.
Then their mac pro line sales will shrink, and xcode etc will be available for these new restricted desktops (which will be cheaper than their mac pro cousins) however for a significant fee.
Then once the sales of the mac pro line is more or less defunct like what these xserves are, they can discontinue them with only a few people making such a fuss.
While there are many things that could stop this, you must admit it is in apples own interest to do it, and it does make sense. You would have to pay to be able to develop for your own devices, and the resulting binaries would only work on your device unless you get it approved through the app store.
Your best bet if you don't like pulseaudio is probably to use jack instead, you can make it so that pulseaudio feeds it's streams to jack and by changing your asound.conf get alsa programs to use it too.
As a bonus you get high quality low latency audio, that doesn't die all the time like pulse and has more functionality... still think pulse should have never existed.
Slashdot Mirror
Rubbish. Flash with H.264 is fucking fantastic.
Bullshit flash has severe overhead it can't get around by default. Playing videos in a regular program is far more efficient.
As for h264 itself, most of the animosity to it would be gone the moment software patents are deemed invalid in the US (that whole, you shouldn't be able to patent math business).
Windows 64-bit works perfectly, looks fantastic, and plays all the media I want (including Flash) without shitting the bed like Ubuntu 64-bit does.
Does anything else besides flash bugger up for you? if so what. I find general media playback far better on linux than to windows. But flash is nasty.
I find most tiny distro installs like ubuntu severely wanting in many ways, but usually they are ok for people who just want to watch movies and use firefox.
Easy solution is to just download the flv's automatically from firefox (things like DownloadHeler will do this) and then use mplayer or some other decent media player to play it back.
I have a modern quad core machine, and fullscreen flash videos take up a whole core still with occasional stutter or tearing.
Also I have had the npviewer.bin process (flash) use up to 40% of my systems memory (6 gig total, so 2.4gig in use) that, is just crazy, there is no justification for it.
Yes, the transistor count on CPUs will grow faster than GPUs, until it won't be so big of a leap. We're obviously not there yet, but we're headed that direction.
You're kidding right, all process shrinks will due is enable gpu makers to use MORE transistors to themselves, and gpu's have been growing in transistor count relative to cpu's for quite some time.
but with entirely separate dies glued together, it really doesn't matter.
so, assuming you're going to stick a modern six core die to a 480 die, would you care to explain how you are going to dissipate enough heat before they fry eachother from being in such close proximity?
There is enough trouble cooling the gpu alone in the high end, what with their up to 200 watt thermal dissipation these days. Adding a second heavy heat creating part right next to it is begging for trouble.
Your mistake is you think advances in process won't be used to make better gpu's, they will.
Every user is different and wants to do different things with a PC. These usually need different packages: my GB of extra stuff differs from your GB of extra stuff.
you will find 90% of what people get is the same, so why not include that 90% and greatly reduce the amount people on average need to download and give a larger base for easier program deployment?
Hell taking the 700mb is enough for everyones basic install to it's extreme we should all just do net installs.
And when the revision that a given app requires is newer than the version that was current when some popular distro froze, that causes trouble. For example, a lot of dedicated servers leased from providers such as Go Daddy will be running 8.04 for quite a while, and depending on PHP 5.3 would exclude 8.04 until this bug [launchpad.net] is fixed.
Again with the windows analogy, I'm not going to try and run crysis on windows 3.1 am I? or alsa on linux 2.0
Commercial programs take time to make, and generally don't depend on beta'ish apis, which generally means whatever libs they are using have been shipped for one to two release cycles.
I don't see how new releases not supporting distributions that have not had updates in 1-2 years is an issue at all.
But how can an application publisher be sure that distributions have 1. those libraries or language interpreters and not their alternatives (e.g. a Qt-centric distro not including GTK+) and 2. new enough versions of said libraries or language interpreters (e.g. PHP 5.3 not 5.0), without having the ./install shell script inside the tarball try to figure out what distro you're on and run either apt-get or yum to ensure it?
QT and gtk+ are the main toolkits in use everywhere, why not include both is the whole point. As mentioned most of the problem stems from distros who don't. As mentioned I've had both installed for the last 8 or so years, and when I install things it is an extreme rarity to need a new library.
As for whether compatible libs are installed this is solved by the way shared objects are handled, those with compatible api's and functionality tend to have the same name, those that don't get a new revision, and the old ones are still included in distros for backwards compat.
Even though I've never used gnome on this machine I've had the desktop environment and it's libs installed from day one just in the off chance something I may like needs it, the extra disk space needed is miniscule.
After a bit more research, I just discovered that Ubuntu also comes on DVD according to this page [on-disk.com]. But a lot of end users have the CD version.
This is because this is the way ubuntu wants it, go to the main ubuntu page, click 'download ubuntu' do you see any mention of a dvd at all? you have to actively hunt it to get it. If anything it should be the opposite with the lesser functionality gimped version being the option.
The collection of all packaged software and all language packs for one of the major desktop distros (e.g. Ubuntu, Debian testing, Fedora) would take far more than 4 GB. Therefore a full repository would span more than 1 DVD.
Of course the entire repository would take far more space than a dvd, I'm not talking about the ENTIRE repository, just a significantly larger (5x or so) subset, the largest common denominator of packages. Having done installs that way over the last ten years the majority of people never need more, for those that do it's very little.
Or more realistic in this case, Windows XP SP2/3 vs. Windows 7. We can assume that SP2/3 is analogous to RHEL/CentOS, with fairly obsolete software that has had security fixes backported, and Windows 7 is like a fairly recent Ubuntu or Fedora.
You missed the analogy, it wasn't concerning age it was concerning available functionality out of the box. Any distro that is limited to 700mb install iso is gimped by default, and with my usual setup would require gigabytes of yum/apt-get downloads.
mod parent up
You will NOT be seeing a gtx480 equivalent in your cpu die any time soon.
From a thermal and 'oh dear god so many transistors' perspective it's pretty much impossible since as process improvements occur the gpu's just use more transistors to suit.
Fpu's were a drop in the bucket compare to modern decent gpu's
with static glibc, libstdc++, Xlib, GTK+, and the like, would be huge.
Those aren't the kind of libaries you'd be static linking, they've been a pretty safe assumption for at least the last five years. It's the small esoteric packages that few people have by default that you would.
And because it would have to include its own GTK+ themes for people who happen to use a distro built on Qt or FLTK or something and don't have any GTK+ themes installed, it wouldn't be styled to fit in with the rest of the distribution even if it does use GTK+, and it would stick out like a sore thumb as much as the Windows version of GIMP does.
The problem are distros that don't ship both qt and gtk+ and themes for both. Usually this comes from having severe data constraints imposed by the use of silly 700mb isos
On an Internet connection with a 5 GB per month transfer allowance, downloading a CD image takes 14% of your monthly allowance, while downloading a DVD image takes almost all of it. Ubuntu comes on a CD instead of a DVD because Canonical wants it to be popular even in countries where home Internet connections are rate-limited in such a manner.
So install media should be forever limited to 700mb for these people? That is ridiculous. In such instances it would be easier and cheaper to get the discs by snail mail. There is something very elegant about having almost all the software you will ever need in one nice disc, and almost never having to install things for dependencies.
An example would be like comparing writing software for windows 95 vs windows 7, sure if I really want some functionality that is in seven to be used in windows 95 (depending on what it is of course) I could probably use it in 95, but reimplementing (or in linux's case rebundling through static linking) it all would be a severe exercise in pain that there is no point putting yourself through just so your os install can stay tiny.
We don't expect microsoft to fit vista, office, sql server, visual studio, on one disc, hell vista and mac os x alone have an install dvd. Why gimp linux installations with install media requirements that were only realistic for a basic os (without even any useful software) over a decade ago?
Chromium does this, and the package manager ends up unable to package security holes that are eventually discovered in the dependencies. That's why Chromium isn't in Fedora.
Yes I know this, and this is precisely why it is a bad idea to do it like windows does. But you people would prefer this to having to rely on central repos for packages (well if not I don't see why you'd be bitching about the way repos work)
The command line does, unless you use an on-screen keyboard. What "shit" are you talking about, other than simply presenting a wizard listing things that correspond to all the common options for ./configure?
How many people actually change their configure parameters that are normal users? configure auto-detects what optional packages are installed and compilees accordingly. I have what two constant commands to type in as opposed to several next and tickbox dialogs which can vary depending on program. Consistent constant shorter cli is easier in this regard.
But this leaves the problem of not having a compiler and the right -dev packages installed. Should the wizard try to detect whether it's running on Ubuntu or Fedora and run the distribution's counterpart to sudo apt-get install build-essential some-library some-other-library first? And should it come with full forked copies of the source code to these libraries, with all their (as of yet unknown) security holes that the package manager can't patch?
No it shouldn't try this, because for end users it would simply be easier to deploy the .tar.gz static compiled thing as per earlier. Compiling if it fails should only be a nice option. Also a large problem I find with things like this are distros like ubuntu that only distribute a minimum of packages on a cd iso, a full fedora dvd install has far more packages and you'll almost never run into packages missing. With the install still coming under half the size of what vista is.
Obviously doing it "right" means that the WoG people have intimate knowledge of lots of environment variations
Not really, it is very common to only have 32-bit packages and 64-bit, most of the abstraction is done by SDL and the like.
I'd rather have a CDE-style thing do the heavy lifting for me.
And people like me and most of everyone else who uses linux would not be downloading your 500mb hello world script for something we could do in a matter of kilobytes. You're welcome to deploy things how you wish, but it's a sign of sloppiness.
if it isn't in the repo, do one of two things
Download a statically compiled .tar.gz from the site that has all of it's own dependencies
Download source, './configure' 'make' 'make install' (and before you say 'this is beyond the end users capabilities, they have to go through more shit with installshield so saying so really is an insult to their intelligence.)
Particularly since people really don't seem to get why this is a problem.
Because it really isn't? (if you distribute your closed source etc app the proper way)
- I should be able to install an application QUICKLY and easily. There's no reason why "installation" should be more complicated than "copying/extracting the binaries to wherever I want them to go".
You can, take the proprietary game world of goo for example, you extract the .tar.gz and click on the world of goo script and bam, you are playing.
- I should not be dependent on some third party to get around to porting each version of software to my flavor of Linux. When a new version of Wireshark or VLC or whatever software comes out, I should be able to install it *quickly and simply* without waiting on package maintainers to get around to it (even if some are very responsive)
You aren't, either download the statically linked compiled version from their site and extract and use, or better option get the source, extract, ./configure make THEN simply use.
Along with the above, I shouldn't be in a state where I can no longer easily install applications because I'm using a somewhat older distribution (and packages are no longer being maintained for that version)
You just lose the ability to do things as easily as yum install *package* or apt-get *package*... you still have the ability to install the newer things yourself just as you wanted in your first two points. Oh wait, doing so for each updated package you want is more of a pain.. which is why we have packages and maintainers in the first place.
- Although the option should be there, it should never, ever, ever, ever, ever, ever, ever, EVER be considered "acceptable" to expect users to compile an application to install it (and all the potential headaches of getting that to work, including hacking make files, dealing with dependencies, patching the software, actually doing C++ debugging, etc).
While I completely agree users should never have to patch software, debug etc. To claim an end user can't simply type './configure' 'make' 'make install' is insulting to their intelligence.
I could make a similar argument that windows users shouldn't have to continually click next and setup settings for their installshield apps, since that is significantly more painful and inconsistent than simply compiling a linux app.
Balloon up my applications with static libraries. Please. The trade-off in system administration headache would pay for itself 100s of times over.
Having a static library version downloadable from upstreams website is a handy thing, but to propose that every integrated repo app should use static libraries is quite frankly retarded.
Administering/installing applications on a windows system is an order of magnitude more effort than on linux as it is. Your complaint boils down to 1. it doesn't do it the (inefficient) way windows does by default. 2. I don't know how to package software for linux (This has been solved by other people)
If the people packaging the closed source app do it right, like what world of goo did, you extract a .tar.gz wherever you want and click on a program and it works.
If you are using any strange libraries include the so's with it so you give people the option of using it or the dynamically linked libs.
For regular programs, this tool is rather useless compared to somebody who packages their stuff well.
Yeah, I know that Java is GPLd now, but in the strictest sense it still isn't Free as there are other gotchas and pitfalls.
While software patents exist, there is nothing that will not have 'gotchas and pitfalls'
And... none of the above beats having a sound card with a hardware mixer
Actually, it can, the cpu can beat pci latency.
long parade of Linux sound servers never solved with any measure of stability.
Jack did, but people bitched about the extra 1% cpu usage, thus pulseaudios invention.
Are you trying to say MySQL or Postgresql are equal to Oracle in performance, reliability, or documentation?
I'm saying that oracle is becoming more and more irrelevant, as some high scale deployments of other software shows.
Some licensing schemes with oracle can wind up costing companies almost a million dollars per year. That equates to quite a few extra full time employed database administrators.. which would more than be able to make up for any perceived lack of documentation etc.
There really are very few scenarios left where you actually need oracle for your database.
Catch is microsoft have already signed an agreement not to sue open source implementations of c# and .net stuff
Why?
Because you are working with a company that would not hesitate to fuck you over the moment it was convenient or the moment you stopped paying up.
You are entitled to your masochism, but to most here working with oracle now would be akin to being a partner with microsoft of the 90's, sure, on paper you're working together.. expect to get fucked over (except with oracle they wouldn't do it technically, just 4-6 digit licensing fees you weren't expecting).
Programmers on the versions of the ARM platform without a MMU do OK today without that happening.
Name a platform that is not embedded or does not have all of the software being run on it at once from a single software developer (ds etc do this).
Even if your own code is awesome if the user is loading random shit that can write to your memory locations you're boned anyway.
The difference back then is the multiple programs were attempting to run without the OS being capable of letting them do so properly.
Oh the os would let them run, just so happens it would let them screw each other up too if one of the programs were badly written, which is impossible to save against unless you have an mmu.
Any program that causes a segfault on a modern pc would cause serious crashes in unrelated programs/the machine in general without an mmu.
Fail to see how this is a troll, aluminum was originally a brand name for a seller of aluminium. Do you call iridium iridum too?
A hardware interface can have copyright protections? this is news to me, we'll have to get on to all those people who write open source drivers without specs and tell them they can't because the hardware is copyrighted /sarcasm
Reverse engineering is legal, catch is of course almost anything can be deemed illegal when you face a company that is willing to spend billions on lawyers.
Give it time
At first we'll just start to see iMac like desktops but with restrictions and os akin to the iPad, because customers like the 'simplicity' etc.
Then their mac pro line sales will shrink, and xcode etc will be available for these new restricted desktops (which will be cheaper than their mac pro cousins) however for a significant fee.
Then once the sales of the mac pro line is more or less defunct like what these xserves are, they can discontinue them with only a few people making such a fuss.
While there are many things that could stop this, you must admit it is in apples own interest to do it, and it does make sense. You would have to pay to be able to develop for your own devices, and the resulting binaries would only work on your device unless you get it approved through the app store.
Your best bet if you don't like pulseaudio is probably to use jack instead, you can make it so that pulseaudio feeds it's streams to jack and by changing your asound.conf get alsa programs to use it too.
As a bonus you get high quality low latency audio, that doesn't die all the time like pulse and has more functionality... still think pulse should have never existed.