I'm running firefox 3.6.12 myself, and found it hilarious that it wasn't getting full frames.
When a 12mhz 386 can do fullspeed and it takes up to 5% on a recent machine, something is still deeply wrong.
Yes just in time compilers are becoming better, but it can't really be argued there will never be any overhead involved, even if most of the overhead is in the initial compilation at startup.
Because everything on the web yields such high performance.
I could emulate that on a 386 full speed, that it lags on a modern quad core machine is ridiculous. While I'm sure it might be able to run full speed on chrome or maybe ff4 beta, check the cpu usage, it would still be ridiculously high compared to a native executable.
It is what all the announcements seem to imply... rather stupid I think. But I guess implying that is easier than trying to explain it's actual goals which can be read on the projects main page.
How much coverage would federal buildings really provide, and how much EDGE/3G/4G traffic would be relieved in reality?
Data costs over 3g are outrageous, the only things with higher data costs are satellite and SMS. After the initial hardware expendature having faster more reliable internet/lan access is a good thing.
I'm sorry, but aren't we in the opening stages of one of the largest know breaches of confidential government documents? How dull do you have to be to make it easier for this to happen again? That doesn't speak to the current state of ease with which such a breach could happen, but only that with a public wifi hotspot in easy reach, you suddenly have an external network in range.
Secret documents aren't accessible to public networks nor this network. Any such classified information is generally only accessible via computers that are designated for access to such materials and have much higher security requirements than regular machines.
Nothing will stop a breech of protocols, if you get enough people/supervisors/etc to break the rules of what secret/top secret etc clearance entails it will be leaked. Saying 'we should not provide good net connectivity because it will allow people to transmit secret things easier' is idiotic, if they had the means to breach the security protocols and wanted to they were going to anyway.
"Orders are orders" is never a proper excuse. And when the government who purpetrated the evils denies that they are evil or that it even happened, do you really expect them to try their own men?
If the US weren't trying to cover it up and ignore it, it wouldn't be so much a problem.
With the exception of synth programs (which I think is fair because if you are using a synth you should know what you want to connect it to.. not necessarily speaker output) everything I use with jack automatically connects itself to the speaker output so no configuration is necessary.
If you mean configuration of the jack server, it ships with sane defaults and unless you want specific properties of your audio server you can just hit 'start' in qjackctl (or not even that if you have it setup to start by default).
So please, what are these configuration issues you speak of?
The point is even with wayland you would still need something for a drawing api etc.
Essentially wayland will not solve the problems you encounter, since those can still be caused by whatever is doing the drawing, it just shifts the blame to elsewhere.
I still welcome it for a possible cleaner separation of duties (and X drivers having to do slightly less) but it will not solve any of the problems people in here think it will. As said it is not a replacement for X, it does not have that kind of scope.
Thing is OSS still doesn't provide the functionality jack does, so why have pro audio apps with jack and other apps with another when it can all function under one system?
As a side note, use more paragraph tags, makes comments more readable
you're using pulse and ALSA with hardware where the ALSA mixer is broken, and some applications aren't configured to talk to pulse, then you're going to end up with blocking issues or worse.
You shouldn't get blocking, pulse should be intercepting the alsa calls and having it go through pulse anyway through the alsa sink. The sink isn't perfect but for non-realtime apps (what most people use) it should function a treat.
As mentioned, until your needs exceed pulses capabilities there is nothing wrong with using it (subjective questionable stability aside).
But it is far easier to skip that whole mess and just use jack from the start.
For instance in audio production you would have to be insane to even consider pulseaudio as remotely usable. Jack suits this purpose fine and dandy, but it can obviously handle little games and other such items.
If pulse is only usable for a small subset of uses, but jack is usable for everything, and jack predates pulse, is far more stable etc, this brings up the question why does pulse even exist? (with the answer being the fraction of a percent cpu business).
Latency becomes a serious issue when doing anything timing sensitive. Jack has sample level synchronisation and uses a callback interface.
The system you mention would have no problems running jack and as mentioned the cpu overhead is minimal, we are literally talking fractions of a percent of difference. If that has an effect on your system you have larger problems.
As for transferring over the network netjack can do this although you will obviously get a few more milliseconds latency over a lan (8msec latency would still be fine and far less than pulse, hell even 16msec would run rings around it).
In modern times there really is no reason to run either pulse or oss, except for the fact it's what your distro comes with and thus path of least resistance so long as you don't try to do anything remotely demanding.
Besides the totally shit nature of the configuration tools, I mean.
qjackctl can hardly be called hard to use. it gives sane defaults and if you want to configure it you can, by default all you have to do is click 'start'.
With the exception of pro audio apps such as synths where it shouldn't be assumed you want it output to speakers, programs using jack automatically connect themselves to the system out without any configuration.
why is JACK so rarely supported?
Everything I'm running on my main machine right now uses jack, pulseaudio isn't even installed, yes this even includes the proprietary adobe flash plugin. All kde related notifications etc are using jack natively, mplayer, and so on.
Anything that doesn't use jack and tries to use alsa (i.e. adobe plugin) uses the alsa jack device.
So why don't we all just use JACK?
Because that would make sense, oh and it would consume a portion of a percent extra cpu time because of the more consistent cpu wakeups because of the smaller buffers and lower latency.
I am not kidding you, pulse audio devs think a fraction of a precent of cpu usage is worth dragging everyone through this bollocks with pulse. Oh, and that multiple seconds of latency can be a good thing.
But what average Joes WILL notice is the way X can shit itself and die hard if you have a half dozen apps on and then launch something heavy like a video.
My main linux machine gets rebooted every few months and I on average have *counts* 18 types of gui apps running at once, with 3-6 instances of certain ones without issue. Have run this way for years because I'm lazy and love to just leave everything open (run a heap of daemons too).
Now if they will only fork the kernel away from Linus who STILL refuses to have a stable hardware ABI even though OSX, Windows, BSD, Solaris, etc has had one for fricking ages which makes them a hell of a lot nicer, then we may actually have that third way.
Not this again. The reason we have no stable ABI, is because it is a FUCKING BAD idea. Besides, if you want a stable abi pick a kernel release and stick with it. There, stable ABI.
You know you are talking about the linux kernel INTERNAL interfaces yes? to keep them stable would basically require development on the kernel to stop. You are free to pick a version and stick with it like what happens in windows land to get a stable ABI.
Technically binary kernel drivers are derivative works of the kernel anyway, thusly should be under the gpl. Yes when the api changes old open source drivers released by vendors break, but that is entirely why they are encouraged to get them into mainline in the first place. Because it is the proper way to do it, and it then becomes supported forever after.
Basically from a development standpoint (and end-user, because who wants broken drivers) binary only kernel modules are retarded. There is no real way to bugfix if there is something wrong with them, they will eventually be deprecated anyway (can't use xp drivers with vista for example) and so on.
Having to give away lifetime free support (because home users will NOT by extended contracts, see the hatred of Best Buy as an example) because every time Linus futzes with the kernel shit breaks all over the place really keeps the smaller shops like mine away from Linux.
The answer is simple, set it all up for them once so it all works and get them to not update the kernel... you wouldn't expect an end user to upgrade from xp to vista without bitching about shit not working would you? so why let them upgrade kernel?
I personally would love it if Shuttleworth does for Linux what Steve Jobs did for Apple, and bring Linux out of the server room into the mainstream.
Apple has NEVER been big in the server room. It has always been in the mainstay of the creative industries.
Every time I've seen someone ask the Wayland devs how they plan to support remote rendering, their response seems to be 'we don't. go away'.
And they are right, because what they are making is NOT an X replacement, it's more a layer beneath X, for the forseeable future most people will still be running X on top of wayland, because wayland does not provide it's own drawing api and other such things.
Fedora? The base OS for RHEL server systems? Is going to dump X so server admins will no longer be able to run graphical admin programs remotely from their servers to their desktop without using some horrific kludge like VNC?
The big mistake here is assuming adopting wayland means dropping X. Wayland can function as a kind of 'screen' program for the multiplexing of display devices. So you can in fact run multiple X servers easily. Why nobody understands this is beyond me.
As a fellow long time fedora user I can concur with most of your points, except on the pulseaudio horror stories.
After having significant issues with audio bits I went solely to jack (because of limitations with pulseaudio before that I had to disable pulse and enable jack for specific tasks), and have not been happier.
After reading this it is easy to see just how flawed the design of pulse is in comparison.When pulseaudio can have up to two seconds (!) of buffer and still create static, there are DEEP issues.
If you have fewer problems with Fedora and find it easier to use (as in less hassle to set things up) then you and I have very different concepts of usability.
As more of a developer type I do find fedora easier to setup, using the fedora dvd image I can wind up out of the box with a system with 98% of what i need (which varies significantly). Ubuntu I have to hunt down the dvd image and even when I get it it does not include many of the various things I need and wind up having to apt-get them afterwards.
The only thing ubuntu has going for it even now is including flash and proprietary codecs.. that really is it.
Problem is there were better solutions that were far better tested than pulseaudio was (and still is) namely jack (which all remotely serious audio applications use in linux btw).
So now we have this divide where anyone who cares about audio uses jack, and all the distros bundle pulseaudio by default... lovely.
I've never had more than a minor problem with pulseaudio. I've got a friend who looks up to me technically actually using it on the network without latency issues. I just don't know what all the fuss is about:D
Gigantic buffers (latency), no decent (compared to jack) method of audio routing. No central SMPTE codes... the list goes on.
Even with regular audio playback with it's giant buffers it can at times cause static noise depending on your uses. Which is just plain idiotic.
You could still keep pulseaudio and just use it in any cases where you can't talk to OSS directly, because OSS has a mixer that actually works... unlike ALSA.
Alsa is perfect when used as a hardware interface for something like jack. Ideally the kernel should just provide an interface to deal with hardware and this is what alsa does. Jack/pulse/etc can then mix etc and provide audio routing and the like.
Recommend looking into jack, it is the only decent sound implementation out there for linux, it's lack of adoption over pulseaudio boils down to pulseaudio wanting craploads of latency to lower cpu usage where jack does not.
Anything remotely serious with audio on linux uses jack by default.
Recommended read. And that is from a primary pulseaudio developer. It goes on about all the design 'features' (flaws) that make it so damn lovely.
In essence we sacrificed stable, awesome low latency audio for fractions of a percent of cpu usage. Now anyone who does anything demanding with audio uses jack (I use it on all machines even if they just watch youtube vids) and all the stock distros distribute pulse.
PulseAudio should have never been invented, and it still doesn't have proper transport and SMPTE controls like jack (because it would fail horrendously with their as much lag as possible without getting noticed model)
ALSA functions well as what it is designed to more or less be, a hardware driver interface. Let Jack take over for mixing and routing and you are fine and dandy. Having low latency, synchronized audio with minimal cpu usage like Jack is a _good_ thing, not bad.
Wayland is not replacing all of X, it has nowhere near the scope X has. Essentially wayland is going to act like a version of 'screen' for the framebuffer. It doesn't draw or do anything.
The ability to have multiple X servers running on a single card is nice, and thusly why wayland should be tested and included. But getting rid of X is not on the cards for quite some time.
The basics of drawing have not changed in the last 20 years, only the hardware has, so why should the X protocol be dropped when it is still useful? Sure the implementation of X changes as the hardware does to suit the hardware better. But I fail to see any fundamental flaws with X that would require it's removal. Can you point to any?
But what average Joes WILL notice is the way X can shit itself and die hard if you have a half dozen apps on and then launch something heavy like a video.
My main linux machine gets rebooted every few months and I on average have *counts* 18 types of gui apps running at once, with 3-6 instances of certain ones without issue. Have run this way for years because I'm lazy and love to just leave everything open (run a heap of daemons too).
Now if they will only fork the kernel away from Linus who STILL refuses to have a stable hardware ABI even though OSX, Windows, BSD, Solaris, etc has had one for fricking ages which makes them a hell of a lot nicer, then we may actually have that third way.
Not this again. The reason we have no stable ABI, is because it is a FUCKING BAD idea. Besides, if you want a stable abi pick a kernel release and stick with it. There, stable ABI.
You know you are talking about the linux kernel INTERNAL interfaces yes? to keep them stable would basically require development on the kernel to stop. You are free to pick a version and stick with it like what happens in windows land to get a stable ABI.
Technically binary kernel drivers are derivative works of the kernel anyway, thusly should be under the gpl. Yes when the api changes old open source drivers released by vendors break, but that is entirely why they are encouraged to get them into mainline in the first place. Because it is the proper way to do it, and it then becomes supported forever after.
Basically from a development standpoint binary only kernel modules are retarded. There is no real way to bugfix if there is something wrong with them, they will eventually be deprecated anyway (can't use xp drivers with vista for example) and so on.
Having to give away lifetime free support (because home users will NOT by extended contracts, see the hatred of Best Buy as an example) because every time Linus futzes with the kernel shit breaks all over the place really keeps the smaller shops like mine away from Linux.
The answer is simple, set it all up for them once so it all works and get them to not update the kernel... you wouldn't expect an end user to upgrade from xp to vista without bitching about shit not working would you? so why let them upgrade kernel?
I personally would love it if Shuttleworth does for Linux what Steve Jobs did for Apple, and bring Linux out of the server room into the mainstream.
Apple has NEVER been in the server room. It has always been in the mainstay of the creative industries.
Slashdot Mirror
I'm running firefox 3.6.12 myself, and found it hilarious that it wasn't getting full frames.
When a 12mhz 386 can do fullspeed and it takes up to 5% on a recent machine, something is still deeply wrong.
Yes just in time compilers are becoming better, but it can't really be argued there will never be any overhead involved, even if most of the overhead is in the initial compilation at startup.
Because everything on the web yields such high performance.
I could emulate that on a 386 full speed, that it lags on a modern quad core machine is ridiculous. While I'm sure it might be able to run full speed on chrome or maybe ff4 beta, check the cpu usage, it would still be ridiculously high compared to a native executable.
It is what all the announcements seem to imply... rather stupid I think. But I guess implying that is easier than trying to explain it's actual goals which can be read on the projects main page.
How much coverage would federal buildings really provide, and how much EDGE/3G/4G traffic would be relieved in reality?
Data costs over 3g are outrageous, the only things with higher data costs are satellite and SMS. After the initial hardware expendature having faster more reliable internet/lan access is a good thing.
I'm sorry, but aren't we in the opening stages of one of the largest know breaches of confidential government documents? How dull do you have to be to make it easier for this to happen again? That doesn't speak to the current state of ease with which such a breach could happen, but only that with a public wifi hotspot in easy reach, you suddenly have an external network in range.
Secret documents aren't accessible to public networks nor this network. Any such classified information is generally only accessible via computers that are designated for access to such materials and have much higher security requirements than regular machines.
Nothing will stop a breech of protocols, if you get enough people/supervisors/etc to break the rules of what secret/top secret etc clearance entails it will be leaked. Saying 'we should not provide good net connectivity because it will allow people to transmit secret things easier' is idiotic, if they had the means to breach the security protocols and wanted to they were going to anyway.
"Orders are orders" is never a proper excuse. And when the government who purpetrated the evils denies that they are evil or that it even happened, do you really expect them to try their own men?
If the US weren't trying to cover it up and ignore it, it wouldn't be so much a problem.
With the exception of synth programs (which I think is fair because if you are using a synth you should know what you want to connect it to.. not necessarily speaker output) everything I use with jack automatically connects itself to the speaker output so no configuration is necessary.
If you mean configuration of the jack server, it ships with sane defaults and unless you want specific properties of your audio server you can just hit 'start' in qjackctl (or not even that if you have it setup to start by default).
So please, what are these configuration issues you speak of?
The point is even with wayland you would still need something for a drawing api etc.
Essentially wayland will not solve the problems you encounter, since those can still be caused by whatever is doing the drawing, it just shifts the blame to elsewhere.
I still welcome it for a possible cleaner separation of duties (and X drivers having to do slightly less) but it will not solve any of the problems people in here think it will. As said it is not a replacement for X, it does not have that kind of scope.
just make the key the md5sum or sha1sum or whatever of whichever bitlength you need of a common passphrase you will always remember.
You lose it you can recreate what it was on a new machine with common checksum tools.
Thing is OSS still doesn't provide the functionality jack does, so why have pro audio apps with jack and other apps with another when it can all function under one system?
As a side note, use more paragraph tags, makes comments more readable
you're using pulse and ALSA with hardware where the ALSA mixer is broken, and some applications aren't configured to talk to pulse, then you're going to end up with blocking issues or worse.
You shouldn't get blocking, pulse should be intercepting the alsa calls and having it go through pulse anyway through the alsa sink. The sink isn't perfect but for non-realtime apps (what most people use) it should function a treat.
As mentioned, until your needs exceed pulses capabilities there is nothing wrong with using it (subjective questionable stability aside).
But it is far easier to skip that whole mess and just use jack from the start.
For instance in audio production you would have to be insane to even consider pulseaudio as remotely usable. Jack suits this purpose fine and dandy, but it can obviously handle little games and other such items.
If pulse is only usable for a small subset of uses, but jack is usable for everything, and jack predates pulse, is far more stable etc, this brings up the question why does pulse even exist? (with the answer being the fraction of a percent cpu business).
Latency becomes a serious issue when doing anything timing sensitive. Jack has sample level synchronisation and uses a callback interface.
The system you mention would have no problems running jack and as mentioned the cpu overhead is minimal, we are literally talking fractions of a percent of difference. If that has an effect on your system you have larger problems.
As for transferring over the network netjack can do this although you will obviously get a few more milliseconds latency over a lan (8msec latency would still be fine and far less than pulse, hell even 16msec would run rings around it).
In modern times there really is no reason to run either pulse or oss, except for the fact it's what your distro comes with and thus path of least resistance so long as you don't try to do anything remotely demanding.
Besides the totally shit nature of the configuration tools, I mean.
qjackctl can hardly be called hard to use. it gives sane defaults and if you want to configure it you can, by default all you have to do is click 'start'.
With the exception of pro audio apps such as synths where it shouldn't be assumed you want it output to speakers, programs using jack automatically connect themselves to the system out without any configuration.
why is JACK so rarely supported?
Everything I'm running on my main machine right now uses jack, pulseaudio isn't even installed, yes this even includes the proprietary adobe flash plugin. All kde related notifications etc are using jack natively, mplayer, and so on.
Anything that doesn't use jack and tries to use alsa (i.e. adobe plugin) uses the alsa jack device.
So why don't we all just use JACK?
Because that would make sense, oh and it would consume a portion of a percent extra cpu time because of the more consistent cpu wakeups because of the smaller buffers and lower latency.
I am not kidding you, pulse audio devs think a fraction of a precent of cpu usage is worth dragging everyone through this bollocks with pulse. Oh, and that multiple seconds of latency can be a good thing.
But what average Joes WILL notice is the way X can shit itself and die hard if you have a half dozen apps on and then launch something heavy like a video.
My main linux machine gets rebooted every few months and I on average have *counts* 18 types of gui apps running at once, with 3-6 instances of certain ones without issue. Have run this way for years because I'm lazy and love to just leave everything open (run a heap of daemons too).
Now if they will only fork the kernel away from Linus who STILL refuses to have a stable hardware ABI even though OSX, Windows, BSD, Solaris, etc has had one for fricking ages which makes them a hell of a lot nicer, then we may actually have that third way.
Not this again. The reason we have no stable ABI, is because it is a FUCKING BAD idea. Besides, if you want a stable abi pick a kernel release and stick with it. There, stable ABI.
You know you are talking about the linux kernel INTERNAL interfaces yes? to keep them stable would basically require development on the kernel to stop. You are free to pick a version and stick with it like what happens in windows land to get a stable ABI.
Technically binary kernel drivers are derivative works of the kernel anyway, thusly should be under the gpl. Yes when the api changes old open source drivers released by vendors break, but that is entirely why they are encouraged to get them into mainline in the first place. Because it is the proper way to do it, and it then becomes supported forever after.
Basically from a development standpoint (and end-user, because who wants broken drivers) binary only kernel modules are retarded. There is no real way to bugfix if there is something wrong with them, they will eventually be deprecated anyway (can't use xp drivers with vista for example) and so on.
Having to give away lifetime free support (because home users will NOT by extended contracts, see the hatred of Best Buy as an example) because every time Linus futzes with the kernel shit breaks all over the place really keeps the smaller shops like mine away from Linux.
The answer is simple, set it all up for them once so it all works and get them to not update the kernel... you wouldn't expect an end user to upgrade from xp to vista without bitching about shit not working would you? so why let them upgrade kernel?
I personally would love it if Shuttleworth does for Linux what Steve Jobs did for Apple, and bring Linux out of the server room into the mainstream.
Apple has NEVER been big in the server room. It has always been in the mainstay of the creative industries.
hmm... appears I hit reply to the wrong person, my mistake.
Every time I've seen someone ask the Wayland devs how they plan to support remote rendering, their response seems to be 'we don't. go away'.
And they are right, because what they are making is NOT an X replacement, it's more a layer beneath X, for the forseeable future most people will still be running X on top of wayland, because wayland does not provide it's own drawing api and other such things.
Fedora? The base OS for RHEL server systems? Is going to dump X so server admins will no longer be able to run graphical admin programs remotely from their servers to their desktop without using some horrific kludge like VNC?
The big mistake here is assuming adopting wayland means dropping X. Wayland can function as a kind of 'screen' program for the multiplexing of display devices. So you can in fact run multiple X servers easily. Why nobody understands this is beyond me.
It's just another layer beneath X.
Replacing X is not a bad goal
This is not replacing X, it does not provide 1/10th of the functionality X does and it readily admits it.
Wayland is more like another abstraction layer that goes beneath X in a sense.
As a fellow long time fedora user I can concur with most of your points, except on the pulseaudio horror stories.
After having significant issues with audio bits I went solely to jack (because of limitations with pulseaudio before that I had to disable pulse and enable jack for specific tasks), and have not been happier.
After reading this it is easy to see just how flawed the design of pulse is in comparison.When pulseaudio can have up to two seconds (!) of buffer and still create static, there are DEEP issues.
If you have fewer problems with Fedora and find it easier to use (as in less hassle to set things up) then you and I have very different concepts of usability.
As more of a developer type I do find fedora easier to setup, using the fedora dvd image I can wind up out of the box with a system with 98% of what i need (which varies significantly). Ubuntu I have to hunt down the dvd image and even when I get it it does not include many of the various things I need and wind up having to apt-get them afterwards.
The only thing ubuntu has going for it even now is including flash and proprietary codecs.. that really is it.
Problem is there were better solutions that were far better tested than pulseaudio was (and still is) namely jack (which all remotely serious audio applications use in linux btw).
So now we have this divide where anyone who cares about audio uses jack, and all the distros bundle pulseaudio by default... lovely.
I've never had more than a minor problem with pulseaudio. I've got a friend who looks up to me technically actually using it on the network without latency issues. I just don't know what all the fuss is about :D
Gigantic buffers (latency), no decent (compared to jack) method of audio routing. No central SMPTE codes... the list goes on.
Even with regular audio playback with it's giant buffers it can at times cause static noise depending on your uses. Which is just plain idiotic.
You could still keep pulseaudio and just use it in any cases where you can't talk to OSS directly, because OSS has a mixer that actually works... unlike ALSA.
Alsa is perfect when used as a hardware interface for something like jack. Ideally the kernel should just provide an interface to deal with hardware and this is what alsa does. Jack/pulse/etc can then mix etc and provide audio routing and the like.
Recommend looking into jack, it is the only decent sound implementation out there for linux, it's lack of adoption over pulseaudio boils down to pulseaudio wanting craploads of latency to lower cpu usage where jack does not.
Anything remotely serious with audio on linux uses jack by default.
Recommended read. And that is from a primary pulseaudio developer. It goes on about all the design 'features' (flaws) that make it so damn lovely.
In essence we sacrificed stable, awesome low latency audio for fractions of a percent of cpu usage. Now anyone who does anything demanding with audio uses jack (I use it on all machines even if they just watch youtube vids) and all the stock distros distribute pulse.
PulseAudio should have never been invented, and it still doesn't have proper transport and SMPTE controls like jack (because it would fail horrendously with their as much lag as possible without getting noticed model)
ALSA functions well as what it is designed to more or less be, a hardware driver interface. Let Jack take over for mixing and routing and you are fine and dandy. Having low latency, synchronized audio with minimal cpu usage like Jack is a _good_ thing, not bad.
Wayland is not replacing all of X, it has nowhere near the scope X has. Essentially wayland is going to act like a version of 'screen' for the framebuffer. It doesn't draw or do anything.
The ability to have multiple X servers running on a single card is nice, and thusly why wayland should be tested and included. But getting rid of X is not on the cards for quite some time.
The basics of drawing have not changed in the last 20 years, only the hardware has, so why should the X protocol be dropped when it is still useful? Sure the implementation of X changes as the hardware does to suit the hardware better. But I fail to see any fundamental flaws with X that would require it's removal. Can you point to any?
But what average Joes WILL notice is the way X can shit itself and die hard if you have a half dozen apps on and then launch something heavy like a video.
My main linux machine gets rebooted every few months and I on average have *counts* 18 types of gui apps running at once, with 3-6 instances of certain ones without issue. Have run this way for years because I'm lazy and love to just leave everything open (run a heap of daemons too).
Now if they will only fork the kernel away from Linus who STILL refuses to have a stable hardware ABI even though OSX, Windows, BSD, Solaris, etc has had one for fricking ages which makes them a hell of a lot nicer, then we may actually have that third way.
Not this again. The reason we have no stable ABI, is because it is a FUCKING BAD idea. Besides, if you want a stable abi pick a kernel release and stick with it. There, stable ABI.
You know you are talking about the linux kernel INTERNAL interfaces yes? to keep them stable would basically require development on the kernel to stop. You are free to pick a version and stick with it like what happens in windows land to get a stable ABI.
Technically binary kernel drivers are derivative works of the kernel anyway, thusly should be under the gpl. Yes when the api changes old open source drivers released by vendors break, but that is entirely why they are encouraged to get them into mainline in the first place. Because it is the proper way to do it, and it then becomes supported forever after.
Basically from a development standpoint binary only kernel modules are retarded. There is no real way to bugfix if there is something wrong with them, they will eventually be deprecated anyway (can't use xp drivers with vista for example) and so on.
Having to give away lifetime free support (because home users will NOT by extended contracts, see the hatred of Best Buy as an example) because every time Linus futzes with the kernel shit breaks all over the place really keeps the smaller shops like mine away from Linux.
The answer is simple, set it all up for them once so it all works and get them to not update the kernel... you wouldn't expect an end user to upgrade from xp to vista without bitching about shit not working would you? so why let them upgrade kernel?
I personally would love it if Shuttleworth does for Linux what Steve Jobs did for Apple, and bring Linux out of the server room into the mainstream.
Apple has NEVER been in the server room. It has always been in the mainstay of the creative industries.