Not the point. The processor is not designed for that. You stuff microcode and data into it from the normal CPU and turn it loose, and it does its thing WAY faster than the normal CPU can. This thing has no disk IO and would not run well at all as a general purpose CPU. It's like trying to go grocery shopping with a Formula 1 car.
This is not a finished product by any stretch of the imagination. These are prototypes. Back in the day prototypes were wirewrapped nightmares and they cost a lot more than $1500!
And you can put a schedule to it when you make a branch from your stable code. Stop development on the release branch, fix the remaining bugs and it is very much possible to get a release out the door on schedule. The developers keep coding, relatively oblivious to the release process. My employer does it all the time.
"It's a Trojan Horse to legitimize Shuttleworth's business prospects"
I have worked for several successful software companies and this is how it works at all of them. The customer wants stable code on schedule and the release process is designed with that understanding. Developers are free to code away on their projects at whatever schedule they work at, but their code stays out of the release branch until it is ready. Welcome to the grown-up world of software development.
I cannot even parse your second point.
"Debian still releases when ready"
Debian doesn't release until GNOME, KDE, and the kernel are ready. Debian does not write these things, they gather them together and get them to work with each other. Nobody is stopping Debian from continuing to do this on whatever schedule they want. Nobody is stopping anybody, or even encouraging anybody, to slow down or change their development plans. What they are asking for is coordinated releases.
The problem is that KDE and GNOME are so big and made up of so many subprojects that there is no way to even say 'it is ready'. It is exactly as you say, projects keep rolling along.
And again I have to explain that releases do not happen from the latest branch, they happen from a stable code branch that has been through the QA process. The developers can keep coding along, but there needs to be opportunities for GNOME and KDE to scoop up all of the subprojects, smash them together and call it working. The only way they can realistically do this is if there are current releases available for all of the subprojects, and all of the subprojects can agree to adopt new things all at once.
Releases do not happen from the latest code. Releases are stable code from a stable branch. They have been through QA. This step needs to happen. The developers can keep on coding, but keep their new code out of the release branch until it is ready to go. This is not limiting at all. Read the title again: scheduled RELEASE cycles, not scheduled CODING cycles.
A distribution can choose to slow down and only come out once a year, or every 18 months. Hey, look at Debian. Personally I would like something like that for my server. Then its code would NOT be the same as everyone else's. Imagine two releases, each happening yearly, 6 months out of sync. These two releases would have almost no common code between them.
And don't forget that each distribution will patch packages for their own needs. RedHat has many many kernel patches, probably customer-specific, that most other distributions are not going to want. This is just an example, every distribution has to do SOMETHING different, or what's the point?
The problem is that Linux is not your plaything, it's what people use to run their databases and web servers on.
If you understand how software development happens among professionals, it works just like this. The customer wants a working product and he wants to know when to expect it. The customer has a schedule, too.
You can start your own project to experiment with your art, but some of us are busy making a living here.
Because APIs change and the individual pieces have to continue to work with each other despite the API changes. The only realistic way to do this is to upgrade everything all at once.
You are just a victim of a bad ISP, things are not going to change because some of us can't get enough bandwidth.
If you want stability and don't want to continually download releases, use a distribution like CentOS that has a really long release cycle.
Here's a short and sweet description of the development process: Software projects are not just 'latest'. There is a code branch for each release. At some point the people who run the project decide that the current state of the code is what will become the release, and they branch it. Development continues unabated on the 'latest' branch. Development stops and bug fixing starts on the release branch. New features in the release branch that can't be fixed by release time are thrown out (or left undocumented) and saved for the next release. Regressions of course are unacceptable and this is where the sweating and the complaining comes in, because the developers have to fix the bugs before the release date. Most real software projects of course have multiple branches for whatever reason, but you get the idea.
All they are saying is that the distributions want releases to happen at particular calendar dates. This does not restrict development in any way, if the project has decent code management and the developers show some restraint.
Developers don't like this because they are being put to schedule in a job that does not lend itself to following schedules. This is being done for the customer. Commercial software companies work in this fashion. It is a successful strategy, I have seen it employed at several companies.
This is also a really excellent sign, that the body of Linux software is mature enough that someone can make a suggestion like this and have it taken seriously.
My wife is jamming away just fine on my Fedora laptop and she is no developer. She has been a Mac user forever and she just picked up my laptop and starting using it instantly. Now she has it all tricked out the way she likes it. She actually likes it better than her Mac except for the lack of Garage Band and iTunes.
Who are you kidding? I have half a dozen random junk PCs, x86, x86_64, PPC, and Fedora installs on all of them without issue.
Anyone can fill out a bug report, even normal users. No programming skills are necessary.
Yes, yes, yes. And more too. Fedora is not for everyone and it makes no claim to that. I run Fedora on my laptop because it has better hardware support for that particular model than Ubuntu. I run it on my desktop because I need it for the software I work with. I run it on my server because all the server packages are already configured just the way I like them. I run it in general because I really like SELinux and Fedora is where SELinux development is happening.
It is not Fedora's fault that Samsung has such crappy driver support.
You never even mentioned if you tried another distribution. Did you? Did you determine whether it's a Fedora issue or a CUPS issue? Did you file bug reports?
Anyone who complains about Linux problems but does not fill out bug reports is just an asshat as far as I am concerned. You are willing to leech from the efforts of others but you are not willing to make a contribution when the opportunity is right in front of you. Blah.
This particular printer was also advertised as having OSX driver support, but the driver is not available in the US unless you lie to their web site and tell them you are from Australia. Tell Samsung to get off their butts and make sure their printers work right in Linux AND OSX.
Read the end-user agreements for your commercial software and you will see that you have no right to sue them for anything beyond the purchase price of the software.
Microsoft always reacts in the most juvenile fashion. It's almost as if Bill Gates never grew up.
Their response to every legitimate attempt by others to advance the state of the art consists of throwing rocks at it. Look at Zune and 'plays for sure'. Look at OLPC. Look at what's happening here.
How much CO2 is generated in the process of accumulating, pressurizing, and delivering it? When you have worked through all of the ripple effect, I bet they generate a pound of CO2 for each pound they sequester.
This is no different from Wile E. Coyote's electric fan-powered sailboat.
Or the ethenol believers who conveniently neglect the big fire they have to put under that still.
Yes, The box says 'game' on it. The implied guarantee of merchantability and fitness says that I can open up the box and use it as a game. If this is not true, then what I have bought is not a game and the box should not say that on it.
IF it's a game, then I should be able to play it out of the box. If it's not a game, then it is not what it says it is. Which is it?
What I am saying is that if the first sale doctrine does not apply, then the merchantability and fitness for use clause does apply. This product violates one or the other, pick one, depending on how you interpret what's going on.
This is why I say that what they are doing is unethical. They have purposely created a situation where it is not clear what the consumer's rights are.
Slashdot Mirror
Not the point. The processor is not designed for that. You stuff microcode and data into it from the normal CPU and turn it loose, and it does its thing WAY faster than the normal CPU can. This thing has no disk IO and would not run well at all as a general purpose CPU. It's like trying to go grocery shopping with a Formula 1 car.
At this stage of their development.
This is not a finished product by any stretch of the imagination. These are prototypes. Back in the day prototypes were wirewrapped nightmares and they cost a lot more than $1500!
And you can put a schedule to it when you make a branch from your stable code. Stop development on the release branch, fix the remaining bugs and it is very much possible to get a release out the door on schedule. The developers keep coding, relatively oblivious to the release process. My employer does it all the time.
"It's a Trojan Horse to legitimize Shuttleworth's business prospects"
I have worked for several successful software companies and this is how it works at all of them. The customer wants stable code on schedule and the release process is designed with that understanding. Developers are free to code away on their projects at whatever schedule they work at, but their code stays out of the release branch until it is ready. Welcome to the grown-up world of software development.
I cannot even parse your second point.
"Debian still releases when ready"
Debian doesn't release until GNOME, KDE, and the kernel are ready. Debian does not write these things, they gather them together and get them to work with each other. Nobody is stopping Debian from continuing to do this on whatever schedule they want. Nobody is stopping anybody, or even encouraging anybody, to slow down or change their development plans. What they are asking for is coordinated releases.
The problem is that KDE and GNOME are so big and made up of so many subprojects that there is no way to even say 'it is ready'. It is exactly as you say, projects keep rolling along.
And again I have to explain that releases do not happen from the latest branch, they happen from a stable code branch that has been through the QA process. The developers can keep coding along, but there needs to be opportunities for GNOME and KDE to scoop up all of the subprojects, smash them together and call it working. The only way they can realistically do this is if there are current releases available for all of the subprojects, and all of the subprojects can agree to adopt new things all at once.
Releases do not happen from the latest code. Releases are stable code from a stable branch. They have been through QA. This step needs to happen. The developers can keep on coding, but keep their new code out of the release branch until it is ready to go. This is not limiting at all. Read the title again: scheduled RELEASE cycles, not scheduled CODING cycles.
A distribution can choose to slow down and only come out once a year, or every 18 months. Hey, look at Debian. Personally I would like something like that for my server. Then its code would NOT be the same as everyone else's. Imagine two releases, each happening yearly, 6 months out of sync. These two releases would have almost no common code between them.
And don't forget that each distribution will patch packages for their own needs. RedHat has many many kernel patches, probably customer-specific, that most other distributions are not going to want. This is just an example, every distribution has to do SOMETHING different, or what's the point?
Lack of diversity doesn't have to be a problem.
The problem is that Linux is not your plaything, it's what people use to run their databases and web servers on.
If you understand how software development happens among professionals, it works just like this. The customer wants a working product and he wants to know when to expect it. The customer has a schedule, too.
You can start your own project to experiment with your art, but some of us are busy making a living here.
Because APIs change and the individual pieces have to continue to work with each other despite the API changes. The only realistic way to do this is to upgrade everything all at once.
You are just a victim of a bad ISP, things are not going to change because some of us can't get enough bandwidth.
If you want stability and don't want to continually download releases, use a distribution like CentOS that has a really long release cycle.
Here's a short and sweet description of the development process: Software projects are not just 'latest'. There is a code branch for each release. At some point the people who run the project decide that the current state of the code is what will become the release, and they branch it. Development continues unabated on the 'latest' branch. Development stops and bug fixing starts on the release branch. New features in the release branch that can't be fixed by release time are thrown out (or left undocumented) and saved for the next release. Regressions of course are unacceptable and this is where the sweating and the complaining comes in, because the developers have to fix the bugs before the release date. Most real software projects of course have multiple branches for whatever reason, but you get the idea.
All they are saying is that the distributions want releases to happen at particular calendar dates. This does not restrict development in any way, if the project has decent code management and the developers show some restraint.
Developers don't like this because they are being put to schedule in a job that does not lend itself to following schedules. This is being done for the customer. Commercial software companies work in this fashion. It is a successful strategy, I have seen it employed at several companies.
This is also a really excellent sign, that the body of Linux software is mature enough that someone can make a suggestion like this and have it taken seriously.
Sorry, can't help you. I only buy real drives now.
I haven't had to recompile a kernel in years! What is your problem?
Well, the alternative is to make everyone march to some sort of schedule, which not even Microsoft can do.
The idea of Fedora is to push things along. If you are writing software or need the new features, yay!
If you are more happy with stability, CentOS is what you are looking for. Same stuff, but older and more stable.
My wife is jamming away just fine on my Fedora laptop and she is no developer. She has been a Mac user forever and she just picked up my laptop and starting using it instantly. Now she has it all tricked out the way she likes it. She actually likes it better than her Mac except for the lack of Garage Band and iTunes.
Who are you kidding? I have half a dozen random junk PCs, x86, x86_64, PPC, and Fedora installs on all of them without issue.
Anyone can fill out a bug report, even normal users. No programming skills are necessary.
Yes, yes, yes. And more too. Fedora is not for everyone and it makes no claim to that. I run Fedora on my laptop because it has better hardware support for that particular model than Ubuntu. I run it on my desktop because I need it for the software I work with. I run it on my server because all the server packages are already configured just the way I like them. I run it in general because I really like SELinux and Fedora is where SELinux development is happening.
Look at what Perot got for selling EDS to GM, and look at whet GM is getting for selling EDS to HP. Adjust for inflation and EDS is worth less now.
It is not Fedora's fault that Samsung has such crappy driver support.
You never even mentioned if you tried another distribution. Did you? Did you determine whether it's a Fedora issue or a CUPS issue? Did you file bug reports?
Anyone who complains about Linux problems but does not fill out bug reports is just an asshat as far as I am concerned. You are willing to leech from the efforts of others but you are not willing to make a contribution when the opportunity is right in front of you. Blah.
This particular printer was also advertised as having OSX driver support, but the driver is not available in the US unless you lie to their web site and tell them you are from Australia. Tell Samsung to get off their butts and make sure their printers work right in Linux AND OSX.
Read the end-user agreements for your commercial software and you will see that you have no right to sue them for anything beyond the purchase price of the software.
Microsoft always reacts in the most juvenile fashion. It's almost as if Bill Gates never grew up.
Their response to every legitimate attempt by others to advance the state of the art consists of throwing rocks at it. Look at Zune and 'plays for sure'. Look at OLPC. Look at what's happening here.
Spoiled brats.
Isn't that a Windows thing? There is no other mention of Windows in the article.
When we have a global Internet and free wireless.
See how long you can get by without gcc. Even the iPhone relies on gcc.
Tell me about how all thos iPhone apps are infected.
How much CO2 is generated in the process of accumulating, pressurizing, and delivering it? When you have worked through all of the ripple effect, I bet they generate a pound of CO2 for each pound they sequester.
This is no different from Wile E. Coyote's electric fan-powered sailboat.
Or the ethenol believers who conveniently neglect the big fire they have to put under that still.
But it doesn't say software product on the box. It says 'game'.
You can't put charcoal in a box and sell it as diamonds with a disclaimer, 'apply pressure before use'.
Yes, The box says 'game' on it. The implied guarantee of merchantability and fitness says that I can open up the box and use it as a game. If this is not true, then what I have bought is not a game and the box should not say that on it.
IF it's a game, then I should be able to play it out of the box. If it's not a game, then it is not what it says it is. Which is it?
What I am saying is that if the first sale doctrine does not apply, then the merchantability and fitness for use clause does apply. This product violates one or the other, pick one, depending on how you interpret what's going on.
This is why I say that what they are doing is unethical. They have purposely created a situation where it is not clear what the consumer's rights are.