Your interpretation of how GCC's various front-ends and back-ends work together, and where optimization happens is a bit skewed. For the most part, if GCC-ADA is poorly optimized, it's no one's fault but the ADA-front end folks. This is because GCC's intermediate represenation (RTL) is essentially treaded as an "assembly" by the front-ends. They compile the code into a syntax tree, optimize where the language allows such optimization, transform that into RTL (at which stage "ADA types" are pretty much gone, and much lower level types have come into play) and then the back-end turns that into assembly and sends it to the assebler.
That sounded a lot cleaner than it really is. At least one of those transformations (syntax tree to RTL) isn't really performed at all, and there's a lot that the ADA-front end has to know about the target platform that it finds out from the various platform specifications that GCC's back-end uses.
Still, the back-end is responsible only for os and machine-specific optimizations and so-called "peephole" optimizations.
As for C being the enemy of proper optimization, I think you're looking a little too hard for a culprit. The real enemy of strong optimization is processor speed. If processors doubled in speed every 20 years, you would see a great deal more effort going into optimization. As it is, the perception is that only obsessives care about those "few extra cycles", which is rather sad. Still a lot of good work is done, and the fact that high-level languages has been flourishing in the last 10 years has really put the screws to the compiler writers to keep up.
Ok, so your statements have gone from generic "low level languages are no faster than high level" to a defense of JIT compilers.
Fair enough, and I can roll with that. Yes, you will get a performance boost by optimizing code for a particular platform on-the-fly.
How much? Hard to tell, since the difference even between two compilers on the *same* platform can be so very different.
What is very certain though is that the largest hit in this is the language. I'm actually surprised that you don't realize that. It's not a slam against C++ to say that its more complex type and exception system slows code down. It's just the cost of abstraction. It's not a slam against Java to say that it's platform-indepenance comes with a speed penanly. It's just what you have to deal with in order to get Java's level of abstraction.
Seriously, if compiler technology were the only barrier to fast code, then the fastest programming language in the world would be LISP, since it pre-dates computers.
And yet, LISP is slow. Why? Mostly because managing everything as a list isn't what modern processors do best, but also because there's an awful lot that a programmer doesn't have to tell LISP in order to get a program to work.
Same goes for Java, just less so. Same goes for C++, just less so still.
C++ is an interesting case. It tries to be a high-level language while maintaining all of the low-level features of C. This has the interesting effect that you can write slower code that is very abstract and quick to write, or you can write very efficient code that requires more manual bit-twiddling (so to speak). The cost comes in the difficulty of maintaining any particular piece of C++, but for some it's worth it.
I really love the very idea of programming languages. They're all very cool as far as I'm concerned (even humble COBOL had its day and there are a few places that TCL is quite interesting). Don't focus on one language and then set out to prove why it's the best tool for all jobs, because pretty much by definition that's not true. Once you've learned about 10 of them and assembly for a few instruction sets, you really begin to get a sense of how wonderfully complex all of the tradeoffs in programming languages are, just as with spoken languages.
I understand your points, and I did take them all into account in my original post.
A compiler can simply optimize large blocks of code better than you can
Yes, and no. It can optimize a large block of code better within the constraints of the language.
A great example of this is C vs aseembly. You say:
so for sufficiently large apps, the C version will almost always be faster than the assembler version, because it can find neat optimizations you didn't think of
You are talking about optimization, and that's cool. I'm not. I'm talking about abstraction. The job of a language includes making certain performance trade-off considerations in favor of development flexibility and maintainability (among other, lesser goals like re-usability, etc)
When a language makes those choices, it's kind of counter-productive to then allow you to violate them. Thus, C imposes scoping, typing, etc. These features all come with performance penalties, but they make writing and maintaining code easier. It's possible to optmize away scoping in a great many cases, but not all (e.g. you can inline, flatten scopes, etc). Ultimately the assembly programmer is going to make *casual* choices which are more optimal because he's looking at the code. It's not a matter of optimization, but of context.
Already many C compilers ignore the 'register' keyword, because they know they can do a better job allocating registers than you can.
That's not at all why they ignore that keyword, and I'm stunned that you think that! The reason that they ignore the keyword is because it's nearly useless except for a handful of architectures. I assure you that if C provided a sophisticated, portable interface to register selection, it would be a boon for program execution everywhere.
The problem in C is that you can only turn on or off a boolean bit, "is this stored in a register". Since the compiler has access to knowledge about the platform it is capable of dealing with virtual registers and register-banks in ways that that simple boolean keyword cannot.
This has absolutely no bearing on the assembly programmer who will be managing those registers to a degree that even C cannot match because it doesn't know what your code execution profile is likely to look like (there are optmizers in the world that re-optimize your program based on profiler output, but they tend to be of limited value because even analyzing profiler output is frought with dangers that only hard AI can tackle).
Please understand here, that I'm not some cranky old man pining for the days of VAX assembly. I'm nto saying that you *want* to write everything in C or even assembly. I'm saying that deluding yourself into thinking that a high-level language like Python, Scheme, Perl, LISP, etc, etc will ever have the performance of a low-level language is pointless. It simply cannot happen until compilers are smart enough to throw away what you wrote, reverse-engineer a set of requirements and re-write it in a lower-level language.
These high-level languages WILL get better. They will get faster as compiler technology progresses, but given the same access to hardware instructions, and hardware that isn't specially designed for one or another high-level language, you will always tend to write less abstract code, and therefor more optimal performing code, in a lower level language.
Go find example programs whose performance characteristics in C vs Java, Smalltalk or any other higher-level language disprove that. Even C++ that looks just like C has to deal with exceptions, dynamic scoping and type conversion that C does not, and the compiler cannot always know if/when those will come into play! It gets worse once you go up to Java where native hardware types get virtualized and have behaviors that are convinient, but costly. Worse still when you go up into LISP where data is code, and both are run-time modifiable.
But, in each of these cases there are significant improvements in the level of detail which the programmer must manage. You take the performance hit because you gain in other ways.
At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
If that was intended as a joke, it's pretty funny. Otherwise, you need to hit the books.
C is "fast" because it's a low-level language. C++, ADA, Perl, C#, LISP, Python, Java, Scheme, etc are "slow" in comparison because their relative levels of abstraction add a performance penalty.
The same can be said (and is, and is correct) of assembly vs. C. C is "slow" in respect to assembly because assembly lacks the abstraction of lexical scope, typing, automatic stack handling, etc.
This is not a theory, it's simple definition of terms.
If you're trying to advocate VMs or other forms of interpreted execution, there are some excellent reasons on which to base your case. Execution speed that will one day magically match that of the same program written in C is most certainly not one of them (assuming that we don't get strong AI any time soon, and build a JIT around it).
My bad, wrong kind of "network". While the idea may be applicable to computer-interconnectivity, that's not what this is about, and I would have known that, had I read the article.
I don't know a lot about the state-of-the-art in the area of network discovery/repair other than what I know as a socket-programmer and sysadmin, but I'm wondering if someone who does know can point out the differences between, say, this research and Apple's Rendezvous (not to be confused with Tibco's product by the same name)?
It seems to me that the basic goals are similar, but with Apple focusing more on the engineering side of solving a user-problem rather than passing the point of diminishing returns on "correct" solutions. Please, feel free to enlighten me though. This stuff is actually really promising, and I hope to live in a world 5 years from now where my laptop just "fits in" to the network that it's placed on in more ways than mere DHCP can accomodate.
I suggest you look into CinePaint (ne Film Gimp), as it sounds like that would suit your needs more than the classic Gimp.
The Gimp is an excellent "basic photo editor", which for those of you who can recall what things were like 6 years ago, is basically the root of what Photoshop was. All we need is for someone to come along and finish the job.
The Gimp folks are going the long, slow route of trying to fix everyone's problems at once. This works for OSS, ala Mozilla, but the results are slow, and many will wander away before its done.
The CinePaint folks are doing the big-return stuff first because they have a specific niche to serve. I'll be very interested to see where it all goes....
Which is no problem at all. Honestly, I sometimes think that no one reads what I write, they just respond to the third post back, no matter who wrote it (sorry to be snide, but that's happened to me on Slashdot a lot more in the last few weeks).
Here's what I said on that very topic:
I was suggesting that a company take The Gimp, modify it as needed (contributing back the OSS parts, and keeping proprietary plugins for patented stuff that they will have to chage money for to pay royalties and fund their staff).
There's this sort of give-and-take to the patent system. It doesn't allow you to hide a technique for 2 decades, it lets you be the primary benificiary of that technique. The way it does this is to require you to license your technique under "reasonable terms" (read, what the market will bear).
So, a company that build their product around The Gimp could keep all of the patent-related goodies in plugins (perhaps changing some of the plugin API where required to make more core-related features pluginable), and only distribute those plugins for a fee, along with support, etc.
The fee would go to pay business costs as well as paying the royalty fees. You can still contribute the bulk of your work back to The Gimp, and you can still benefit from the development being done on it, but you get neatly around PhotoShop's patents for customers who need those features.
I guess I'm behind the times. Much of my idea is already reality, and the name of the product is CinePaint, which is the re-named "Film Gimp" that I mentioned before. I don't know if they intend to incorporate the patented elements from PhotoShop in a non-free version, but it seems like a logical step, and Gimp's plugin system makes that a reasonable (logistically, I leave the ethics of using patented code up to the reader) thing to do.
"Even with all its popularity and success for far, some people are still surprised to hear that the current software release of CinePaint is still a pre release version ! Rowe points out the project is far from finished, "The GUI is the main thing holding us back now. The goal for 2003 is to make the GUI in CinePaint better than that in Photoshop. I've been itching to work on the CinePaint interface from day one, but infrastructure, stability, and cross-platform have had to come first."
Ok, you cited two things you like about Photoshop. Cool. Get on it. I expect plugins by the end of the month.
Seriously, is it so hard to read the *rest* of what I wrote? I was suggesting that a company take The Gimp, modify it as needed (contributing back the OSS parts, and keeping proprietary plugins for patented stuff that they will have to chage money for to pay royalties and fund their staff).
The Gimp is a pain in the ass to use, but most of what PS gives you above and beyond The Gimp in terms of real features center around the ready-for-print market (patents prevent much of this technology from entering The Gimp) and some of PS' advances layering features (again, likely patented). Their scaling and interpolation is nice (also probably patented, which again leads to my point), but rarely worthy of chosing them over a competitor. In fact 90% of the ready-for-print market cares about only 10 or so of PS' core features asside from simple image editing. Of those 10 or so features a good chunk are covered by patents, and that's really what's keeping PS afloat right now.
Create a company that can ship patented plug-ins for The Gimp, and you remove the barrier that has kept it a second-class citizen for so long. Of course, getting the starting capital would be tricky in today's market, but this is a huge area with lots of profit to be had. The early worm will most certainly get the worm.
Remember that the power of open source is that the larger and more complex the software that you're imitating/improving, the more of an edge you have because of the large community of contributors who have source code.
I hate to use the word, because it has particular political weight right now, but he is clearly a terrorist. That said, I'm glad he exists, and I applaud his actions.
Let me explain before your media-fed hind-brain demands my death (probably too late). Terrorism in its purest form is applying fear to achieve an agenda by performing acts intended to craft that fear and direct it. In this case, that fear is already present, and it's the reason for the situation. This guy is clearly trying to highten it (that phrase you cite is pretty clear evidence) and put CERT in the spot of being the bad-guy for letting their partners know before everyone else (assuming he is able to keep doing this). Regardless of how CERT spins this, the bottom line is that if they release info at all, they release it to the world on the time-table of a hostile's choosing. CERT will have to change.
So why do I approve? Simple logic. I'm assuming this guy isn't the smartest or most well-versed person in intrusion ever. I also don't trust just anyone who works for a major software vendor. Those two points made, I assume that our friend the terrorist here is not the only person who's all too happy to have early access to this information, but should not. The difference is that he's a) giving out the info so everyone else gets it too and b) creating a situation where CERT is incented to change their policies on the release of information. If he just released the info, CERT might get away with finding and squashing the leak. As long as he releases it in a "scary" way, it puts that much more pressure on CERT, and I honestly think that the people security admins have to fear the most already have their own private channels for early CERT notifications.
I don't trust CERT, but if they have info that I don't I'm not too worried. When CERT starts creating networks of people who have information I don't (and which can burn me in the wrong hands), I get scared. This guy is just directing that fear in a constructive way. I approve. I wish more "black hats" like him were out there keeping us honest and preventing us from fooling ourselves into a false sense of security.
Ok, so the Slashdot take is a bit sensational, and not fact-heavy, but Adobe does have a rather strong hold on the Mac-using image and publishing market. It seems to me that there's only a few things that have to happen for The Gimp to all but replace Photoshop for this purpose. All it really needs is some company to come along and give it a) plugins for dealing with patented color-management for ready-for-print applications (no problem as plugins with licensing, as long as you pay Adobe and the few other companies a royalty) and b) a Mac-native UI that fixes some of the basic brokenness of The Gimp's poor UI choices (e.g. the nearly un-navigatable menus).
Both of these tasks are many orders of magnitude smaller than rolling your own Photoshop replacement, and The Gimp has a far more flexible plugin architecture and tons of people who are happy to write plugins in C, scheme, Perl, Python and other languages!
Anyone have the money to kick something like this off? Consider this you Make Money Fast wakeup call!
And, if you need more of a push... there's CinePaint (ne "Film Gimp"), which you could integrate into your product and add a whole other market.
You're probably right (it sounds familliar), but it's been too long since I saw what guarantees they gave.
The problem is that Red Hat 8.0 really is being shipped *as* a desktop OS, not a server OS. Before Red Hat was all too happy to have you run a desktop, but they weren't too keen on supporting it.
With that change in focus, I think they're more likely to open up the definition of binary compatibility....
There is one and only one reason that Red Hat bumps the major number, and that's binary compatability. If you can't run binaries under it that you could in the previous release, then it can't have the same major-number. Period. Usually the reason for the change in binary compatibility is due to library changes (e.g. new major version of glibc).
Now, there may be political, marketing or contractual reasons that a major number is prefered, but since binary compatibility is not guaranteed between major releases, you'll usually find that the one leads to the other, and thus the original statement holds true (i.e. engineers are free to rev libs in a major release, so they do).
The reason that Red Hat would release a new major version so soon after 8.0 is almost certainly to track the latest desktop updates which have been fast-and-furious since 8.0 was released, especially from GNOME (2.2.x is FAR more reasonable than 2.0, which IMHO, Red Hat released too early).
While I imagine that was meant as a Troll, you cite a valid concern. That, of course, is why you want to direct grandma at a service provider that advertises their use of SpamAssassin, so that she doesn't have to know the details.
This, however, is Slashdot, and I do expect that slashdot_user.clue() > grandma.clue() if you know what I mean...
Ooops, forgot to note that you will probably want to install Razor2 (it's just flat-out amazingly cool, and far more reliable than Razor1). Go to sf.net and search for razor. Download and install it and THEN go through the steps I mentioned to download, configure and install SpamAssassin. If you already did that, you should be able to do a "force install Mail::SpamAssassin" from the CPAN prompt.
I've been using SpamAssassin for about a year now. It started out good, and got better. Now it's actually a little frightening how good it is.
If you want to try it out, you will (most likely) need your own machine handling mail (if you're a broadband or DSL user, this is easy enough, I'll assume you've made that step...)
Now, make sure Perl is installed.
Now, as root, type "perl -MCPAN -e shell" and follow the instructions to set up Perl's configuration system.
In that shell, type "install Mail::SpamAssassin".
Exit that shell and type "/etc/init.d/spamassassin start"
You will want to do what your OS prefers for making sure this starts at boot time, under Red Hat Linux, that's "/sbin/chkconfig --levels 35 spamassassin on"
Exit your root shell, and do the rest as your user account.
Assuming you use sendmail with procmail (see the SpamAssassin site for other MTA configuration steps), put:
:0fw | spamc -f
into your.procmailrc.
SpamAssassin is now doing its job. It just marks messages that it thinks are spam. See the example procmailrc on spamassassin.org for more information on how you can move the mail to another folder, delete it, or even more complex things. Also, there's a procmail bug that the example config can help you work around.
If you're doing this on a busy site, I recommend adding "-m 20" or so to your spamd command-line to throttle periods of intense mail delivery.
You can also configure SpamAssassin to do lots of useful stuff just the way you like it. There's a FAQ on your site that will walk you through it, but after the first time spamd handles mail for you, it will create a ".spamassassin/user_prefs" file that has good comments in it that guide you through common configuration needs (like whitelisting users).
First, I think the partent post was ment to be humor.
If you were able to lay aside your biases, you might even chuckle.
As for the war, there are certainly those that argue attacking Iraq is wrong. I won't take a stand on that because there are a number of reasons to support the argument that come down to a larger view of man's behavior and the ultimate benificiary of ones actions.
However, the response that you quote is a smoke-screen, so we don't have to dig all that deep to deal with the problem.
No one can effectively argue at this point that S.H. is not a brutal and unstable ruler. He's certainly not the man that I would put in charge of Iraq, nor would I flinch at pulling the trigger if I were in the front row when he gave a speach, and I happened to have a pistol on me.
That said, the current actions of the U.S. government have little to do with the quality of S.H.'s rulership. For one, we've been in the business of giving large amounts of money and trade to countries with equally repugnant civil rights records for decades, and ask Amnesty International about the U.S. track record on opposing torture and civil suppression. We practically pay extra for it (not to mention train for it) in Central and South America and Asia.
Now we're fighting for freedom in Iraq, and I have to ask: why? What's more, I have to ask: is this the way we want to go to war?
The last several times we've committed US troops to foreign conflict (in Asia, the Caribian, Persian Gulf, Kosovo and lesser conflicts in Africa), the President has made the decision to go to war, and the Congress has rubber-stamped the decision post-facto. We have a constitution, and while the language is somewhat vague (allowing Presidents avoid impeachment for such action), it is certainly clear that the intent of the constitution was never to allow this sort of large-scale conflict without a formal declaration of war.
Now, if we're stepping boldly into the 21st century and forgoing national conflict in preference for UN peacekeeping, then I'm all for it. However, if that process is implemented as "UN sets deadline for compliance; deadline expires; within minutes US sends 40 Tomahawk Cruise Missiles", then I think someone missed the point. No one at the UN decided that it was time to attack. The US invited a handful of its trusted allies who happen to be members of the UN join a US-operated and overwhelmingly US-staffed war against Iraq.
There is a delicate game the US has been playing in the middle-east for the last 50 years. We're trying to ensure that those who litterally control the fuel that the world's nations run on cannot blackmail us with it because of political tensions. Our financial and weapons support of Iraq vs Iran was an ideal example of this. It has earned us the hatred of just about everyone in the region, and even those who were once our allies have become reluctant partners only due to our overwhelming superiority in terms of military and power (e.g. Turkey).
We shall see where this goes, but let us not fool ourselves into thinking that we're fighting for the Iraqi people. Such a thing would be massively out of character for the United States.
This box is a planned follow-on to a lot of work Sun has been doing. We all know that they work on Gnome and ship it with newer versions of Solaris. We all know they had a terminal product that used Java.
What I think is interesting about this is the use of Linux as the OS base.
Why would Sun choose Linux? Well, for starters, they don't have an OS whose performance profile is best on lower-end hardware. For another, Linux supports not only lots of hardware (which does help Sun, but not as much as if they were deploying on random hardware) but also has dizzying arrays of extra goodies available if they decide they need it.
Solaris has always been a conservative OS, and they're not a desktop system, so to add in all of the things that they would want for a desktop, Sun could spend years modifying Solaris. On the other hand, modifying Linux to suit their needs is trivial.
I've heard a few voices saying over the past few years that Sun is going to dump Solaris for Linux. IMHO, this is a far more credible data-point in that direction than the absorbtion of Cobalt. A new product is an ideal place to test the theory....
On the server side, Solaris could be dumped in favor of Linux with about 1-2 years work. Sun's engineers certainly are capable of making the required changes (mostly hardware support for Sun's high-end hardware and bringing Solaris' high-performance threading, multi-processor support and NFS to the Linux kernel, along with some userland stuff like porting tools and the pkg system, though they might prefer to dump that for apt or rpm or apt+rpm).
The real question is: how badly does Sun need to cut OS development costs to stay afloat? They're hurting. Everyone buys into the idea that on the high-end, Sun's hardware is sweet. It's just that the costs of maintaining an entire OS just for a high-end hardware niche don't match up. Linux could give Sun the chance to cut costs, improve Linux (and thus score PR points) and ship their hardware without having to employ anyone to maintain "ls".
we're using somewhat different definitions of "open source" here. I [...] mean software for which the source code is available for inspection, not [...] rights to modify or redistribute[...]
That's a fine idea, it's just not "open source". The Open Source Initiative are the keepers of the actual definition of the term as it was originally coined by the founders of the OSI. They certify licenses on the basis of several criteria, of which access to source is only one. If you want to use another, looser defined term, feel free (pun intended), but let's not start re-defining a term which was coined specifically to avoid the ambiguity of previous terms (e.g. free software).
Sure, there are a few mass-market applications (office suites, database tools, networking tools and operating system stuff, basically) that nearly everyone uses, and a few more that are big enough to be worth putting in with them (things like basic art programs, programming tools, mathematical toolkits and other such generalised techie toys).
Wow! Talk about some sweeping categories (and I'll note that this article/thread is about a company whose software would fit smack-into the middle of one of them).
Yes, I see your general point. You're saying that software that is written for a narrow, industry-specific purpose is not going to have a huge ground-swell of developers and what's more companies will be reluctant to release their code.
You're right of course, and that's why you don't see tons of mutual fund weighting applications on Sourceforge, even though there are many that have been written.
I think you're grading on the wrong curve. You're looking at the areas that open source development is just starting to apply pressure, in industries where change is often glacial and comparing it to the software, networking and computer hardware industries which are still getting their feet, and are evolving at a frightening pace. Of course, you see the largest impact in these areas.
But that does not change the fact that open source development is about coming to terms with the fact that software on its own has no value. Branding and control have value. The ability to reduce costs has value. Software can help you achive these goals, so it can help you to realize value, but it has none of its own.
Large, non-high-tech companies are starting to figure this out, but in many cases it may be too late. How can a large, established company compete with its upstart competition if five of them are sharing the costs of developing internal software? It's a scary proposition for an established company, but if you build (or re-build) an industry around the idea that software is worthless, you can cut costs, improve quality and improve maintenance efficiency. It's going to hurt to compete against that....
you can go and download OpenOffice, Mozilla, Linux, etc. right now and ditch MS proprietary software altogether, and yet most people don't. You have to stop and ask why that is
I find myself asking how the rate of change could have been so high. MS and proprietary UNIX owned the server market 5 years ago and MS owned the desktop with only a small amount of pressure from Apple. Another 5 years and Sun will probably have to throw out proprietary software. Microsoft already sees the writing on that particular wall, but the desktop market has been their safe-haven.
In the last 3 years open source desktops have gone from hacker toys that scared anyone else who saw them to the slick desktop I'm using right now, and which I use for work as well. The open source desktop (in its various forms) is fairly new and the first volleys were pre-mature. The next wave of dekstop platforms will be from Red Hat, IBM, Sun, Dell and a few other giants in varying degrees of competition and/or cooperation. In anot
"Open source" is a term coined by ESR (I'm pretty sure, he was at least the first person I heard pushing it) which refers to the general physical property of having access to source code in a "useful way".
"Free software" is a term coined by Richard Stallman to indicate a way of thinking about software and its impact on those with whom you collaborate.
While what I said would play into RMS' definition of free software just fine, the very act of giving people the source code to your software and giving people the right to modify and distribute it is a denial of the sort of value-proposition that has dominated the software business for the last 20 years.
I'm not pushing the free software "we should all just get along" party line here, just pointing out that when you deny such a value proposition, you're going to have responses like, "well, why should I hand you my wallet?!" The only appropriate answer is, "don't bother, someone else will."
That's why open source software is unstoppable. It's not that the software's better (sometimes it is, but that's not the point); it's not that it's going to make your business more money.
The reason it's unstoppable is because it's not a physical phenomenon, but a change in the vlaue proposition. Software isn't really valuable, but we've been acting like it was for 30 years because we weren't yet sure what to do about programmers (who *are* valuable). At first, we put programmers into the same mold as producers of physical property, but that's not quite right. The econmics are totaly different.
Open source is the natural evolution of the market, and old-school companies that ask "why" they should adapt will soon find that they don't care why so much as "how" and "how fast". The first shot heard 'round the world was Netscape. The next was Apache. Both of these pieces of software, in the early-90s model, should have been gigantic money-makers that sold for hundreds or thousands of dollars. Netscape was given away for free, and eventually open sourced in the face of competition from another free product.
Think about that. Don't think about it in terms of business success, think of it in terms of business failure! The single most imortant interface between the end-user and the late-90s phenomenon that was the.com-era-Internet wasn't worth a dime, and yet it took over the market as a free product and was eventually replaced by another free product!
Same goes for the world's most popular Web server. Same goes for the world's most popular mail server, domain name server, etc, etc.
The value proposition has changed, and all of the manuevering you're going to see in the next 5-10 years is basically just the death-throws of software-as-valuable-commodity.
Even patents are just a speed-bump. The reality is that the gold-rush in software patent applications over the last 10 years will mean that in another 20 or less years, there won't be a whole lot of fundamental technique left to patent in software (sure, new application techniques will be fair game, but even then avoiding prior art will be a legal mine-field which IBM et al will be all too happy to challenge you on), and the old patents will all be expiring, which allows existing open source projects to absorb the now time-tested choice bits of technology (e.g. the way RSA was absorbed in a ground-swell of OSS development after the patent expired).
So, you see, I don't care about the politics or the touchy-feely Stallman crusade. I don't think most of that is realistic. What I do find interesting is that there are still people in the world who can watch giant companies giving away their software and they still think that there's going to be a market for their closed-source applications in 5 years.
You're absolutely right, and here's how you convince the lay-person. Don't allow for the physical mail metaphor (there's a reason people use email FAR more than they ever used physical mail). Instead use this one:
Imagine a world were everyone walked around with sound-proof ear muffs and charged you a penny for them to listen to what you have to say. Would you ever know what was going on? Worse, imagine a world where only certain people did this? Would those people or the people who didn't have ear-muffs be hired for jobs, be promoted, meet new friends, etc.
Seriously, as I discussed in the answer to question #2, I haven't seen a way to provide Reasoning's shareholders with an equivalent (much less superior) return by making our source code Open. I think this is one of the most significant challenges that advocates of Open Source have yet to successfully address.
And advocates of Open Source never will, nor should they try.
Your products will: survive because they are unreproducable; survive because they go open source; or be replaced by an open source package that ships with 20 operating system distributions a month after its first stable release.
Roll those dice however you like. "Open Source advocates" shouldn't have to care, and we CERTAINLY should not have to hand-hold you through the decision. If you were making the decision for more than econimic reasons, then we could talk, but open source software development is fundamentally the denial of the idea that software is a valuable commodity (rather that programmers and support), so we're not going to help you understand how to preserve its status as such.
Ok, this is a linux tangent in a XFree thread, but it's important that this get addressed.
The platonic ideal here would certainly be to have a development process that produced working kernels instantly and reliably when new hardware support or features were added. Back in the real world, large software projects need time to integrate. One project may be done with their work in terms of their niche, but that usually means that the integration and testing work has just begun. Impact on other yet-to-be integrated pieces needs to be evaluated, etc.
Also, there's the painful process of choosing which features to NOT back-port to older versions. This is especially hard when a change is made in a development version, but desired in a stable version.
Microsoft and every other software company goes through the same process. You'll always be able to point out examples (e.g. how long do you think MS had USB support for NT before it became available?)
There's this perception in the open source world that the existance of code should necessitate its use in every project, packaging and distribution, etc. I'd personally be happier if Linux were as slow as XFree86 to absorb new code. It hurts because I want the new features, but I'm a happier camper when the software works and fringe cases aren't catastrophic.
Slashdot Mirror
Your interpretation of how GCC's various front-ends and back-ends work together, and where optimization happens is a bit skewed. For the most part, if GCC-ADA is poorly optimized, it's no one's fault but the ADA-front end folks. This is because GCC's intermediate represenation (RTL) is essentially treaded as an "assembly" by the front-ends. They compile the code into a syntax tree, optimize where the language allows such optimization, transform that into RTL (at which stage "ADA types" are pretty much gone, and much lower level types have come into play) and then the back-end turns that into assembly and sends it to the assebler.
That sounded a lot cleaner than it really is. At least one of those transformations (syntax tree to RTL) isn't really performed at all, and there's a lot that the ADA-front end has to know about the target platform that it finds out from the various platform specifications that GCC's back-end uses.
Still, the back-end is responsible only for os and machine-specific optimizations and so-called "peephole" optimizations.
As for C being the enemy of proper optimization, I think you're looking a little too hard for a culprit. The real enemy of strong optimization is processor speed. If processors doubled in speed every 20 years, you would see a great deal more effort going into optimization. As it is, the perception is that only obsessives care about those "few extra cycles", which is rather sad. Still a lot of good work is done, and the fact that high-level languages has been flourishing in the last 10 years has really put the screws to the compiler writers to keep up.
Ok, so your statements have gone from generic "low level languages are no faster than high level" to a defense of JIT compilers.
Fair enough, and I can roll with that. Yes, you will get a performance boost by optimizing code for a particular platform on-the-fly.
How much? Hard to tell, since the difference even between two compilers on the *same* platform can be so very different.
What is very certain though is that the largest hit in this is the language. I'm actually surprised that you don't realize that. It's not a slam against C++ to say that its more complex type and exception system slows code down. It's just the cost of abstraction. It's not a slam against Java to say that it's platform-indepenance comes with a speed penanly. It's just what you have to deal with in order to get Java's level of abstraction.
Seriously, if compiler technology were the only barrier to fast code, then the fastest programming language in the world would be LISP, since it pre-dates computers.
And yet, LISP is slow. Why? Mostly because managing everything as a list isn't what modern processors do best, but also because there's an awful lot that a programmer doesn't have to tell LISP in order to get a program to work.
Same goes for Java, just less so. Same goes for C++, just less so still.
C++ is an interesting case. It tries to be a high-level language while maintaining all of the low-level features of C. This has the interesting effect that you can write slower code that is very abstract and quick to write, or you can write very efficient code that requires more manual bit-twiddling (so to speak). The cost comes in the difficulty of maintaining any particular piece of C++, but for some it's worth it.
I really love the very idea of programming languages. They're all very cool as far as I'm concerned (even humble COBOL had its day and there are a few places that TCL is quite interesting). Don't focus on one language and then set out to prove why it's the best tool for all jobs, because pretty much by definition that's not true. Once you've learned about 10 of them and assembly for a few instruction sets, you really begin to get a sense of how wonderfully complex all of the tradeoffs in programming languages are, just as with spoken languages.
Good luck and enjoy!
I understand your points, and I did take them all into account in my original post.
A compiler can simply optimize large blocks of code better than you can
Yes, and no. It can optimize a large block of code better within the constraints of the language.
A great example of this is C vs aseembly. You say:
so for sufficiently large apps, the C version will almost always be faster than the assembler version, because it can find neat optimizations you didn't think of
You are talking about optimization, and that's cool. I'm not. I'm talking about abstraction. The job of a language includes making certain performance trade-off considerations in favor of development flexibility and maintainability (among other, lesser goals like re-usability, etc)
When a language makes those choices, it's kind of counter-productive to then allow you to violate them. Thus, C imposes scoping, typing, etc. These features all come with performance penalties, but they make writing and maintaining code easier. It's possible to optmize away scoping in a great many cases, but not all (e.g. you can inline, flatten scopes, etc). Ultimately the assembly programmer is going to make *casual* choices which are more optimal because he's looking at the code. It's not a matter of optimization, but of context.
Already many C compilers ignore the 'register' keyword, because they know they can do a better job allocating registers than you can.
That's not at all why they ignore that keyword, and I'm stunned that you think that! The reason that they ignore the keyword is because it's nearly useless except for a handful of architectures. I assure you that if C provided a sophisticated, portable interface to register selection, it would be a boon for program execution everywhere.
The problem in C is that you can only turn on or off a boolean bit, "is this stored in a register". Since the compiler has access to knowledge about the platform it is capable of dealing with virtual registers and register-banks in ways that that simple boolean keyword cannot.
This has absolutely no bearing on the assembly programmer who will be managing those registers to a degree that even C cannot match because it doesn't know what your code execution profile is likely to look like (there are optmizers in the world that re-optimize your program based on profiler output, but they tend to be of limited value because even analyzing profiler output is frought with dangers that only hard AI can tackle).
Please understand here, that I'm not some cranky old man pining for the days of VAX assembly. I'm nto saying that you *want* to write everything in C or even assembly. I'm saying that deluding yourself into thinking that a high-level language like Python, Scheme, Perl, LISP, etc, etc will ever have the performance of a low-level language is pointless. It simply cannot happen until compilers are smart enough to throw away what you wrote, reverse-engineer a set of requirements and re-write it in a lower-level language.
These high-level languages WILL get better. They will get faster as compiler technology progresses, but given the same access to hardware instructions, and hardware that isn't specially designed for one or another high-level language, you will always tend to write less abstract code, and therefor more optimal performing code, in a lower level language.
Go find example programs whose performance characteristics in C vs Java, Smalltalk or any other higher-level language disprove that. Even C++ that looks just like C has to deal with exceptions, dynamic scoping and type conversion that C does not, and the compiler cannot always know if/when those will come into play! It gets worse once you go up to Java where native hardware types get virtualized and have behaviors that are convinient, but costly. Worse still when you go up into LISP where data is code, and both are run-time modifiable.
But, in each of these cases there are significant improvements in the level of detail which the programmer must manage. You take the performance hit because you gain in other ways.
At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
If that was intended as a joke, it's pretty funny. Otherwise, you need to hit the books.
C is "fast" because it's a low-level language. C++, ADA, Perl, C#, LISP, Python, Java, Scheme, etc are "slow" in comparison because their relative levels of abstraction add a performance penalty.
The same can be said (and is, and is correct) of assembly vs. C. C is "slow" in respect to assembly because assembly lacks the abstraction of lexical scope, typing, automatic stack handling, etc.
This is not a theory, it's simple definition of terms.
If you're trying to advocate VMs or other forms of interpreted execution, there are some excellent reasons on which to base your case. Execution speed that will one day magically match that of the same program written in C is most certainly not one of them (assuming that we don't get strong AI any time soon, and build a JIT around it).
And the answer is... RTFA ;-)
My bad, wrong kind of "network". While the idea may be applicable to computer-interconnectivity, that's not what this is about, and I would have known that, had I read the article.
Thanks anyway, all!
I don't know a lot about the state-of-the-art in the area of network discovery/repair other than what I know as a socket-programmer and sysadmin, but I'm wondering if someone who does know can point out the differences between, say, this research and Apple's Rendezvous (not to be confused with Tibco's product by the same name)?
It seems to me that the basic goals are similar, but with Apple focusing more on the engineering side of solving a user-problem rather than passing the point of diminishing returns on "correct" solutions. Please, feel free to enlighten me though. This stuff is actually really promising, and I hope to live in a world 5 years from now where my laptop just "fits in" to the network that it's placed on in more ways than mere DHCP can accomodate.
Thanks!
I suggest you look into CinePaint (ne Film Gimp), as it sounds like that would suit your needs more than the classic Gimp.
The Gimp is an excellent "basic photo editor", which for those of you who can recall what things were like 6 years ago, is basically the root of what Photoshop was. All we need is for someone to come along and finish the job.
The Gimp folks are going the long, slow route of trying to fix everyone's problems at once. This works for OSS, ala Mozilla, but the results are slow, and many will wander away before its done.
The CinePaint folks are doing the big-return stuff first because they have a specific niche to serve. I'll be very interested to see where it all goes....
Here's what I said on that very topic:
There's this sort of give-and-take to the patent system. It doesn't allow you to hide a technique for 2 decades, it lets you be the primary benificiary of that technique. The way it does this is to require you to license your technique under "reasonable terms" (read, what the market will bear).So, a company that build their product around The Gimp could keep all of the patent-related goodies in plugins (perhaps changing some of the plugin API where required to make more core-related features pluginable), and only distribute those plugins for a fee, along with support, etc.
The fee would go to pay business costs as well as paying the royalty fees. You can still contribute the bulk of your work back to The Gimp, and you can still benefit from the development being done on it, but you get neatly around PhotoShop's patents for customers who need those features.
Check out this glowing article about CinePaint for more, but here's a quote:
Ok, you cited two things you like about Photoshop. Cool. Get on it. I expect plugins by the end of the month.
Seriously, is it so hard to read the *rest* of what I wrote? I was suggesting that a company take The Gimp, modify it as needed (contributing back the OSS parts, and keeping proprietary plugins for patented stuff that they will have to chage money for to pay royalties and fund their staff).
The Gimp is a pain in the ass to use, but most of what PS gives you above and beyond The Gimp in terms of real features center around the ready-for-print market (patents prevent much of this technology from entering The Gimp) and some of PS' advances layering features (again, likely patented). Their scaling and interpolation is nice (also probably patented, which again leads to my point), but rarely worthy of chosing them over a competitor. In fact 90% of the ready-for-print market cares about only 10 or so of PS' core features asside from simple image editing. Of those 10 or so features a good chunk are covered by patents, and that's really what's keeping PS afloat right now.
Create a company that can ship patented plug-ins for The Gimp, and you remove the barrier that has kept it a second-class citizen for so long. Of course, getting the starting capital would be tricky in today's market, but this is a huge area with lots of profit to be had. The early worm will most certainly get the worm.
Remember that the power of open source is that the larger and more complex the software that you're imitating/improving, the more of an edge you have because of the large community of contributors who have source code.
I hate to use the word, because it has particular political weight right now, but he is clearly a terrorist. That said, I'm glad he exists, and I applaud his actions.
Let me explain before your media-fed hind-brain demands my death (probably too late). Terrorism in its purest form is applying fear to achieve an agenda by performing acts intended to craft that fear and direct it. In this case, that fear is already present, and it's the reason for the situation. This guy is clearly trying to highten it (that phrase you cite is pretty clear evidence) and put CERT in the spot of being the bad-guy for letting their partners know before everyone else (assuming he is able to keep doing this). Regardless of how CERT spins this, the bottom line is that if they release info at all, they release it to the world on the time-table of a hostile's choosing. CERT will have to change.
So why do I approve? Simple logic. I'm assuming this guy isn't the smartest or most well-versed person in intrusion ever. I also don't trust just anyone who works for a major software vendor. Those two points made, I assume that our friend the terrorist here is not the only person who's all too happy to have early access to this information, but should not. The difference is that he's a) giving out the info so everyone else gets it too and b) creating a situation where CERT is incented to change their policies on the release of information. If he just released the info, CERT might get away with finding and squashing the leak. As long as he releases it in a "scary" way, it puts that much more pressure on CERT, and I honestly think that the people security admins have to fear the most already have their own private channels for early CERT notifications.
I don't trust CERT, but if they have info that I don't I'm not too worried. When CERT starts creating networks of people who have information I don't (and which can burn me in the wrong hands), I get scared. This guy is just directing that fear in a constructive way. I approve. I wish more "black hats" like him were out there keeping us honest and preventing us from fooling ourselves into a false sense of security.
Ok, so the Slashdot take is a bit sensational, and not fact-heavy, but Adobe does have a rather strong hold on the Mac-using image and publishing market. It seems to me that there's only a few things that have to happen for The Gimp to all but replace Photoshop for this purpose. All it really needs is some company to come along and give it a) plugins for dealing with patented color-management for ready-for-print applications (no problem as plugins with licensing, as long as you pay Adobe and the few other companies a royalty) and b) a Mac-native UI that fixes some of the basic brokenness of The Gimp's poor UI choices (e.g. the nearly un-navigatable menus).
Both of these tasks are many orders of magnitude smaller than rolling your own Photoshop replacement, and The Gimp has a far more flexible plugin architecture and tons of people who are happy to write plugins in C, scheme, Perl, Python and other languages!
Anyone have the money to kick something like this off? Consider this you Make Money Fast wakeup call!
And, if you need more of a push... there's CinePaint (ne "Film Gimp"), which you could integrate into your product and add a whole other market.
You're probably right (it sounds familliar), but it's been too long since I saw what guarantees they gave.
The problem is that Red Hat 8.0 really is being shipped *as* a desktop OS, not a server OS. Before Red Hat was all too happy to have you run a desktop, but they weren't too keen on supporting it.
With that change in focus, I think they're more likely to open up the definition of binary compatibility....
There is one and only one reason that Red Hat bumps the major number, and that's binary compatability. If you can't run binaries under it that you could in the previous release, then it can't have the same major-number. Period. Usually the reason for the change in binary compatibility is due to library changes (e.g. new major version of glibc).
Now, there may be political, marketing or contractual reasons that a major number is prefered, but since binary compatibility is not guaranteed between major releases, you'll usually find that the one leads to the other, and thus the original statement holds true (i.e. engineers are free to rev libs in a major release, so they do).
The reason that Red Hat would release a new major version so soon after 8.0 is almost certainly to track the latest desktop updates which have been fast-and-furious since 8.0 was released, especially from GNOME (2.2.x is FAR more reasonable than 2.0, which IMHO, Red Hat released too early).
While I imagine that was meant as a Troll, you cite a valid concern. That, of course, is why you want to direct grandma at a service provider that advertises their use of SpamAssassin, so that she doesn't have to know the details.
This, however, is Slashdot, and I do expect that slashdot_user.clue() > grandma.clue() if you know what I mean...
Ooops, forgot to note that you will probably want to install Razor2 (it's just flat-out amazingly cool, and far more reliable than Razor1). Go to sf.net and search for razor. Download and install it and THEN go through the steps I mentioned to download, configure and install SpamAssassin. If you already did that, you should be able to do a "force install Mail::SpamAssassin" from the CPAN prompt.
If you want to try it out, you will (most likely) need your own machine handling mail (if you're a broadband or DSL user, this is easy enough, I'll assume you've made that step...)
Now, make sure Perl is installed.
Now, as root, type "perl -MCPAN -e shell" and follow the instructions to set up Perl's configuration system.
In that shell, type "install Mail::SpamAssassin".
Exit that shell and type "/etc/init.d/spamassassin start"
You will want to do what your OS prefers for making sure this starts at boot time, under Red Hat Linux, that's "/sbin/chkconfig --levels 35 spamassassin on"
Exit your root shell, and do the rest as your user account.
Assuming you use sendmail with procmail (see the SpamAssassin site for other MTA configuration steps), put:into your
SpamAssassin is now doing its job. It just marks messages that it thinks are spam. See the example procmailrc on spamassassin.org for more information on how you can move the mail to another folder, delete it, or even more complex things. Also, there's a procmail bug that the example config can help you work around.
If you're doing this on a busy site, I recommend adding "-m 20" or so to your spamd command-line to throttle periods of intense mail delivery.
You can also configure SpamAssassin to do lots of useful stuff just the way you like it. There's a FAQ on your site that will walk you through it, but after the first time spamd handles mail for you, it will create a ".spamassassin/user_prefs" file that has good comments in it that guide you through common configuration needs (like whitelisting users).
First, I think the partent post was ment to be humor.
If you were able to lay aside your biases, you might even chuckle.
As for the war, there are certainly those that argue attacking Iraq is wrong. I won't take a stand on that because there are a number of reasons to support the argument that come down to a larger view of man's behavior and the ultimate benificiary of ones actions.
However, the response that you quote is a smoke-screen, so we don't have to dig all that deep to deal with the problem.
No one can effectively argue at this point that S.H. is not a brutal and unstable ruler. He's certainly not the man that I would put in charge of Iraq, nor would I flinch at pulling the trigger if I were in the front row when he gave a speach, and I happened to have a pistol on me.
That said, the current actions of the U.S. government have little to do with the quality of S.H.'s rulership. For one, we've been in the business of giving large amounts of money and trade to countries with equally repugnant civil rights records for decades, and ask Amnesty International about the U.S. track record on opposing torture and civil suppression. We practically pay extra for it (not to mention train for it) in Central and South America and Asia.
Now we're fighting for freedom in Iraq, and I have to ask: why? What's more, I have to ask: is this the way we want to go to war?
The last several times we've committed US troops to foreign conflict (in Asia, the Caribian, Persian Gulf, Kosovo and lesser conflicts in Africa), the President has made the decision to go to war, and the Congress has rubber-stamped the decision post-facto. We have a constitution, and while the language is somewhat vague (allowing Presidents avoid impeachment for such action), it is certainly clear that the intent of the constitution was never to allow this sort of large-scale conflict without a formal declaration of war.
Now, if we're stepping boldly into the 21st century and forgoing national conflict in preference for UN peacekeeping, then I'm all for it. However, if that process is implemented as "UN sets deadline for compliance; deadline expires; within minutes US sends 40 Tomahawk Cruise Missiles", then I think someone missed the point. No one at the UN decided that it was time to attack. The US invited a handful of its trusted allies who happen to be members of the UN join a US-operated and overwhelmingly US-staffed war against Iraq.
There is a delicate game the US has been playing in the middle-east for the last 50 years. We're trying to ensure that those who litterally control the fuel that the world's nations run on cannot blackmail us with it because of political tensions. Our financial and weapons support of Iraq vs Iran was an ideal example of this. It has earned us the hatred of just about everyone in the region, and even those who were once our allies have become reluctant partners only due to our overwhelming superiority in terms of military and power (e.g. Turkey).
We shall see where this goes, but let us not fool ourselves into thinking that we're fighting for the Iraqi people. Such a thing would be massively out of character for the United States.
This box is a planned follow-on to a lot of work Sun has been doing. We all know that they work on Gnome and ship it with newer versions of Solaris. We all know they had a terminal product that used Java.
What I think is interesting about this is the use of Linux as the OS base.
Why would Sun choose Linux? Well, for starters, they don't have an OS whose performance profile is best on lower-end hardware. For another, Linux supports not only lots of hardware (which does help Sun, but not as much as if they were deploying on random hardware) but also has dizzying arrays of extra goodies available if they decide they need it.
Solaris has always been a conservative OS, and they're not a desktop system, so to add in all of the things that they would want for a desktop, Sun could spend years modifying Solaris. On the other hand, modifying Linux to suit their needs is trivial.
I've heard a few voices saying over the past few years that Sun is going to dump Solaris for Linux. IMHO, this is a far more credible data-point in that direction than the absorbtion of Cobalt. A new product is an ideal place to test the theory....
On the server side, Solaris could be dumped in favor of Linux with about 1-2 years work. Sun's engineers certainly are capable of making the required changes (mostly hardware support for Sun's high-end hardware and bringing Solaris' high-performance threading, multi-processor support and NFS to the Linux kernel, along with some userland stuff like porting tools and the pkg system, though they might prefer to dump that for apt or rpm or apt+rpm).
The real question is: how badly does Sun need to cut OS development costs to stay afloat? They're hurting. Everyone buys into the idea that on the high-end, Sun's hardware is sweet. It's just that the costs of maintaining an entire OS just for a high-end hardware niche don't match up. Linux could give Sun the chance to cut costs, improve Linux (and thus score PR points) and ship their hardware without having to employ anyone to maintain "ls".
That's a fine idea, it's just not "open source". The Open Source Initiative are the keepers of the actual definition of the term as it was originally coined by the founders of the OSI. They certify licenses on the basis of several criteria, of which access to source is only one. If you want to use another, looser defined term, feel free (pun intended), but let's not start re-defining a term which was coined specifically to avoid the ambiguity of previous terms (e.g. free software).
Wow! Talk about some sweeping categories (and I'll note that this article/thread is about a company whose software would fit smack-into the middle of one of them).
Yes, I see your general point. You're saying that software that is written for a narrow, industry-specific purpose is not going to have a huge ground-swell of developers and what's more companies will be reluctant to release their code.
You're right of course, and that's why you don't see tons of mutual fund weighting applications on Sourceforge, even though there are many that have been written.
I think you're grading on the wrong curve. You're looking at the areas that open source development is just starting to apply pressure, in industries where change is often glacial and comparing it to the software, networking and computer hardware industries which are still getting their feet, and are evolving at a frightening pace. Of course, you see the largest impact in these areas.
But that does not change the fact that open source development is about coming to terms with the fact that software on its own has no value. Branding and control have value. The ability to reduce costs has value. Software can help you achive these goals, so it can help you to realize value, but it has none of its own.
Large, non-high-tech companies are starting to figure this out, but in many cases it may be too late. How can a large, established company compete with its upstart competition if five of them are sharing the costs of developing internal software? It's a scary proposition for an established company, but if you build (or re-build) an industry around the idea that software is worthless, you can cut costs, improve quality and improve maintenance efficiency. It's going to hurt to compete against that....
I find myself asking how the rate of change could have been so high. MS and proprietary UNIX owned the server market 5 years ago and MS owned the desktop with only a small amount of pressure from Apple. Another 5 years and Sun will probably have to throw out proprietary software. Microsoft already sees the writing on that particular wall, but the desktop market has been their safe-haven.
In the last 3 years open source desktops have gone from hacker toys that scared anyone else who saw them to the slick desktop I'm using right now, and which I use for work as well. The open source desktop (in its various forms) is fairly new and the first volleys were pre-mature. The next wave of dekstop platforms will be from Red Hat, IBM, Sun, Dell and a few other giants in varying degrees of competition and/or cooperation. In anot
No, not at all.
.com-era-Internet wasn't worth a dime, and yet it took over the market as a free product and was eventually replaced by another free product!
"Open source" is a term coined by ESR (I'm pretty sure, he was at least the first person I heard pushing it) which refers to the general physical property of having access to source code in a "useful way".
"Free software" is a term coined by Richard Stallman to indicate a way of thinking about software and its impact on those with whom you collaborate.
While what I said would play into RMS' definition of free software just fine, the very act of giving people the source code to your software and giving people the right to modify and distribute it is a denial of the sort of value-proposition that has dominated the software business for the last 20 years.
I'm not pushing the free software "we should all just get along" party line here, just pointing out that when you deny such a value proposition, you're going to have responses like, "well, why should I hand you my wallet?!" The only appropriate answer is, "don't bother, someone else will."
That's why open source software is unstoppable. It's not that the software's better (sometimes it is, but that's not the point); it's not that it's going to make your business more money.
The reason it's unstoppable is because it's not a physical phenomenon, but a change in the vlaue proposition. Software isn't really valuable, but we've been acting like it was for 30 years because we weren't yet sure what to do about programmers (who *are* valuable). At first, we put programmers into the same mold as producers of physical property, but that's not quite right. The econmics are totaly different.
Open source is the natural evolution of the market, and old-school companies that ask "why" they should adapt will soon find that they don't care why so much as "how" and "how fast". The first shot heard 'round the world was Netscape. The next was Apache. Both of these pieces of software, in the early-90s model, should have been gigantic money-makers that sold for hundreds or thousands of dollars. Netscape was given away for free, and eventually open sourced in the face of competition from another free product.
Think about that. Don't think about it in terms of business success, think of it in terms of business failure! The single most imortant interface between the end-user and the late-90s phenomenon that was the
Same goes for the world's most popular Web server. Same goes for the world's most popular mail server, domain name server, etc, etc.
The value proposition has changed, and all of the manuevering you're going to see in the next 5-10 years is basically just the death-throws of software-as-valuable-commodity.
Even patents are just a speed-bump. The reality is that the gold-rush in software patent applications over the last 10 years will mean that in another 20 or less years, there won't be a whole lot of fundamental technique left to patent in software (sure, new application techniques will be fair game, but even then avoiding prior art will be a legal mine-field which IBM et al will be all too happy to challenge you on), and the old patents will all be expiring, which allows existing open source projects to absorb the now time-tested choice bits of technology (e.g. the way RSA was absorbed in a ground-swell of OSS development after the patent expired).
So, you see, I don't care about the politics or the touchy-feely Stallman crusade. I don't think most of that is realistic. What I do find interesting is that there are still people in the world who can watch giant companies giving away their software and they still think that there's going to be a market for their closed-source applications in 5 years.
You're absolutely right, and here's how you convince the lay-person. Don't allow for the physical mail metaphor (there's a reason people use email FAR more than they ever used physical mail). Instead use this one:
Imagine a world were everyone walked around with sound-proof ear muffs and charged you a penny for them to listen to what you have to say. Would you ever know what was going on? Worse, imagine a world where only certain people did this? Would those people or the people who didn't have ear-muffs be hired for jobs, be promoted, meet new friends, etc.
Hint to moderators, the parent is no more insightful than it is coherent.
"It's un-friggin ridiculous how damn much IBM..."
I'm going to have to get out the big parsing guns for this one...
"Honestly, I'm surprised IBM charges as much as they do with all the payroll savings they now have from sending jobs over to India"
And this is related... how?
Supporting evidence?
Seriously, as I discussed in the answer to question #2, I haven't seen a way to provide Reasoning's shareholders with an equivalent (much less superior) return by making our source code Open. I think this is one of the most significant challenges that advocates of Open Source have yet to successfully address.
And advocates of Open Source never will, nor should they try.
Your products will: survive because they are unreproducable; survive because they go open source; or be replaced by an open source package that ships with 20 operating system distributions a month after its first stable release.
Roll those dice however you like. "Open Source advocates" shouldn't have to care, and we CERTAINLY should not have to hand-hold you through the decision. If you were making the decision for more than econimic reasons, then we could talk, but open source software development is fundamentally the denial of the idea that software is a valuable commodity (rather that programmers and support), so we're not going to help you understand how to preserve its status as such.
Ok, this is a linux tangent in a XFree thread, but it's important that this get addressed.
The platonic ideal here would certainly be to have a development process that produced working kernels instantly and reliably when new hardware support or features were added. Back in the real world, large software projects need time to integrate. One project may be done with their work in terms of their niche, but that usually means that the integration and testing work has just begun. Impact on other yet-to-be integrated pieces needs to be evaluated, etc.
Also, there's the painful process of choosing which features to NOT back-port to older versions. This is especially hard when a change is made in a development version, but desired in a stable version.
Microsoft and every other software company goes through the same process. You'll always be able to point out examples (e.g. how long do you think MS had USB support for NT before it became available?)
There's this perception in the open source world that the existance of code should necessitate its use in every project, packaging and distribution, etc. I'd personally be happier if Linux were as slow as XFree86 to absorb new code. It hurts because I want the new features, but I'm a happier camper when the software works and fringe cases aren't catastrophic.