Yes, this does seem to be a rather minor problem. It doesn't do anything on the search engine page that the hacker couldn't do on his own page. It's arguable whether insertion of a popup window or an unbidden redirect is exactly a "security breach" at all. Although it's certainly annoying, none of the user's data is compromised.
This sort of thing could be used to break sites which use cookie security. It would be easy to use the JavaScript to return the session cookie to an intercept site by CGI communication with that site. However, since search engines don't usually have user accounts, this is unlikely to be important. Still, it should be tried on Yahoo! at least, and any other search engine sites that support login and use weak session security.
The time you take to learn a little bit about Linux will amount to far less time you'll waste with system crashes, forced product "activation," virii and who knows what else.
I've known how to use UNIX for twenty years now, but I prefer to use my Macintosh. Everything is easier, and easier means faster, because the software works with me rather than against me. While system stability on the Mac is worse than on Linux, application stability is much better. I got a Linux box (Red Hat) last year out of curiosity, and played with a bunch of software I downloaded, but everything about the application software was so painful, awkward, ugly, slow and unreliable that I found myself still using the Mac for everything. After a few months of idle time on the Linux box I gave it away. I haven't missed it once.
I read that report and I thought it was very good. However, it did not deal with the same subjects as the FAQ of this story, which is oriented largely towards installation issues and use of the command line.
I don't ever recall seeing a usability study on the use of the command line by ordinary computer users, but I'm sure it would be an amusing waste of time and money. It's obvious what the results would be.
The concept that you need to learn an OS disturbs me. Linuc is obviously an engineer's OS and not a user's OS.
Despite your mod down to Troll status, you're quite right. The idea of needing to read a 50-page manual before using a piece of software has been obsolete since 1984. Most of the computer-using world knows that it's obsolete, but/. is a haven for command-line nostalgics. Apparently there are people who prefer to spend their time memorizing commands rather than using software to get something done, just as there are people who would rather tinker under their car's hoods than actually drive anywhere. I have nothing against this taste, but what seems to be missing on/. is an understanding that this inclination is and always will be in the minority.
ersonally, I'd think that making the OS easier to use would be a good idea.
Excellent point. This 50-page manual is a testament to bad design on every page. I particularly like the constant assumption that Windows users have spent most of their time in the DOS shell.
It would be fun to do a controlled study to watch average users scratching their heads over the thing and asking to be excused early.
It's possible if the primary author takes the pains to get ownership of improvements assigned to him, and the community is willing to do so.
The main issue there seems to be informed consent, that is, do community contributors understand that their contributions may be used to generate revenue for someone else? I think we can all agree that it would be deceptive to represent software as GPLed and accept free submissions without informing contributors of the commercial licensing of their contributions.
Ghostscript is an example of a GPL'ed Free Software program that provides its primary author with a source of revenue from proprietary licensing.
Thanks for the reference! I see a general description of commercial licensing, but so far I haven't been able to find the modifications to the GPL that assign all modifications back to the owners of Ghostscript. Could you provide a quote or specific pointer, and explain how informed consent for contributing changes works here?
Software under Mozilla-style licenses requires ownership of published modifications to be assigned to the originator. Netscape/AOL/Time-Warner owns all modifications to Mozilla.
I can't find such a provision for assignment of modifications in the Mozilla Public License. Again, could you please provide specifics, and explain how informed consent is obtained?
The thing Mundie always forgets is that if I release my wonderfull code GPLed it doesn't stop M$ from using it - it just requires them to come back to me and license it under some other terms...
This is technically possible, but does anyone do it? Pragmatically this kind of license fork seems untenable.
For one thing, if there is any community support of the GPLed version, third-party improvements to the GPLed version could not be covered by the commercial license. This includes any contributed changes that were incorporated into the main source branch by the original author -- they're all GPLed. That means there probably does not exist any "pure" version which could be commercially licensed. Any free software which has enough value that someone would wish to license it commercially (e.g., Mozilla, GCC, Linux kernel, Bison, Eazel, GNOME, KDE, etc.) has probably benefited from community participation, and so could not be commercially licensed.
First, consulting businesses are really the only viable business model for Free Software. I don't think anyone has tried to deny that.
(I'll assume you meant services businesses, since companies like Eazel, Mandrake, Red Hat, and so on are not consultancies per se.)
That's fine as far as it goes, but small consultancies don't have the financial resources to support the development of significant original software. If consulting were to become the dominant software business model, it would create stagnation in the software industry. Let's face it, people want to use Word, not TeX, and Photoshop, not GIMP. A consultancy or a computer science department is never going to develop Word or Photoshop. That takes serious revenues and investment, not linear service fees or spare-time development.
Second, you mostly seem to be obsessed with being "greatly profitable" rather than making enough to live on.
I was responding directly to claims about Cygnus, Red Hat, and other companies being, and I quote, "greatly profitable." In fact, they are not profitable at all, much less "greatly." I often see the same claim about open source profits made by open source advocates. The post I responded to here was modded up to 5, which is ridiculous for a set of demonstrably false statements.
I'm sorry if you or the moderators don't care to be informed of an uncomfortable truth, but I think it's important to correct persistent misinformation. Debate should revolve around facts, not propaganda.
You do have a point, but I think the truth lies somewhere between my observation and your response.
What concessions RMS makes to the ability to make money in The GNU Manifesto are distinctly pained. It's clear that RMS believes anyone writing software should be motivated primarily by the sheer joy of it, and that the need to pay the bills should be considered a regrettable necessity. He says that he believes programmers should be paid much less than they are and that the prospect of wealth is a corrupting influence.
His whole concern is with programmer salary, and not with business model. He barely discusses what it would take to actually build a business on free software as opposed to what it takes to pay programmers. When he even discusses salary, it's only in one of his pained concessions about how if you really have to make money, here's how you could, but really, you shouldn't care about that.
In contrast, ESR enthusiastically embraces the idea of open source as a way to make money. In some ways this is just a difference in emphasis, but it's a big difference in emphasis, on which numerous companies were launched -- as opposed to the one major company formed under the RMS model, Cygnus. And the ESR companies have enthusiastically embraced the Big Money/Next Big Thing way of describing themselves, which is anathema to RMS.
Unfortunately, no company of significant size founded on the ESR model has yet succeeded in making a profit. There are a few small consultancies, but they do not create significant original software -- they only offer services on software which other people have written, or create small vertical projects. The ones that have tried to create their own horizontal software (e.g., Eazel, Lutris) have not made a profit by doing so.
I agree with your analysis of Red Hat's overvaluation, and I also agree that we will not see an Oracle or a Microsoft emerge from Open Source. The question is whether we will see any profitable horizontal software development businesses emerge from it. So far, there are none.
I don't agree that the model has universally failed...
I didn't say that. I said it "has almost universally failed, and nowhere succeeded." So far, nothing in this thread has provided any valid counterexamples to that observation.
there are plenty of us that don't give a ding darn whether the "business model" is "valid" or not. Richard Stallman sure as hell doesn't care.
This is the first of several comments like this in the thread, so I'm responding to this one.
Business model is exactly the difference between free software and open source. You're quite right that RMS doesn't care about profit potential. He is opposed to the idea of making money by writing software. This quixotic viewpoint defines the free software movement. For a while, it largely gave way to the open source movement, which held that it was possible to make money by developing software and giving it away with source code for free. Now it's turning out that this concept doesn't work, which is why I wrote: "Hasn't the idea that open source generates major profit potential been pretty well refuted?" I'm not arguing here against the free software concept, only the open source concept.
Cygnus, for example, was greatly profitable developing free software long before the movement ever became popular. RedHat seems to be doing well, having beat analyst expectations every quarter. Mandrake has done well. IBM has done well. CollabNet has done well.
The above is not correct, and in fact, no one has been able to cite an example of a profitable open source software company. Cygnus was privately held and so it's hard to figure out if it was proftable or not, but it was definitely not "greatly profitable." However, it's easy to do a back-of-the-envelope calculation based on its $20M in annual revenues and 180 employees at the time of its acquisition. The cost of maintaining 180 employees in a technology company in the SF Bay Area is more than $18M annually, and there are other costs of doing business, so if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "greatly profitable.")
Red Hat has yet to turn a profit, though it keeps promising one real soon now.
Since its creation in November 1998 the company recorded losses. The cumulated amount of the overdrawn turnover of the group accounts between September 30, 1999 and 31 March 2001 amounted to 13,7 MEuros is approximately three times the amount of the turnover over the period. In spite of a strong progression envisaged of its turnover, MANDRAKESOFT considers a benefit only at the end of the exercise closed at June 30 2003;
That is, it doesn't expect to become profitable for two years.
IBM is sinking a billion dollars into open source this year. That doesn't mean it will realize any profit from this investment. It certainly hasn't earned it back yet, and whether it ever will is purely speculative.
CollabNet is privately held, so it's hard to say how much money it's made back on that $35M investment. It's announced a few deals, but refuses to comment on their size: "It's our first true enterprise development network..." It's a significant deal for CollabNet, so much so that Mills refused to comment on the size of the contract or even whether it's the company's biggest win so far. (CollabNet is still privately held.) Mills did say that there are other deals now in the pilot stage with the potential to be as big as this one. I think it's a safe bet that the company is not yet profitable.
Many consultancy companies have done well. In fact, the consultancy companies do what can't be done in the Microsoft world - they can be profitable, equal players.
Consultancies are homesteading businesses, not software companies. As already pointed out, consultancies only scale linearly, not exponentially. In any case, they aren't doing so well either. I'm not going to mention the name of one company we're partnered with, but they make a great open source product, but they're in dire straits and they're going to have to start charging for it. I imagine there are probably a few small-business open source consultancies which are bringing in six-figure salaries for their principals, but that's not enough to sustain development efforts, and it's not enough to go public.
He said that we basically don't see economic reality and we don't know about business, and while we have good points we should abandon most of our philosophical ideas.
No offense, but isn't that true? Hasn't the idea that open source generates major profit potential been pretty well refuted by the bursting of last year's Linux bubble and the collapse of companies like Eazel and VA Linux? Was there ever a quantitative business model as opposed to a religious manifesto behind any of those claims? Hasn't the idea of making money by giving away software and charging for services failed for almost every company that's tried it?
No flamebait here, I hope. I'm just not sure why people are continuing to assert the validity of a model that has almost universally failed, and nowhere succeeded.
I agree with you. The video is completely unconvincing as a claim of flight. The unit is visibly dangling, and its altitude is too steady for the fans to be contributing -- it's clearly being held just where it is by the tether. The web site calls it a hover test, but the unit is not hovering, it's hanging.
If this were being presented by Transcendental Meditation to demonstrate their claims of levitation, we'd laugh it out of court.
The question that ran through my mind when reading this piece was whether it had anything to do with security by obscurity. There's nothing "obscured" about an unpublished link or a non-standard HTTP port. They are completely understandable, just a little harder to find if you haven't been told where to look.
Security through obscurity is usually discussed in terms of hiding encryption algorithms and security protocols, which is a totally separate issue. Read this article by Simson Garfinkel on the subject, for instance.
So to me the article seemed like a giant non sequitur.
It must be tough to do earthbound testing of such a device. Of course, the article was short on details.
However, it was not short on that detail. It discusses the issue and shows a picture illustrating that testing will take place on the Vomit Comet:
By flying in a parabolic arc, airplanes can simulate weightlessness here on Earth! A prototype of the PSA will be tested in a weightless (freely-falling) environment aboard a NASA KC-135 next year.
I will omit the obligatory refrain of "read the article, then post."
The lack of DVD playback is especially odd considering how much time Steve devoted to iDVD
I pointed out here on/. back in March that the lack of DVD playback in the original Mac OS X release was very curious given the Apple DVD marketing push, since if the operating system was up to DVD playback, it should require little more than a utility program to provide it. I speculated that this implied a deeper system problem which would take significantly longer to fix, possibly something related to non-real-time process scheduling. This suggestion was greeted with a mixture of disbelief and exasperation.
At this point, it looks like my speculation has been validated. The reason DVD playback is not yet available for Mac OS X is not simply because the program wasn't finished in time, but because it has proven difficult to implement on the Darwin kernel.
The remaining questions, given that it is being reported that DVD playback was still flaky during today's demo, are whether the new, extra-slipped September ship date for the feature is realistic, and whether the fix for the problem is robust enough to deal with new applications that will require steady high-bandwidth real-time data delivery.
HP and its partners at the University of California, Los Angeles (UCLA), expect to be able to fabricate a 16-kilobit memory using this approach by 2005.
Two kilobytes? WOW!
Why, if Moore's law applies to this new technology and they get a 64-fold increase over the following decade, they'll have built a 128KB memory by 2015!
Move over, DRAM! Step aside, SRAM! A new memory king is coming to town!
I was addressing applicationperformance issues primarily in the final paragraph's examples.
GIMP chokes badly on the kinds of large files that are common in design, while Photoshop is optimized for large file sizes. In addition, GIMP doesn't do CMYK separation and isn't integrated with useful color management packages. The performance and feature gaps produce a TCO equation that is decidedly against the "free" GIMP.
As for UI, Photoshop's is generally acknowledged to be superior, which is a significant TCO factor.
With respect to GCC vs. CodeWarrior, I was referring to compile speed, which is a fundamental determinant of programmer productivity. GCC doesn't even have precompiled headers. I was not referring to program optimization.
The vast majority of issues cited applied only to server systems. Desktop systems were discussed only in a speculative way, not in either qualitative or quantitative terms.
Reliability used an oversimplistic methodology, probing only for crashes and freezes based on random character input. This is not a metric that has anything to do with the average time between software failures and the seriousness of those failures in real-world software usage; it's yet another uptime-based quality claim. No commercial vendor would ship software that had been QA'd only through this ridiculously simplistic process, which would miss virtually all bugs.
Performance discussion dealt only with the speed of the base OS platform, not of applications.
The first numbers were based on abstract benchmarks rather than on comparison of real-world software packages. Instead, let's compare building a project with GCC vs. CodeWarrior, or browsing the web with Mozilla on Linux vs. Explorer on Windows or Mac.
When claiming a win on database performance, the article fails to note that the winner, while running on Linux, was DB2, a proprietary product from IBM, not an open source or free software database. Let's try MySQL under load against a commercial package instead.
The third performance test cited was for custom-built software, not applications which are used in the field. Again, it's quite possible the base kernel is faster, but in real-world conditions application performance usually predominates.
The web server benchmarks appear to be for static pages. Apache is known to be slower than IIS for dynamic content.
Security I'll grant is much better on Linux than any flavor of Windows, though a desktop Mac OS (not X) system is more secure than either.
The total cost of ownership issues associated with inferior user interfaces and typically inferior application software performance were not addressed. For instance, compare a shop of graphic designers using GIMP on Linux with one using Photoshop on Mac or Windows, and you'll arrive at a very different TCO conclusion. Ditto for a software engineering team using GCC vs. one using Codewarrior.
In short, it seemed to me a very partisan piece that ignored most of the issues associated with real-world desktop usage.
Note the word "concieved" in the first line of the document...there is not much in place yet.
That was my first take as well, but then when I looked through the references, I found that many feasibility questions seem to be resolved already. For instance, I read the main page and thought, "Sure, but how do you transport the strand through the nanopore?" Then I checked the first reference listed, and what do you know: "We show that an electric field can drive single-stranded RNA and DNA molecules through a 2.6-nm diameter ion channel in a lipid bilayer membrane."
The final system may still be largely conceptual, but it's by no means blue sky. I tend to be a techno-skeptic but this work impresses me.
The page sounds to me like a breathless plea for lots of venture capital funding.
This is grossly unfair. The language and style are well within the normal bounds for scientific papers. The word "revolutionary" is appropriate for a technology that would do years of work in hours. And in case you didn't notice, it's not private research -- it's being done at The Department of Molecular and Cellular Biology, The Biological Laboratories, Harvard University. What interest would a university laboratory have in "venture capital"? If they later spin it off into private industry for product development, then they might go for venture funding, but it simply makes no sense to do so now. There's a big difference between research sponsorship and venture funding.
They turned out to be far more problematic than anticipated, like most new technologies. Gears stick together, levers bend, everything wears out. It turns out that microsurfaces are different enough from macrosurfaces that the basic mechanisms that work on the macroscale fail on the microscale.
Unfortunately, it's not online except for subscribers, but the always interesting Science News did an article on the problem last year:
Unexpectedly strong friction and other surface forces are hindering development of some microscopic machines, such as these microgears with teeth 9 micrometers long. Researchers are turning to a new frontier of surface science for answers about sticking and wear.
There are micromachines that work, as other posters have noted, but the idea that larger-scale mechanical engineering could be easily projected into the microworld has now been discredited. Nanotechnology will present even greater challenges.
In my experience, most programmers generate awful, bug ridden code thanks to premature (and frequently incorrect) `optimization'.
I'd agree with that. I've often seen programmers introduce early twists and turns into basic data flow in hopes of creating some performance improvement down the line. In real life, most performance problems are unanticipated and need to be determined by empirical measurement, not by convoluting the architecture.
Of course, there are some obvious performance problems that can be found by early design review, before coding even starts, but usually those are in areas where the problem is well understood. For instance, in a process system, you know that context switch is going to be a performance bottleneck, so you don't introduce 2K data copies at each switch, and in a B-tree system, you know that you want the index blocks to carry as many items per block as possible, so you don't have a 32-byte key when a 4-byte key will do. (These are both real-world examples of performance problems in Apple software which could have been headed off by review.)
Slashdot Mirror
This sort of thing could be used to break sites which use cookie security. It would be easy to use the JavaScript to return the session cookie to an intercept site by CGI communication with that site. However, since search engines don't usually have user accounts, this is unlikely to be important. Still, it should be tried on Yahoo! at least, and any other search engine sites that support login and use weak session security.
Tim
I've known how to use UNIX for twenty years now, but I prefer to use my Macintosh. Everything is easier, and easier means faster, because the software works with me rather than against me. While system stability on the Mac is worse than on Linux, application stability is much better. I got a Linux box (Red Hat) last year out of curiosity, and played with a bunch of software I downloaded, but everything about the application software was so painful, awkward, ugly, slow and unreliable that I found myself still using the Mac for everything. After a few months of idle time on the Linux box I gave it away. I haven't missed it once.
Tim
I know it's a joke, but to respond anyway:
I read that report and I thought it was very good. However, it did not deal with the same subjects as the FAQ of this story, which is oriented largely towards installation issues and use of the command line.
I don't ever recall seeing a usability study on the use of the command line by ordinary computer users, but I'm sure it would be an amusing waste of time and money. It's obvious what the results would be.
Tim
Despite your mod down to Troll status, you're quite right. The idea of needing to read a 50-page manual before using a piece of software has been obsolete since 1984. Most of the computer-using world knows that it's obsolete, but /. is a haven for command-line nostalgics. Apparently there are people who prefer to spend their time memorizing commands rather than using software to get something done, just as there are people who would rather tinker under their car's hoods than actually drive anywhere. I have nothing against this taste, but what seems to be missing on /. is an understanding that this inclination is and always will be in the minority.
Tim
Excellent point. This 50-page manual is a testament to bad design on every page. I particularly like the constant assumption that Windows users have spent most of their time in the DOS shell.
It would be fun to do a controlled study to watch average users scratching their heads over the thing and asking to be excused early.
Tim
The main issue there seems to be informed consent, that is, do community contributors understand that their contributions may be used to generate revenue for someone else? I think we can all agree that it would be deceptive to represent software as GPLed and accept free submissions without informing contributors of the commercial licensing of their contributions.
Ghostscript is an example of a GPL'ed Free Software program that provides its primary author with a source of revenue from proprietary licensing.
Thanks for the reference! I see a general description of commercial licensing, but so far I haven't been able to find the modifications to the GPL that assign all modifications back to the owners of Ghostscript. Could you provide a quote or specific pointer, and explain how informed consent for contributing changes works here?
Software under Mozilla-style licenses requires ownership of published modifications to be assigned to the originator. Netscape/AOL/Time-Warner owns all modifications to Mozilla.
I can't find such a provision for assignment of modifications in the Mozilla Public License. Again, could you please provide specifics, and explain how informed consent is obtained?
Thanks, Tim
This is technically possible, but does anyone do it? Pragmatically this kind of license fork seems untenable.
For one thing, if there is any community support of the GPLed version, third-party improvements to the GPLed version could not be covered by the commercial license. This includes any contributed changes that were incorporated into the main source branch by the original author -- they're all GPLed. That means there probably does not exist any "pure" version which could be commercially licensed. Any free software which has enough value that someone would wish to license it commercially (e.g., Mozilla, GCC, Linux kernel, Bison, Eazel, GNOME, KDE, etc.) has probably benefited from community participation, and so could not be commercially licensed.
Tim
(I'll assume you meant services businesses, since companies like Eazel, Mandrake, Red Hat, and so on are not consultancies per se.)
That's fine as far as it goes, but small consultancies don't have the financial resources to support the development of significant original software. If consulting were to become the dominant software business model, it would create stagnation in the software industry. Let's face it, people want to use Word, not TeX, and Photoshop, not GIMP. A consultancy or a computer science department is never going to develop Word or Photoshop. That takes serious revenues and investment, not linear service fees or spare-time development.
Second, you mostly seem to be obsessed with being "greatly profitable" rather than making enough to live on.
I was responding directly to claims about Cygnus, Red Hat, and other companies being, and I quote, "greatly profitable." In fact, they are not profitable at all, much less "greatly." I often see the same claim about open source profits made by open source advocates. The post I responded to here was modded up to 5, which is ridiculous for a set of demonstrably false statements.
I'm sorry if you or the moderators don't care to be informed of an uncomfortable truth, but I think it's important to correct persistent misinformation. Debate should revolve around facts, not propaganda.
Tim
What concessions RMS makes to the ability to make money in The GNU Manifesto are distinctly pained. It's clear that RMS believes anyone writing software should be motivated primarily by the sheer joy of it, and that the need to pay the bills should be considered a regrettable necessity. He says that he believes programmers should be paid much less than they are and that the prospect of wealth is a corrupting influence.
His whole concern is with programmer salary, and not with business model. He barely discusses what it would take to actually build a business on free software as opposed to what it takes to pay programmers. When he even discusses salary, it's only in one of his pained concessions about how if you really have to make money, here's how you could, but really, you shouldn't care about that.
In contrast, ESR enthusiastically embraces the idea of open source as a way to make money. In some ways this is just a difference in emphasis, but it's a big difference in emphasis, on which numerous companies were launched -- as opposed to the one major company formed under the RMS model, Cygnus. And the ESR companies have enthusiastically embraced the Big Money/Next Big Thing way of describing themselves, which is anathema to RMS.
Unfortunately, no company of significant size founded on the ESR model has yet succeeded in making a profit. There are a few small consultancies, but they do not create significant original software -- they only offer services on software which other people have written, or create small vertical projects. The ones that have tried to create their own horizontal software (e.g., Eazel, Lutris) have not made a profit by doing so.
I agree with your analysis of Red Hat's overvaluation, and I also agree that we will not see an Oracle or a Microsoft emerge from Open Source. The question is whether we will see any profitable horizontal software development businesses emerge from it. So far, there are none.
Tim
I didn't say that. I said it "has almost universally failed, and nowhere succeeded." So far, nothing in this thread has provided any valid counterexamples to that observation.
there are plenty of us that don't give a ding darn whether the "business model" is "valid" or not. Richard Stallman sure as hell doesn't care.
This is the first of several comments like this in the thread, so I'm responding to this one.
Business model is exactly the difference between free software and open source. You're quite right that RMS doesn't care about profit potential. He is opposed to the idea of making money by writing software. This quixotic viewpoint defines the free software movement. For a while, it largely gave way to the open source movement, which held that it was possible to make money by developing software and giving it away with source code for free. Now it's turning out that this concept doesn't work, which is why I wrote: "Hasn't the idea that open source generates major profit potential been pretty well refuted?" I'm not arguing here against the free software concept, only the open source concept.
Tim
The above is not correct, and in fact, no one has been able to cite an example of a profitable open source software company. Cygnus was privately held and so it's hard to figure out if it was proftable or not, but it was definitely not "greatly profitable." However, it's easy to do a back-of-the-envelope calculation based on its $20M in annual revenues and 180 employees at the time of its acquisition. The cost of maintaining 180 employees in a technology company in the SF Bay Area is more than $18M annually, and there are other costs of doing business, so if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "greatly profitable.")
Red Hat has yet to turn a profit, though it keeps promising one real soon now.
Mandrake is losing money. According to its financial disclosure, as translated by BabelFish:
Since its creation in November 1998 the company recorded losses. The cumulated amount of the overdrawn turnover of the group accounts between September 30, 1999 and 31 March 2001 amounted to 13,7 MEuros is approximately three times the amount of the turnover over the period. In spite of a strong progression envisaged of its turnover, MANDRAKESOFT considers a benefit only at the end of the exercise closed at June 30 2003;
That is, it doesn't expect to become profitable for two years.
IBM is sinking a billion dollars into open source this year. That doesn't mean it will realize any profit from this investment. It certainly hasn't earned it back yet, and whether it ever will is purely speculative.
CollabNet is privately held, so it's hard to say how much money it's made back on that $35M investment. It's announced a few deals, but refuses to comment on their size: "It's our first true enterprise development network..." It's a significant deal for CollabNet, so much so that Mills refused to comment on the size of the contract or even whether it's the company's biggest win so far. (CollabNet is still privately held.) Mills did say that there are other deals now in the pilot stage with the potential to be as big as this one. I think it's a safe bet that the company is not yet profitable.
Many consultancy companies have done well. In fact, the consultancy companies do what can't be done in the Microsoft world - they can be profitable, equal players.
Consultancies are homesteading businesses, not software companies. As already pointed out, consultancies only scale linearly, not exponentially. In any case, they aren't doing so well either. I'm not going to mention the name of one company we're partnered with, but they make a great open source product, but they're in dire straits and they're going to have to start charging for it. I imagine there are probably a few small-business open source consultancies which are bringing in six-figure salaries for their principals, but that's not enough to sustain development efforts, and it's not enough to go public.
Tim
No offense, but isn't that true? Hasn't the idea that open source generates major profit potential been pretty well refuted by the bursting of last year's Linux bubble and the collapse of companies like Eazel and VA Linux? Was there ever a quantitative business model as opposed to a religious manifesto behind any of those claims? Hasn't the idea of making money by giving away software and charging for services failed for almost every company that's tried it?
No flamebait here, I hope. I'm just not sure why people are continuing to assert the validity of a model that has almost universally failed, and nowhere succeeded.
Tim
If this were being presented by Transcendental Meditation to demonstrate their claims of levitation, we'd laugh it out of court.
Tim
How many virus writers go on to live normal, productive lives? How many never write another virus?
(Ah, to heck with it. Kill 'em all and let DoS sort 'em out!)
Tim
Security through obscurity is usually discussed in terms of hiding encryption algorithms and security protocols, which is a totally separate issue. Read this article by Simson Garfinkel on the subject, for instance.
So to me the article seemed like a giant non sequitur.
Tim
However, it was not short on that detail. It discusses the issue and shows a picture illustrating that testing will take place on the Vomit Comet:
I will omit the obligatory refrain of "read the article, then post."
Tim
Presumably this means that SuSe will now concentrate on actually making money rather than just making a distro.
Tim
So I'm not sure what your point is.
Tim
I pointed out here on /. back in March that the lack of DVD playback in the original Mac OS X release was very curious given the Apple DVD marketing push, since if the operating system was up to DVD playback, it should require little more than a utility program to provide it. I speculated that this implied a deeper system problem which would take significantly longer to fix, possibly something related to non-real-time process scheduling. This suggestion was greeted with a mixture of disbelief and exasperation.
At this point, it looks like my speculation has been validated. The reason DVD playback is not yet available for Mac OS X is not simply because the program wasn't finished in time, but because it has proven difficult to implement on the Darwin kernel.
The remaining questions, given that it is being reported that DVD playback was still flaky during today's demo, are whether the new, extra-slipped September ship date for the feature is realistic, and whether the fix for the problem is robust enough to deal with new applications that will require steady high-bandwidth real-time data delivery.
Tim
Two kilobytes? WOW!
Why, if Moore's law applies to this new technology and they get a 64-fold increase over the following decade, they'll have built a 128KB memory by 2015!
Move over, DRAM! Step aside, SRAM! A new memory king is coming to town!
Tim
GIMP chokes badly on the kinds of large files that are common in design, while Photoshop is optimized for large file sizes. In addition, GIMP doesn't do CMYK separation and isn't integrated with useful color management packages. The performance and feature gaps produce a TCO equation that is decidedly against the "free" GIMP.
As for UI, Photoshop's is generally acknowledged to be superior, which is a significant TCO factor.
With respect to GCC vs. CodeWarrior, I was referring to compile speed, which is a fundamental determinant of programmer productivity. GCC doesn't even have precompiled headers. I was not referring to program optimization.
Tim
Reliability used an oversimplistic methodology, probing only for crashes and freezes based on random character input. This is not a metric that has anything to do with the average time between software failures and the seriousness of those failures in real-world software usage; it's yet another uptime-based quality claim. No commercial vendor would ship software that had been QA'd only through this ridiculously simplistic process, which would miss virtually all bugs.
Performance discussion dealt only with the speed of the base OS platform, not of applications.
The first numbers were based on abstract benchmarks rather than on comparison of real-world software packages. Instead, let's compare building a project with GCC vs. CodeWarrior, or browsing the web with Mozilla on Linux vs. Explorer on Windows or Mac.
When claiming a win on database performance, the article fails to note that the winner, while running on Linux, was DB2, a proprietary product from IBM, not an open source or free software database. Let's try MySQL under load against a commercial package instead.
The third performance test cited was for custom-built software, not applications which are used in the field. Again, it's quite possible the base kernel is faster, but in real-world conditions application performance usually predominates.
The web server benchmarks appear to be for static pages. Apache is known to be slower than IIS for dynamic content.
Security I'll grant is much better on Linux than any flavor of Windows, though a desktop Mac OS (not X) system is more secure than either.
The total cost of ownership issues associated with inferior user interfaces and typically inferior application software performance were not addressed. For instance, compare a shop of graphic designers using GIMP on Linux with one using Photoshop on Mac or Windows, and you'll arrive at a very different TCO conclusion. Ditto for a software engineering team using GCC vs. one using Codewarrior.
In short, it seemed to me a very partisan piece that ignored most of the issues associated with real-world desktop usage.
Tim
That was my first take as well, but then when I looked through the references, I found that many feasibility questions seem to be resolved already. For instance, I read the main page and thought, "Sure, but how do you transport the strand through the nanopore?" Then I checked the first reference listed, and what do you know: "We show that an electric field can drive single-stranded RNA and DNA molecules through a 2.6-nm diameter ion channel in a lipid bilayer membrane."
The final system may still be largely conceptual, but it's by no means blue sky. I tend to be a techno-skeptic but this work impresses me.
The page sounds to me like a breathless plea for lots of venture capital funding.
This is grossly unfair. The language and style are well within the normal bounds for scientific papers. The word "revolutionary" is appropriate for a technology that would do years of work in hours. And in case you didn't notice, it's not private research -- it's being done at The Department of Molecular and Cellular Biology, The Biological Laboratories, Harvard University. What interest would a university laboratory have in "venture capital"? If they later spin it off into private industry for product development, then they might go for venture funding, but it simply makes no sense to do so now. There's a big difference between research sponsorship and venture funding.
Tim
They turned out to be far more problematic than anticipated, like most new technologies. Gears stick together, levers bend, everything wears out. It turns out that microsurfaces are different enough from macrosurfaces that the basic mechanisms that work on the macroscale fail on the microscale.
Unfortunately, it's not online except for subscribers, but the always interesting Science News did an article on the problem last year:
There are micromachines that work, as other posters have noted, but the idea that larger-scale mechanical engineering could be easily projected into the microworld has now been discredited. Nanotechnology will present even greater challenges.
Tim Maroney
I'd agree with that. I've often seen programmers introduce early twists and turns into basic data flow in hopes of creating some performance improvement down the line. In real life, most performance problems are unanticipated and need to be determined by empirical measurement, not by convoluting the architecture.
Of course, there are some obvious performance problems that can be found by early design review, before coding even starts, but usually those are in areas where the problem is well understood. For instance, in a process system, you know that context switch is going to be a performance bottleneck, so you don't introduce 2K data copies at each switch, and in a B-tree system, you know that you want the index blocks to carry as many items per block as possible, so you don't have a 32-byte key when a 4-byte key will do. (These are both real-world examples of performance problems in Apple software which could have been headed off by review.)
Tim