So let me get this straight: Apple spends several years carefully building an ecosystem for it's hardware and software, and it is nice enought to give away aan excellent free program specifically to gain market share and to leverage hardware sales. It is a closed ecosystem, which is what you pay for being able to use a nice free state-of-the-art music management program.
Enter Pre, a direct competitor of Apple in one of the most strategic lines of Apple's business. How do you think Apple should react when Pre starts (ab)using iTunes, thus gaining more ground and cannibalizing iPhone/iPod in process? I'm surprised they were nice enough to let it stay for a while instead of forcing a mandatory update down everyone's throat and making an incompatible change to the iTunes Store protocol (which would be justified given the shamelessness of Pre strategy).
Maybe Palm should consider making it's own compelling software instead of weaseling it's way through and piggybacking the success of Apple. Or, as a more open (yet inferior) alternative, use Microsoft Media Player as it's music software
Taking a casual look at screenshots immediately reveals icons "borrowed" from KDE. Hmm... I don't think those were in public domain. Gods of GPL won't be pleased with it, for sure. With this attitude, I wonder if the entire OS is truly written from scratch and not a single file from any other project covered by GPL was "incorporated." Because if it was, that would be a shame. And it would create significant issues for the SkyOS developers if they try to sell the product.
As for the viability of the project (assuming that it's legally clean) - no, it is not viable. As simple as that. ISVs will not develop software for it and people are confused enough with Windows vs OS X vs Linux - the market is saturated. I'm sure SkyOS will have it's share of dedicated followers and users (all 23 of them) but that's pretty much it's niche.
I am not sure about the motives of this move. Several explanations come to mind.
Pure FUD. This is a plausible one. Sun has a lot to lose with Linux success. Linux has always been a competition to Solaris and this is not going to change. Leave "Let's be friends - there is place for everyone." rhethoric for glossy corporate press releases. As long as Sun cares about Solaris it will fight tooth and nail against Linux. becaus if Linux wins, Sun will be reduced to a vendor of exotic albeit powerful and very expensive hardware running a commodity OS on it. And this is not a good position to be in, now that Intel/AMD platform is becoming cheaper and more powerful every day.
Change in strategy with Schwartz steering the company. It is unlikely, but still possible that Sun will try to get out of the OS business altogether. But as I said, it is very unlikely - someone will have to do a lot of explaining to the customers, why Linux, so much maligned by the Company, suddenly became the top choice despite all the hype around Solaris (OTOH, seeing the sheer number of people that drank Apple's Cool-Aid during both PowerPC heyday and during the recent migration to Intel platform, one learns to no be surprized by anything). And someone would have to convince customers to buy an expesive piece of hardware running Linux from Sun, not from Dell...
Finally, and this is the most possible case, the Comany continues to do what it's been doing the best for about 6 years - running around like a chicken with head chopped off. The company is losing ground and has no strategic direction whatsoever. This might be yet another testament to the "we are clueless and will become irrelevant soon" motto.
So much for sensationalism ("Boo hoo! Vista will ship with firewall turned [partially] OFF") At this point, some news sources really love to grab any single rumor about Vista and turn it into big news.
On a technical side however, I don't see why this is a yes-or-no proposition. What would prevent the installer to ask a question like: "Do you want the firewall to block outgoing traffic? Yes/No" (with some blurb explaining to non-geeks why they might/might not need it, what implications it might have, and how to change one's decision later on).
Whoa! From level 3 straight down to Troll just because I didn't drink the Palm CoolAid. I'm becoming a Slashdotter, I guess...:-)
Steve, just promise me you won't break any chairs of fucking kill anyone when your little wet dream does not work any better than Xbox or tablet PCs.
Facing such an impeccable logic, I cannot really argue. You won.
PDA sales are in the dirt right now. I suspect it has something to do with a planned lack of choices outside expensive but underperforming WinCE machines and constantly breaking Windoze syncs. Those losers can't even get handwriting recognition right. Saying that Windoze mobile has won in a market like that is not saying much. They might have "won" but they did it by killing the market and it's not going to get any better till choice comes back.
You are wrong (IMHO). "Expensive?" Wrong! You cannot find something in sub-$100 tier but there are plenty in the $100-$250 one. Which is not really expensive. This is not a gadget one buys every month or every year. "Underperforming?" Wrong again! Unless you belong to the elite group of people who run Monte-Carlo simulations on PDAs, the hardware performance is just right. One probably needs only one 10th of it to read e-mail and run Contacts/Calendar. Maybe even less. For God's sake, my Axim x50v is not less powerful than a top-of-the-line 486-33 workstation, I used to work on in 1994.
Even though I am biased here (I spend most of my time in Linux, not Windows) it is easy to see where the market goes once you stop closing your eyes and ears and chanting "losers" and "Windoze." As I said before, you can partially praise Microsoft for doing their homework and creating a highly useful product in Windows Mobile (despite arguments presented here, I am yet to observe that dreaded "instability" in my x50v and neither do I see that in PDAs of my colleagues and friends). Then, you can also thank Palm for screwing it up by letting PalmOS be stagnant for years while Microsoft was busy improving their product and winning the market share.
Oh yeah, one more reason for poor sales is good devices. I'm still happily syncing my handspring visor with Kontact and KPilot and those programs continue to improve it's capabilities. Here's three cheers for marking contact birthdays in my calendar.
That's wonderful. The only minor issue here is that 99.99% of the PDA users don't give a crap. They sync with Outlook and corporate Exchange.
That was the least coherent post I've seen in a while.
Thank you. You have a nice day too.
For the record, I don't think the 700w is a bad thing - there are people that will always use MacOS and people who will always use Windows, would it be bad for Dell to sell them both the hardware? Because that's how the PalmSource / Palm relationship is now. Palm can sell everyone the hardware now, regardless of what OS they want.
I was not talking about Palm, the hardware company. Those guys will survive - they produce very nice hardware (Treo, LifeDrive) and they do have a market niche. I was talking about Palm, the software vendor (PalmSource or whatever it is now). These guys will go.
And I'll continue to pick the PalmOS ones, because the UI is nicer (a la MacOS for desktops...)
IMHO, you will not. Here's how I see it unfolding: in about 1-2 years there will be no new PalmOS based PDAs and most probably, Treo model line-up will also convert to 'w'. LifeDrive will hold the fort for some time before dropping PalmOS as well. The great new Linux-based embedded OS to replace PalmOS will never materialize (at least not from the PalmOS vendor) and the assets will be eventually sold to someone planning to enter this market (maybe Apple). Again, this is what I think and you can actually bug me 2 years from now reminding me how wise/stupid I was.:-)
This is for all those idealists, who were saying that Treo 700w was actually a good move for PalmOS. Unfortunately it was not. Rather it was a beginning of PalmOS's end.
I say, good riddance. As much as I loved my Palm III, those days are gone and Palm has been wandering aimlessly chasing one target after another and making all kinds of ridiculous mistakes.
As much as I disagree, the market has chosen features over minimalism (it always does, BTW). No matter how ridiculous it is to watch movies on a 4" screen, this is what consumers want and Microsoft answered a call while Palm actually tried to tell consumers that they actually would not want to do that.
Overall it's a damn shame. Palm was a good (not great) platform and it could continue eating Microsoft's lunch. Instead, they literally sat and watched Microsoft learning from their mistakes and stealing their market. Just imagine the humiliation of pushing Windows Mobile on Treos!
On to Linux. I am yet to see a practical PDA running embedded Linux. No, Zaurus doesn't count - those are more like exotic geek gadgets rather than consumer devices. I would love it PalmSource actually pulled this off and managed to finally create one, but I know better. I predict that whatever_this_company_is_now_called will be off the market before the device hits the shelves. In about 1-2 years the PDA market will be 100% Windows Mobile. The battle will shift into the smartphone space with Symbian and Windows Mobile being the biggest players and everyone else feeding off the table crumbs.
Here we go again, two firms absolutely unfit to compete against Microsoft in their products' price/performance, one basically in its death throes, the other one continually losing the market to the SQL Server... What a great duo! I'm sure they will come up with a real.NET killer. At least this time (they sadly have been failing this task on several noble attempts).
Seriously, I doubt world needs yet another infrastructure (even assuming this one will be Java-based). The only thing that I see happening by this effort is further discrediting of the Java technology, which after all those years still cannot provide an enterprise infrastructure compelling to developers (the hodge-podge of Struts, Spring, JSF, etc. only makes things worse).
Last but not the least, let's go back to the basic question and ask ourselves "cui prodest?" I see what Sun has in it, yet I fail to see what benefits Oracle is supposed to realize for it. Oracle is not a player in this field. Speculation and rumors may fly high but it will be interesting to observe the real motives of Ellison in this case.
The paragraph I quoted in my first post was about price. More specifically, about the impact of non-Microsoft based solution on the product price.
They will PAY you at Walmart to take it home!
on
Google PC to Hit Walmart?
·
· Score: 2, Informative
Who needs common sense when you can ride the industry craze. A couple years ago we would hear about a Java Operating System, that would render laptops free. Today it's all Google: "The machine would run an operating system created by Google, not Microsoft's Windows, which is one reason it would be so cheap -- perhaps as little as a couple of hundred dollars."
Too bad the idiots didn't bother to check the facts: Windows OEM license is actually in the $50-$90 range. That's exactly the savings you get for not preinstalling Windows on a PC. The rest is hardware.
There is another somewhat plausible explanation of low cost however: having an Operating System so lightweight, it doesn't requires too much hardware. For a common e-mail-browser-wordprocessor-spreadsheet use case one doesn't need 1Gb or RAM. Building an OS that is oriented toward that use case should result in much lower resource requirements, making hardware cheaper.
That's exactly the point! I have not been "doing XmlHttpRequest/Ajax". I have been building interactive websites using the existing technologies (CGI/JavaScript) and they worked just fine. Of course, they didn't work exactly like desktop applications, but their behavior model was still well understood.
Aside from "reinventing the wheel" issue, it is also to bee seen yet, whether AJAX fulfills its interactivity promises without making application development unbearably complicated (it is one thing to show a "Hello, AJAX" example; an application with real-life functionality is another matter). Java has been promising similar features for years and so far its success in the field has been mediocre at best.
AJAX...helps you transform clunky Web interfaces into interactive Ajax applications.
Recalling the Simpsons: "Only suckers buy [last year's] model. You are not a sucker, are you?"
I can't wait to start padding my resume with the latest and greates technology out there that will do the same thing we've been doing for decade but with more acronyms and steeper learning curve.
I've recently been invited to Google's Orkut. Unfortunately, the registration process didn't go all that well and I ended up having the Orkut service enabled on my Google account yet being unable to log in.
I've been trying to get help from Google for two months already. So far, I only received two automated responses and nothing else. I am still unable to log onto Orkut.
My overall experience with Google is mixed: it works great when it works. When it doesn't work, it's a disaster - there is no contact phone number or e-mail address where a human being would try to fix the problem. You are basically on your own because, you know, "It's free, so no guarantees."
I hope, Google DVR if it ever gets released without their favorite 'Beta' qualifier, will have real customer support. Google so far has been in business where they provide no guarantee to anyone. They have to learn how to support their clients.
I've been using Doxygen for several years already and while it is a great tool that simplifies documentation generation a lot, the output is far from perfect by any reasonable standards:
Consider.NET Development Center. MSDN has been following this documentation presentation model for years and it proved to be quite convenient for developers. You get a hierarchical API tree on the left and documentation on the right. The documentation for API groups is clumped together with nice introductory articles etc. Unfortunately it is practically impossible to generate using Doxygen.
Doxygen is not scalable. Period. If your source base is 10 million LOC and you change one function in one tiny file, you will have to run Doxygen on your entire source base to incorporate the change.
Neither is Doxygen geared toward generating API manuals. This is actually the worst problem with the whole situation. I've seen projects, where people would generate Doxygen style API reference and call it "documentation." Well, just having a huge list of documented function is not documentation.
Having said that, I still think that Doxygen is the best automated documentation generator out there and I hope it'll answer all those issues in the future.
What I suggested is just one of the measures. I didn't mean that it should exclude jail time. On the opposite, I think that both punishments should go hand in hand.
As for the severity, taking one's license is far from being merely a slap on the wrist. If one has invested a considerable amount of time, money, and energy into developing some computer-related skill set, being banned from any computer-related job is actually an extremely severe punishment - one would have to build his career again from scratch in some completely unrelated area.
Once these measures become accepted and after a number of well-published cases, computer crime will become a domain of hardcore criminals as opposed to pimple-faced kids, having nothing else to do on rainy Sunday. And that is actually good, because it is easier to fight the criminals than the kids.
Many professions where wrongdoing is a serious offence have employed license revocation as a successful deterrent. While software development is not a licensed activity, having a similar punishment (e.g. prohibition to be employed in any computer-affiliated capacity) might be a solution for a problem. Needless to say, that this is a drsatic measure and it should be applied to serious offenses only (i.e. viruses/worms, etc.)
Am I the only one who feels, this looks like yet another OpenLinux project? Several 2nd and 3rd tier Linux distributors joining together in a futile effort to knock RedHat off it's throne...
The problem is, each distribution has its own set of goals. Or at least it better have - otherwise there is no reason for it to exist. And while there are different sets of goals, there will always be problems with maintaining a unified base.
The main problem, however, is that "enterpriseness" of the distribution is not about the choice of package format or a set of packages, or a cute name. It is about support. RHEL per se is not much different from dozens of other distributions on the market. It is the support behind it that makes it so attractive in the eyes of the IT industry. And this is really what any join effoer for another enterprise-ready distribution should be about.
It's easy to see why regressions are a big deal for businesses -- it's embarrassing to the management. Business rules need not control development processes in Free Software.
It's sad if that's the way it works for you. Regression testing is a big deal for our business not because of the management but because we want our clients to be happy. I would be awfully embarrassing for us if every software release (which we do on a weekly basis for 200,000+ clients) broke some feature that used to work before. We care about our reputation and we care about our clients, which is why we try not to break things.
It is also sad that a lot of Open Source projects reject the idea of treating themselves like a regular business in a sense that they would try to identify the client base, to cater to it and to respect it. Applying those simple rules would dramatically increase the impact of the project, broaden the audience and it would not violate the spirit of the Open Source in any fashion whatsoever.
Anyway, to close this thread (it's been way longer than what I itended), let me just say that I did not intend to start teaching the GCC developers what they should do. I just shared my views based on my experience. If it is the case that the regression testing is completely unusable for GCC than there is little use in trying to utilize it now without a rewrite. But it is obvious to me that having a decent regression testsuite for GCC would benefit everyone, developers and clients alike.
Sorry, but the above is just not convincing. I just keep sizing this to my work and my group and guess what: it doesn't fit. No matter how "oddball" is the test in the software I am responsible for, it is a test in the testsuite and the testsuite is sacrosanct - no one breaks the test suite.
Your arguments just serve as excellent exceptions proving the rule. Yes, there are cases when the bugfix is so important that it has to go in right away. However unlike your world where it would happen and then someone starts screaming bloody murder a day, or a week, or a month from now, in our case we are fully aware that the urgent fix breaks feature X before we even release the new version and the next order is to fix that feature for the follow-up release.
As for the completeness of the testsuite - you are right. Nothing is complete and features do break. However using it as an excuse to not abide by regression testing rules is akin to not trying to achieve anything just because of the possibility of failure. Try regression testing and you'll see that surprise breakages will diminish over time even if not every single case is covered. One project I used to be in charge for was a middleware request broker, routing tens of millions of messages per day with rich feature set and rather decent platform support. Since the initial release I cannot recall a single breakage for the last 15 releases.
I strongly disagree. Your scenario has inherent ambiguity embedded into it: it assumes that someone has to make a subjective decision whether feature X is more valuable than feature Y and therefore, feature X could be enhanced/fixed at the expense of feature Y being broken.
This process is subjective and the net result is the product constantly breaking things that used to work. It practically nullifies the value of regression testing. Consider the "double releases" of so many software packages, where the second release comes straight on the heels of the prior one because the first release broke things that used to work. With reasonable regression testing process such problem is minimized.
The alternative process requires more discipline. It doesn't hold new fixes "hostage" but it requires responsibility on your side to ensure that your fix doesn't break anything else that used to work. And in case it does, it puts the burden of fixing it upon you. But as a result, you avoid that vicious flipping where every new release tends to break some feature of the previous one.
In other words, something on AIX breaks, and my patch gets rejected. I don't know how to work around some sucky AIX bug, and don't have time to learn. My patch fixed a real bug, maybe even on all platforms. It gets dropped on the floor just because IBM hasn't been obliged to maintain their own damn port.
Exactly! Sorry if it sounds harsh but that's the only way to ensure non-deteriorating quality of the product. It worked before. now with your patch it doesn't - ergo, your patch broke it. You may think that your patch fixed a really important problem, but from the point of view of some guy in Romania using GCC on C64, the new version broke things. Regression testing approach eliminates the source of ambiguity about whose fix is more important and whose bug is "buggier."
Note however, that I didn't delve into the mechanics of fixing such newly introduced bugs. This is something that can be improved. For example, if you produce a fix for one bug and it breaks Ultrix, there should be some way to talk to someone involved into Ultrix port to get some help with fixing the issue. If there's no one involved, there should be at least some company sponsoring the architecture. If there's no such company, then the port should be announced as unsupported and heading toward obsoletion.
I realize that it is easier said then done but having a reasonable process to handle such issues is much better in my opinion than ad-hoc rejection of support just because the target audience is smaller compared to Linux.
So, everybody who fixes something that (incidentally) affects emission of debug annotations in Gcc has to learn all the idiot formats used in AIX, Solaris, Tru64, PE, and what-have-you just because FSF happens to have those machines?
That's what regression testing is for. It is not unreasonable for any large system to contain a constantly growing testsuite that tests core features of the system. In fact, GCC does have a testsuite, although I don't know how versatile it is. For a compiler suite a reasonable testsuite would contain programs of varying complexity in the source language as well as object files for each valid combination of optimization/feature level and a platform (not a very difficult thing to produce).
The testsuite would then handle each such program in the following manner:
Compile it using a given optimization/feature level
Perform a binary diff against the "canonical" object code. Maybe do the same thing for aseembly outputs. Fail if outputs differ.
Link a program, run it, and compare result to the expected one.
The only challenging part of this process is to "seed" the testsuite with canonical object files: someone would have to either trust a stable compiler version or to proof-read each.o/.s file. After that, all discrepancies would be considered failures by default. If the new compiler version produces different object code, it has to be either explained (and incorporated into the testsuite) or the compiler has to be fixed.
Combine the above with a distributed build system (like Tinderbox or CruiseControl) and you've got an automated regression testing system. After that, every applied patch would have to go through this ordeal to ensure that it doesn't break the compiler.
I would be great if this kind of data was utilized through a "Get the Facts" campaign to counter Microsoft claims about their superior TCO. I wonder if OpenOffice people are going to make use of it in order to promote awareness and gain even more support. If OpenOffice was a commercial product, their salespeople would already be knocking on the doors of all major education establishments with nifty handouts documenting this case study, begging the officials to give OpenOffice a try.
I am not talking about drive-by spyware installation. This is a completely different realm. It existed for a long time and that didn't prevent malicious wardriving from proliferation. It will be just the same with wireless keyboard snooping.
As we have seen in the recent years, computer criminals and indentity thieves are getting more and more organized in their attempts to steal valuable data and they try to utilize every single opportunity. Again, it is not a question for me whether wireless keyboard protocol is insecure but rather when it becomes actively exploited.
Slashdot Mirror
So let me get this straight: Apple spends several years carefully building an ecosystem for it's hardware and software, and it is nice enought to give away aan excellent free program specifically to gain market share and to leverage hardware sales. It is a closed ecosystem, which is what you pay for being able to use a nice free state-of-the-art music management program.
Enter Pre, a direct competitor of Apple in one of the most strategic lines of Apple's business. How do you think Apple should react when Pre starts (ab)using iTunes, thus gaining more ground and cannibalizing iPhone/iPod in process? I'm surprised they were nice enough to let it stay for a while instead of forcing a mandatory update down everyone's throat and making an incompatible change to the iTunes Store protocol (which would be justified given the shamelessness of Pre strategy).
Maybe Palm should consider making it's own compelling software instead of weaseling it's way through and piggybacking the success of Apple. Or, as a more open (yet inferior) alternative, use Microsoft Media Player as it's music software
As for the viability of the project (assuming that it's legally clean) - no, it is not viable. As simple as that. ISVs will not develop software for it and people are confused enough with Windows vs OS X vs Linux - the market is saturated. I'm sure SkyOS will have it's share of dedicated followers and users (all 23 of them) but that's pretty much it's niche.
On a technical side however, I don't see why this is a yes-or-no proposition. What would prevent the installer to ask a question like: "Do you want the firewall to block outgoing traffic? Yes/No" (with some blurb explaining to non-geeks why they might/might not need it, what implications it might have, and how to change one's decision later on).
Even though I am biased here (I spend most of my time in Linux, not Windows) it is easy to see where the market goes once you stop closing your eyes and ears and chanting "losers" and "Windoze." As I said before, you can partially praise Microsoft for doing their homework and creating a highly useful product in Windows Mobile (despite arguments presented here, I am yet to observe that dreaded "instability" in my x50v and neither do I see that in PDAs of my colleagues and friends). Then, you can also thank Palm for screwing it up by letting PalmOS be stagnant for years while Microsoft was busy improving their product and winning the market share.
That's wonderful. The only minor issue here is that 99.99% of the PDA users don't give a crap. They sync with Outlook and corporate Exchange.I say, good riddance. As much as I loved my Palm III, those days are gone and Palm has been wandering aimlessly chasing one target after another and making all kinds of ridiculous mistakes.
As much as I disagree, the market has chosen features over minimalism (it always does, BTW). No matter how ridiculous it is to watch movies on a 4" screen, this is what consumers want and Microsoft answered a call while Palm actually tried to tell consumers that they actually would not want to do that.
Overall it's a damn shame. Palm was a good (not great) platform and it could continue eating Microsoft's lunch. Instead, they literally sat and watched Microsoft learning from their mistakes and stealing their market. Just imagine the humiliation of pushing Windows Mobile on Treos!
On to Linux. I am yet to see a practical PDA running embedded Linux. No, Zaurus doesn't count - those are more like exotic geek gadgets rather than consumer devices. I would love it PalmSource actually pulled this off and managed to finally create one, but I know better. I predict that whatever_this_company_is_now_called will be off the market before the device hits the shelves. In about 1-2 years the PDA market will be 100% Windows Mobile. The battle will shift into the smartphone space with Symbian and Windows Mobile being the biggest players and everyone else feeding off the table crumbs.
Seriously, I doubt world needs yet another infrastructure (even assuming this one will be Java-based). The only thing that I see happening by this effort is further discrediting of the Java technology, which after all those years still cannot provide an enterprise infrastructure compelling to developers (the hodge-podge of Struts, Spring, JSF, etc. only makes things worse).
Last but not the least, let's go back to the basic question and ask ourselves "cui prodest?" I see what Sun has in it, yet I fail to see what benefits Oracle is supposed to realize for it. Oracle is not a player in this field. Speculation and rumors may fly high but it will be interesting to observe the real motives of Ellison in this case.
The paragraph I quoted in my first post was about price. More specifically, about the impact of non-Microsoft based solution on the product price.
Too bad the idiots didn't bother to check the facts: Windows OEM license is actually in the $50-$90 range. That's exactly the savings you get for not preinstalling Windows on a PC. The rest is hardware.
There is another somewhat plausible explanation of low cost however: having an Operating System so lightweight, it doesn't requires too much hardware. For a common e-mail-browser-wordprocessor-spreadsheet use case one doesn't need 1Gb or RAM. Building an OS that is oriented toward that use case should result in much lower resource requirements, making hardware cheaper.
Aside from "reinventing the wheel" issue, it is also to bee seen yet, whether AJAX fulfills its interactivity promises without making application development unbearably complicated (it is one thing to show a "Hello, AJAX" example; an application with real-life functionality is another matter). Java has been promising similar features for years and so far its success in the field has been mediocre at best.
Recalling the Simpsons: "Only suckers buy [last year's] model. You are not a sucker, are you?"
I can't wait to start padding my resume with the latest and greates technology out there that will do the same thing we've been doing for decade but with more acronyms and steeper learning curve.
I've been trying to get help from Google for two months already. So far, I only received two automated responses and nothing else. I am still unable to log onto Orkut.
My overall experience with Google is mixed: it works great when it works. When it doesn't work, it's a disaster - there is no contact phone number or e-mail address where a human being would try to fix the problem. You are basically on your own because, you know, "It's free, so no guarantees."
I hope, Google DVR if it ever gets released without their favorite 'Beta' qualifier, will have real customer support. Google so far has been in business where they provide no guarantee to anyone. They have to learn how to support their clients.
- Consider
.NET Development Center. MSDN has been following this documentation presentation model for years and it proved to be quite convenient for developers. You get a hierarchical API tree on the left and documentation on the right. The documentation for API groups is clumped together with nice introductory articles etc. Unfortunately it is practically impossible to generate using Doxygen.
- Doxygen is not scalable. Period. If your source base is 10 million LOC and you change one function in one tiny file, you will have to run Doxygen on your entire source base to incorporate the change.
- Neither is Doxygen geared toward generating API manuals. This is actually the worst problem with the whole situation. I've seen projects, where people would generate Doxygen style API reference and call it "documentation." Well, just having a huge list of documented function is not documentation.
Having said that, I still think that Doxygen is the best automated documentation generator out there and I hope it'll answer all those issues in the future.As for the severity, taking one's license is far from being merely a slap on the wrist. If one has invested a considerable amount of time, money, and energy into developing some computer-related skill set, being banned from any computer-related job is actually an extremely severe punishment - one would have to build his career again from scratch in some completely unrelated area.
Once these measures become accepted and after a number of well-published cases, computer crime will become a domain of hardcore criminals as opposed to pimple-faced kids, having nothing else to do on rainy Sunday. And that is actually good, because it is easier to fight the criminals than the kids.
Many professions where wrongdoing is a serious offence have employed license revocation as a successful deterrent. While software development is not a licensed activity, having a similar punishment (e.g. prohibition to be employed in any computer-affiliated capacity) might be a solution for a problem. Needless to say, that this is a drsatic measure and it should be applied to serious offenses only (i.e. viruses/worms, etc.)
The problem is, each distribution has its own set of goals. Or at least it better have - otherwise there is no reason for it to exist. And while there are different sets of goals, there will always be problems with maintaining a unified base.
The main problem, however, is that "enterpriseness" of the distribution is not about the choice of package format or a set of packages, or a cute name. It is about support. RHEL per se is not much different from dozens of other distributions on the market. It is the support behind it that makes it so attractive in the eyes of the IT industry. And this is really what any join effoer for another enterprise-ready distribution should be about.
It's sad if that's the way it works for you. Regression testing is a big deal for our business not because of the management but because we want our clients to be happy. I would be awfully embarrassing for us if every software release (which we do on a weekly basis for 200,000+ clients) broke some feature that used to work before. We care about our reputation and we care about our clients, which is why we try not to break things.
It is also sad that a lot of Open Source projects reject the idea of treating themselves like a regular business in a sense that they would try to identify the client base, to cater to it and to respect it. Applying those simple rules would dramatically increase the impact of the project, broaden the audience and it would not violate the spirit of the Open Source in any fashion whatsoever.
Anyway, to close this thread (it's been way longer than what I itended), let me just say that I did not intend to start teaching the GCC developers what they should do. I just shared my views based on my experience. If it is the case that the regression testing is completely unusable for GCC than there is little use in trying to utilize it now without a rewrite. But it is obvious to me that having a decent regression testsuite for GCC would benefit everyone, developers and clients alike.
Your arguments just serve as excellent exceptions proving the rule. Yes, there are cases when the bugfix is so important that it has to go in right away. However unlike your world where it would happen and then someone starts screaming bloody murder a day, or a week, or a month from now, in our case we are fully aware that the urgent fix breaks feature X before we even release the new version and the next order is to fix that feature for the follow-up release.
As for the completeness of the testsuite - you are right. Nothing is complete and features do break. However using it as an excuse to not abide by regression testing rules is akin to not trying to achieve anything just because of the possibility of failure. Try regression testing and you'll see that surprise breakages will diminish over time even if not every single case is covered. One project I used to be in charge for was a middleware request broker, routing tens of millions of messages per day with rich feature set and rather decent platform support. Since the initial release I cannot recall a single breakage for the last 15 releases.
This process is subjective and the net result is the product constantly breaking things that used to work. It practically nullifies the value of regression testing. Consider the "double releases" of so many software packages, where the second release comes straight on the heels of the prior one because the first release broke things that used to work. With reasonable regression testing process such problem is minimized.
The alternative process requires more discipline. It doesn't hold new fixes "hostage" but it requires responsibility on your side to ensure that your fix doesn't break anything else that used to work. And in case it does, it puts the burden of fixing it upon you. But as a result, you avoid that vicious flipping where every new release tends to break some feature of the previous one.
Exactly! Sorry if it sounds harsh but that's the only way to ensure non-deteriorating quality of the product. It worked before. now with your patch it doesn't - ergo, your patch broke it. You may think that your patch fixed a really important problem, but from the point of view of some guy in Romania using GCC on C64, the new version broke things. Regression testing approach eliminates the source of ambiguity about whose fix is more important and whose bug is "buggier."
Note however, that I didn't delve into the mechanics of fixing such newly introduced bugs. This is something that can be improved. For example, if you produce a fix for one bug and it breaks Ultrix, there should be some way to talk to someone involved into Ultrix port to get some help with fixing the issue. If there's no one involved, there should be at least some company sponsoring the architecture. If there's no such company, then the port should be announced as unsupported and heading toward obsoletion.
I realize that it is easier said then done but having a reasonable process to handle such issues is much better in my opinion than ad-hoc rejection of support just because the target audience is smaller compared to Linux.
That's what regression testing is for. It is not unreasonable for any large system to contain a constantly growing testsuite that tests core features of the system. In fact, GCC does have a testsuite, although I don't know how versatile it is. For a compiler suite a reasonable testsuite would contain programs of varying complexity in the source language as well as object files for each valid combination of optimization/feature level and a platform (not a very difficult thing to produce).
The testsuite would then handle each such program in the following manner:
The only challenging part of this process is to "seed" the testsuite with canonical object files: someone would have to either trust a stable compiler version or to proof-read each .o/.s file. After that, all discrepancies would be considered failures by default. If the new compiler version produces different object code, it has to be either explained (and incorporated into the testsuite) or the compiler has to be fixed.
Combine the above with a distributed build system (like Tinderbox or CruiseControl) and you've got an automated regression testing system. After that, every applied patch would have to go through this ordeal to ensure that it doesn't break the compiler.
I would be great if this kind of data was utilized through a "Get the Facts" campaign to counter Microsoft claims about their superior TCO. I wonder if OpenOffice people are going to make use of it in order to promote awareness and gain even more support. If OpenOffice was a commercial product, their salespeople would already be knocking on the doors of all major education establishments with nifty handouts documenting this case study, begging the officials to give OpenOffice a try.
As we have seen in the recent years, computer criminals and indentity thieves are getting more and more organized in their attempts to steal valuable data and they try to utilize every single opportunity. Again, it is not a question for me whether wireless keyboard protocol is insecure but rather when it becomes actively exploited.