It's nearly trivial to detect whether users are actually blocking (i.e., not downloading) ads, so why not just block people who block ads?
Blocking a particular browser doesn't make sense; there are ad-block solutions for every browser, and it is easy for browsers to lie about who they are. This "campaign" sounds like Microsoft astroturfing.
Why doesn't IBM just buy Sun? They'd get control of Java and Solaris, they could kill the Sun/Microsoft dealings, and they'd get Sun's server customers. Granted, at 16B, Sun is probably still somewhat overvalued, but I think such a deal would be good for IBM overall.
Everything has a cost. Linux generally costs me a lot of time -- more time than it's worth to me
Not as much as Windows. Windows installation and maintenance is a bitch.
from compatibility issues and poor hardware vendor support to the general PITA of learning the nuances of a particular version of a given distribution.
So you prefer writing a list container for each type. Or a void* cast.
No; I have no problem with parameterized types. We're discussing metaprogramming and generic programming.
The point is the *possibility* of efficient, specialized versions. As said, std::fill with a vector can be reduced to a simple memset. At compile-time. No branches, no overhead, no indirections.
Yes, manually creating specialized versions is a good thing for efficiency. My point is that it is the exact opposite of metaprogramming or generic programming. The very fact that library authors manually specialize std::fill tells you that the generic version is inefficient and that metaprogramming has failed for that type.
(Quite separately from that, I'm making the point that overloading vector<bool> with bit_vector has a number of other problems.)
See they are NOT in the same league. These languages offer wonderful constructs which allow generic programming even at run-time - but at a cost. I like templates because they are generic at *compile-time*, which yields a significant performance boost.
First, several of the languages I mentioned do offer compile-time metaprogramming (ML, Haskell, etc.). Second, the distinction between compile-time and runtime disappears when JITs enter the picture; JITs permit generic programming and metaprogramming using existing object-oriented techniques, without the complexity of adding a separate static programming language. JITs basically make static metaprogramming facilities obsolete (Java/JVM got a few details wrong, but the next generation or two will fix that).
As for performance, I write performance critical code in C++; it sounds to me like you really do not. Why? Because of statements like "An unpacked version makes absolutely no sense, since it is semantically identical." and "The point is the *possibility* of efficient, specialized versions." In fact, when performance matters, the difference between a packed and an unpacked boolean array can be big, and the difference between a possible and an actual specialized version is crucial.
Right but that's a matter of the anti-aliasing filter which is used before the actual sampling.
Well, yeah, but since there are no ideal anti-aliasing filters and since real-world signals are not band-limited, you can't just design sampling rates based on twice the frequency limit of human hearing.
In fact, there is little need to sample so close to the Nyquist limit; it's safer to sample at very high frequencies during recording and playback and make decisions about what to represent in the compressor, giving you the same bitrate. The only reason we're stuck with 44kHz is historical--fast signal processors used to be expensive.
Not ideal, but since the applications are so rarely informed when they are out of memory in these days and times
That's an incorrect assumption; desktop machines run out of memory all the time, and when they do, this kind of code loses data.
KDE is an X-only application. It is exactly as portable as it should be.
This code fails on lots of platforms on which X runs.
Limiting the language to avoid surprises is a hopeless endeavor, which I'd advice against.
This isn't about "surprises", it's about the fact that in C/C++, you simply cannot reason reliably about programs; writing robust programs in C/C++ is enormously hard and unnecessarily expensive.
But I would like to hear what you suggest in it's stead?
Most languages other than C/C++/Objective-C.
To get my job done, I need a powerful language, not a nanny nor a straightjacket.
You actually sound like exactly the kind of person who needs a straightjacket. But, in any case, plenty of languages are as powerful as C/C++ but without the defects.
Boost shows it every day. The STL shows it every day.
I'm not disputing that Boost and the STL are general. Vastly general, in fact. But there are costs: development, risk of errors, compilation times, more difficult debugging, code bloat, porting, training, compiler bugs, etc. Nobody has demonstrated that Boost/STL-style development has overall more benefits than it has costs.
Believe me, I have been down this road, written quite a few generic C++ libraries even before it was popular, and in the end concluded that it didn't survive a cost/benefit analysis.
Perfect example: std::vector<bool> becomes a bitset, and std::fill in turn fills this bitset using an optimized memset instead of setting each bit individually
I'm sorry, what is this supposed to be a "perfect example" of?
vector<bool> is a hand-written, specialized version of vector<T>, so, in fact, it's an example of where genericity fails and you have to resort to overloading and manual specialization. Furthermore, using the vector<bool> notation instead of a distinct name like bit_vector means that (1) the code needs to pull in vector<T>, (2) the expected unpacked vector<bool> version is unavailable even though it is what is usually needed, and (3) users don't even know what space/time tradeoff they are getting when they are using vector<bool> (and may not even be aware that this is a special case).
Furthermore, what makes you think you're getting efficient, specialized versions of the generic algorithms? Even if you're lucky and you get it for fill, what about all the other generic algorithms?
I'm curious. Give me examples of less limited metaprogramming.
Wrong conclusion. That would mean type safety doesnt pay off because even high performance commercial libraries have been written without such constructs. Yes, you can do it without templates in C++, but it won't be as flexible, or fast.
No, it doesn't mean that; type safety is widely used and preferred, while only a small minority of C++ programmers actually do active metaprogramming (meaning, anything more than use existing libraries).
In any case, the basic point is still that nobody has ever shown that metaprogramming or generic programming in C++ improves programmer productivity or software quality.
So far, only D provides that. D *is* a language designed with these two in mind. Maybe it is the best candidate for replacement....
Well, it may be the best candidate for a replacement, but I think D metaprogramming is still quite poor and limited; merely cleaning up the C++ syntax just isn't enough.
No examples? So that's a no, then, you couldn't find anything in a random class? So you original statement was false, it is actually pretty easy to produce correct C++ code.
No, the original statement was true and I demonstrated it: C++ source code has lots of bugs (as demonstrated by the bug list).
The fact that you think that bugs can be spotted at the level of a single class is itself telling and shows that you really don't have an inkling of what is going on. One of the big problems with C++ is exactly that the meaning and behavior of code can be changed in so many arbitrary ways by other code.
But since you asked, here's an arbitrary method (first one I picked, I really wasn't looking for anything specific):
Assuming standard definitions for "new", this code has several places where it can (and will) leak memory. It also depends on unportable features. Beyond that, it's impossible to tell what this code does, let alone whether it does it correctly; depending on header files and other compilation units, this piece of code can do arbitrary things: crash, alter any memory location, alter any variable in any other namespace, etc. The meaning of the code may change depending on whether you remember to include a header file or not, and if you don't include it, it may still compile without warning.
I also couldn't find any unit tests for this code, so this code probably hasn't even been unit tested.
Well, not by heart, but I know enough to know when to look up the details. [...] Most of it. I don't use this part very much, though, so there might well be corners I don't know that well.
You don't even know enough to understand how much trouble you're in.
I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.
Many people use templates for generic programming and metaprogramming; that doesn't prove that they are actually useful or that it "pays off" compared to simpler constructs, since pretty much nobody ever bothers making the comparison. Given that most of those libraries, even high performance commercial libraries, have been written without such constructs, it's reasonable to postulate that it doesn't.
Furthermore, being able to do it in C++ doesn't mean C++ "supports" it. Generic programming and metaprogramming in C++ is very limited in what you can do relative to languages that were designed with support for those features, it taxes compilers to the limit, it uses constructs intended for completely different purposes, and it gives lousy compiler diagnostics to users.
Well, I believe I have learned C++, which took about 6 months of medium intensity.
So, you claim you know all the rules and definition in ISO/ANSI C++? You can tell exactly which constructs are implementation defined and undefined? You know the entire STL API, complexities, etc.? You know the entire C99 subset, and its rules and definitions? I really doubt it.
What you probably mean is that, after 6 months of studying, you can produce useful code in C++ that seems to work on your desktop machine. That's nice, but it's just enough to get you into trouble.
Most of the complaining is just sour grapes. C++ is not a language for everyone, it's powerful and complex. Most programmers should be able to learn basic C++, even Java programmers.
I have been developing in C++ for 20 years, do most of my development in C++, and I do not claim to understand C++. And I have yet to see a substantial piece of correct C++ code.
If there are people who have actually learned C++, I have never met them or seen their code.
A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building?
C++ does not "support" functional programming, generic programming, object oriented programming, or even metaprogramming; if you invest a lot of work and effort, you can approximate small subsets of these programming styles in C++, badly. And I have yet to see that it's worth the effort; the best and most common use of C++ still seems to be as a slightly better C.
C++ is far too complex yes. But there is nothing that can really replace it.
Well, that is true in a very limited sense: there are specialty high performance applications in which there is no substitute for C++. However, most software should simply not be written in C/C++ anymore, software like Firefox, OpenOffice, KDE, etc.
C++ is my main development language right now, but I have to say: please give it a rest. C++ is what it is, and I don't think adding even more crap to it is going to make it any better.
What we need is a language with C++-like performance characteristics and a C-like syntax that will feel familiar to C/C++ programmers but without all the baggage of 30+ years of C history.
Every business person I've talked to says freedom takes a back seat to utility, price, ease of use and ease of migration any day of the week.
Well, then you're talking to stupid business people. The kinds of "freedoms" that "free software" guarantees are not some ideological gimmicks, their purpose is to reduce costs and business risks.
Most companies aren't choosing Linux just because it is open source, that is merely icing on the cake [...] They are choosing Linux for its cost, stability, etc etc.
Linux has low cost, high stability, and (most importantly) low business risk because it is open source.
Now, as for StarOffice, the fact that OpenOffice exists greatly reduces the risk of shipping StarOffice for Google because it means that if Sun screws up on StarOffice, Google can switch to OpenOffice with few problems.
That's funny, because the FreeBSD project is able to use lots of OpenSolaris code. The problem is Linux is encumbered because of the GPL.
The Linux license was a given and nobody can change it. Sun knew that when they picked the OpenSolaris license, and they deliberately picked a license that was incompatible with Linux, for no other reason than they wanted to be incompatible with Linux. If Sun had wanted to be less encumbered and still wanted to be compatible with Linux, they could have triple licensed. And the fact that Sun has recently talked about using GPLv3 and licenses other code under the GPLv2 tells you that they have no issues with GPL-like restrictions.
No, the problem is that Sun is trying to use open source licenses to drive wedges into the UNIX community, re-start the UNIX wars, and split the UNIX community again.
If Linux is superior, why would they need any Solaris code?
I don't think either system is superior, and that's exactly why permitting developers to merge the two systems is important: by combining the best parts of each system, we would arrive at a superior system.
Sun, unfortunately, has chosen to prohibit that and instead is trying to force users to make an either/or choice. It's the 21st century version of the UNIX wars, and it's as bad for open source today as it was for UNIX 20 years ago.
Just because of the juvenile ad homniem in the last sentence?
It's not a "juvenile ad hominem".
We get a story about security-relevant buffer overflows in important C programs almost daily. These are serious problems. To address those, either we need better programmers or we need better tools. Since we can't educate the programmers any more than we already do, obviously it's the tools that aren't working, and that means that the people who are choosing the tools are making the wrong choice, and the GGP poster exemplifies the attitudes and technical misinformation that lead to these wrong choices.
I've seen this go on for 30 years, and I'm really getting fed up with it.
The problem really is people, people like the GGP poster.
Sun has built more core technologies and released more code open source than almost any other organization.
Sure, but quantity isn't the same as utility or significance. Because of claims like yours, I looked at Sun's actual contributions to the software I use daily, and I know that they have not made any big contributions that are useful to me. Without Sun, Linux would look pretty much the same (only that we might actually have a decent network file system).
Eg. systrace and Andrew Morton's claims that Sun is fracturing the non-windows market. Hey Andrew here's a clue for you, Sun was shipping a non-windows product before Linus ever started work in Linux.
You are so right: Sun was shipping a non-Windows product long before Linux. Now, what did Sun do back then and what was the result? They turned BSD into a proprietary product, talked a lot about openness and how superior their technologies were, and then they fractured the UNIX market and helped Microsoft to market dominance.
There are many indications that Sun is heading down the same path again, only that this time they are targeting Linux. I don't want to repeat that history.
Gee, that's odd... why then does the European Commission say that Sun is the number one contributor to the entire Debian project?
Yes, there is a lot of code by Sun that is available as Debian packages, but you can't assess the value of that contribution by its quantity. For example, there is very little Sun code in Debian that is essential for running a Linux desktop or server system.
So what if they have done bad things in the past?
Plenty of things, like trying to market Solaris as a superior alternative to Linux, rebranding Gnome as a "Java desktop system", deliberately picking incompatible licenses for their open source releases, misrepresenting Java as an open standard, trying to sabotage Harmony, failing to follow through on their commitment to having Java become an ISO/ANSI standard, their involvement with SCO, their involvement with Microsoft, not accepting contributions under open source licenses to projects like Java, etc. That's in addition to foisting lousy technologies like NFS on the world.
Right now, they support open source. As long as they keep supporting open source, I will support them.
Well, my advice to you would be to check your facts and not take their word for it. If, after checking, you find that they support open source projects that matter to you, go ahead and support them (and I hope your contributions aren't limited to posting on Slashdot).
I did check, and I found that none of Sun's open source contributions matter to me, but that I do find several of their activities objectionable, and that's why I don't support them.
Slashdot Mirror
It's nearly trivial to detect whether users are actually blocking (i.e., not downloading) ads, so why not just block people who block ads?
Blocking a particular browser doesn't make sense; there are ad-block solutions for every browser, and it is easy for browsers to lie about who they are. This "campaign" sounds like Microsoft astroturfing.
Why doesn't IBM just buy Sun? They'd get control of Java and Solaris, they could kill the Sun/Microsoft dealings, and they'd get Sun's server customers. Granted, at 16B, Sun is probably still somewhat overvalued, but I think such a deal would be good for IBM overall.
Everything has a cost. Linux generally costs me a lot of time -- more time than it's worth to me
Not as much as Windows. Windows installation and maintenance is a bitch.
from compatibility issues and poor hardware vendor support to the general PITA of learning the nuances of a particular version of a given distribution.
Yes, that about sums up Windows.
So you prefer writing a list container for each type. Or a void* cast.
No; I have no problem with parameterized types. We're discussing metaprogramming and generic programming.
The point is the *possibility* of efficient, specialized versions. As said, std::fill with a vector can be reduced to a simple memset. At compile-time. No branches, no overhead, no indirections.
Yes, manually creating specialized versions is a good thing for efficiency. My point is that it is the exact opposite of metaprogramming or generic programming. The very fact that library authors manually specialize std::fill tells you that the generic version is inefficient and that metaprogramming has failed for that type.
(Quite separately from that, I'm making the point that overloading vector<bool> with bit_vector has a number of other problems.)
See they are NOT in the same league. These languages offer wonderful constructs which allow generic programming even at run-time - but at a cost. I like templates because they are generic at *compile-time*, which yields a significant performance boost.
First, several of the languages I mentioned do offer compile-time metaprogramming (ML, Haskell, etc.). Second, the distinction between compile-time and runtime disappears when JITs enter the picture; JITs permit generic programming and metaprogramming using existing object-oriented techniques, without the complexity of adding a separate static programming language. JITs basically make static metaprogramming facilities obsolete (Java/JVM got a few details wrong, but the next generation or two will fix that).
As for performance, I write performance critical code in C++; it sounds to me like you really do not. Why? Because of statements like "An unpacked version makes absolutely no sense, since it is semantically identical." and "The point is the *possibility* of efficient, specialized versions." In fact, when performance matters, the difference between a packed and an unpacked boolean array can be big, and the difference between a possible and an actual specialized version is crucial.
Right but that's a matter of the anti-aliasing filter which is used before the actual sampling.
Well, yeah, but since there are no ideal anti-aliasing filters and since real-world signals are not band-limited, you can't just design sampling rates based on twice the frequency limit of human hearing.
In fact, there is little need to sample so close to the Nyquist limit; it's safer to sample at very high frequencies during recording and playback and make decisions about what to represent in the compressor, giving you the same bitrate. The only reason we're stuck with 44kHz is historical--fast signal processors used to be expensive.
Not ideal, but since the applications are so rarely informed when they are out of memory in these days and times
That's an incorrect assumption; desktop machines run out of memory all the time, and when they do, this kind of code loses data.
KDE is an X-only application. It is exactly as portable as it should be.
This code fails on lots of platforms on which X runs.
Limiting the language to avoid surprises is a hopeless endeavor, which I'd advice against.
This isn't about "surprises", it's about the fact that in C/C++, you simply cannot reason reliably about programs; writing robust programs in C/C++ is enormously hard and unnecessarily expensive.
But I would like to hear what you suggest in it's stead?
Most languages other than C/C++/Objective-C.
To get my job done, I need a powerful language, not a nanny nor a straightjacket.
You actually sound like exactly the kind of person who needs a straightjacket. But, in any case, plenty of languages are as powerful as C/C++ but without the defects.
Boost shows it every day. The STL shows it every day.
...
I'm not disputing that Boost and the STL are general. Vastly general, in fact. But there are costs: development, risk of errors, compilation times, more difficult debugging, code bloat, porting, training, compiler bugs, etc. Nobody has demonstrated that Boost/STL-style development has overall more benefits than it has costs.
Believe me, I have been down this road, written quite a few generic C++ libraries even before it was popular, and in the end concluded that it didn't survive a cost/benefit analysis.
Perfect example: std::vector<bool> becomes a bitset, and std::fill in turn fills this bitset using an optimized memset instead of setting each bit individually
I'm sorry, what is this supposed to be a "perfect example" of?
vector<bool> is a hand-written, specialized version of vector<T>, so, in fact, it's an example of where genericity fails and you have to resort to overloading and manual specialization. Furthermore, using the vector<bool> notation instead of a distinct name like bit_vector means that (1) the code needs to pull in vector<T>, (2) the expected unpacked vector<bool> version is unavailable even though it is what is usually needed, and (3) users don't even know what space/time tradeoff they are getting when they are using vector<bool> (and may not even be aware that this is a special case).
Furthermore, what makes you think you're getting efficient, specialized versions of the generic algorithms? Even if you're lucky and you get it for fill, what about all the other generic algorithms?
I'm curious. Give me examples of less limited metaprogramming.
CommonLisp, Smalltalk, Python, Haskell, ML,
It's the same with you - you just simply don't know the difference between good quality and bad quality audio.
Who cares? What matters is the difference between good quality and bad quality music.
Then again, I'm a musician so I'm used to picking through the fine parts of sound.
Most musicians pick through interpretation and, occasionally, technique and instruments; sound usually just doesn't make the list.
You're going to need a decent sound system to do it (no, not a $50k system, but computer speakers or headphones won't do it
Well, since that's all I ever use for listening to music, I guess it doesn't matter then, does it?
Listen to the cymbals and the kick drum.
Almost none of the music I listen to has either, so that's another reason why it doesn't matter.
Wrong conclusion. That would mean type safety doesnt pay off because even high performance commercial libraries have been written without such constructs. Yes, you can do it without templates in C++, but it won't be as flexible, or fast.
No, it doesn't mean that; type safety is widely used and preferred, while only a small minority of C++ programmers actually do active metaprogramming (meaning, anything more than use existing libraries).
In any case, the basic point is still that nobody has ever shown that metaprogramming or generic programming in C++ improves programmer productivity or software quality.
So far, only D provides that. D *is* a language designed with these two in mind. Maybe it is the best candidate for replacement....
Well, it may be the best candidate for a replacement, but I think D metaprogramming is still quite poor and limited; merely cleaning up the C++ syntax just isn't enough.
No examples? So that's a no, then, you couldn't find anything in a random class? So you original statement was false, it is actually pretty easy to produce correct C++ code.
t Data()); // Maybe it wasn't running (e.g. we're opening local html files)
No, the original statement was true and I demonstrated it: C++ source code has lots of bugs (as demonstrated by the bug list).
The fact that you think that bugs can be spotted at the level of a single class is itself telling and shows that you really don't have an inkling of what is going on. One of the big problems with C++ is exactly that the meaning and behavior of code can be changed in so many arbitrary ways by other code.
But since you asked, here's an arbitrary method (first one I picked, I really wasn't looking for anything specific):
void HTMLDocumentImpl::setCookie( const DOMString & value )
{
WId windowId = 0;
KHTMLView *v = view ();
if ( v && v->topLevelWidget() )
windowId = v->topLevelWidget()->winId();
QString fake_header("Set-Cookie: ");
fake_header.append(value.string().toLatin1().cons
fake_header.append("\n");
QDBusInterface *kcookiejar = new QDBusInterface("org.kde.kded", "/modules/kcookiejar",
"org.kde.KCookieServer");
if (!kcookiejar->isValid())
{
QDBusInterface("org.kde.kded", "/kded", "org.kde.kded").call("loadModule", QByteArray("kcookiejar"));
delete kcookiejar;
kcookiejar = new QDBusInterface("org.kde.kded", "/modules/kcookiejar",
"org.kde.KCookieServer");
}
kcookiejar->call(QDBus::NoBlock, "addCookies",
URL().url(), fake_header, qlonglong(windowId));
delete kcookiejar;
}
Assuming standard definitions for "new", this code has several places where it can (and will) leak memory. It also depends on unportable features. Beyond that, it's impossible to tell what this code does, let alone whether it does it correctly; depending on header files and other compilation units, this piece of code can do arbitrary things: crash, alter any memory location, alter any variable in any other namespace, etc. The meaning of the code may change depending on whether you remember to include a header file or not, and if you don't include it, it may still compile without warning.
I also couldn't find any unit tests for this code, so this code probably hasn't even been unit tested.
Well, not by heart, but I know enough to know when to look up the details. [...] Most of it. I don't use this part very much, though, so there might well be corners I don't know that well.
You don't even know enough to understand how much trouble you're in.
I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.
Many people use templates for generic programming and metaprogramming; that doesn't prove that they are actually useful or that it "pays off" compared to simpler constructs, since pretty much nobody ever bothers making the comparison. Given that most of those libraries, even high performance commercial libraries, have been written without such constructs, it's reasonable to postulate that it doesn't.
Furthermore, being able to do it in C++ doesn't mean C++ "supports" it. Generic programming and metaprogramming in C++ is very limited in what you can do relative to languages that were designed with support for those features, it taxes compilers to the limit, it uses constructs intended for completely different purposes, and it gives lousy compiler diagnostics to users.
Then tell me what is not correct about that code.
Here you go.
Well, I believe I have learned C++, which took about 6 months of medium intensity.
So, you claim you know all the rules and definition in ISO/ANSI C++? You can tell exactly which constructs are implementation defined and undefined? You know the entire STL API, complexities, etc.? You know the entire C99 subset, and its rules and definitions? I really doubt it.
What you probably mean is that, after 6 months of studying, you can produce useful code in C++ that seems to work on your desktop machine. That's nice, but it's just enough to get you into trouble.
I did look at D. I think it's better than C++, but I think it's still way too complex for what it does.
Overall, actually, I think a batch-compiled (non-VM) version of C# 2.0 would be a fairly good language.
Most of the complaining is just sour grapes. C++ is not a language for everyone, it's powerful and complex. Most programmers should be able to learn basic C++, even Java programmers.
I have been developing in C++ for 20 years, do most of my development in C++, and I do not claim to understand C++. And I have yet to see a substantial piece of correct C++ code.
If there are people who have actually learned C++, I have never met them or seen their code.
A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building?
C++ does not "support" functional programming, generic programming, object oriented programming, or even metaprogramming; if you invest a lot of work and effort, you can approximate small subsets of these programming styles in C++, badly. And I have yet to see that it's worth the effort; the best and most common use of C++ still seems to be as a slightly better C.
C++ is far too complex yes. But there is nothing that can really replace it.
Well, that is true in a very limited sense: there are specialty high performance applications in which there is no substitute for C++. However, most software should simply not be written in C/C++ anymore, software like Firefox, OpenOffice, KDE, etc.
but for the whole compiler architecture to make it more scalable and plufable.
I, for one, think VisualStudio is plufable enough already!
C++ is my main development language right now, but I have to say: please give it a rest. C++ is what it is, and I don't think adding even more crap to it is going to make it any better.
What we need is a language with C++-like performance characteristics and a C-like syntax that will feel familiar to C/C++ programmers but without all the baggage of 30+ years of C history.
(And, no, neither Java nor C# are that language.)
Every business person I've talked to says freedom takes a back seat to utility, price, ease of use and ease of migration any day of the week.
Well, then you're talking to stupid business people. The kinds of "freedoms" that "free software" guarantees are not some ideological gimmicks, their purpose is to reduce costs and business risks.
Most companies aren't choosing Linux just because it is open source, that is merely icing on the cake [...] They are choosing Linux for its cost, stability, etc etc.
Linux has low cost, high stability, and (most importantly) low business risk because it is open source.
Now, as for StarOffice, the fact that OpenOffice exists greatly reduces the risk of shipping StarOffice for Google because it means that if Sun screws up on StarOffice, Google can switch to OpenOffice with few problems.
Not being in Germany, I could also care less.
Oh, if you "could care less", that means that you do care!
That's funny, because the FreeBSD project is able to use lots of OpenSolaris code. The problem is Linux is encumbered because of the GPL.
The Linux license was a given and nobody can change it. Sun knew that when they picked the OpenSolaris license, and they deliberately picked a license that was incompatible with Linux, for no other reason than they wanted to be incompatible with Linux. If Sun had wanted to be less encumbered and still wanted to be compatible with Linux, they could have triple licensed. And the fact that Sun has recently talked about using GPLv3 and licenses other code under the GPLv2 tells you that they have no issues with GPL-like restrictions.
No, the problem is that Sun is trying to use open source licenses to drive wedges into the UNIX community, re-start the UNIX wars, and split the UNIX community again.
If Linux is superior, why would they need any Solaris code?
I don't think either system is superior, and that's exactly why permitting developers to merge the two systems is important: by combining the best parts of each system, we would arrive at a superior system.
Sun, unfortunately, has chosen to prohibit that and instead is trying to force users to make an either/or choice. It's the 21st century version of the UNIX wars, and it's as bad for open source today as it was for UNIX 20 years ago.
Just because of the juvenile ad homniem in the last sentence?
It's not a "juvenile ad hominem".
We get a story about security-relevant buffer overflows in important C programs almost daily. These are serious problems. To address those, either we need better programmers or we need better tools. Since we can't educate the programmers any more than we already do, obviously it's the tools that aren't working, and that means that the people who are choosing the tools are making the wrong choice, and the GGP poster exemplifies the attitudes and technical misinformation that lead to these wrong choices.
I've seen this go on for 30 years, and I'm really getting fed up with it.
The problem really is people, people like the GGP poster.
Sun has built more core technologies and released more code open source than almost any other organization.
Sure, but quantity isn't the same as utility or significance. Because of claims like yours, I looked at Sun's actual contributions to the software I use daily, and I know that they have not made any big contributions that are useful to me. Without Sun, Linux would look pretty much the same (only that we might actually have a decent network file system).
Eg. systrace and Andrew Morton's claims that Sun is fracturing the non-windows market. Hey Andrew here's a clue for you, Sun was shipping a non-windows product before Linus ever started work in Linux.
You are so right: Sun was shipping a non-Windows product long before Linux. Now, what did Sun do back then and what was the result? They turned BSD into a proprietary product, talked a lot about openness and how superior their technologies were, and then they fractured the UNIX market and helped Microsoft to market dominance.
There are many indications that Sun is heading down the same path again, only that this time they are targeting Linux. I don't want to repeat that history.
Gee, that's odd... why then does the European Commission say that Sun is the number one contributor to the entire Debian project?
Yes, there is a lot of code by Sun that is available as Debian packages, but you can't assess the value of that contribution by its quantity. For example, there is very little Sun code in Debian that is essential for running a Linux desktop or server system.
So what if they have done bad things in the past?
Plenty of things, like trying to market Solaris as a superior alternative to Linux, rebranding Gnome as a "Java desktop system", deliberately picking incompatible licenses for their open source releases, misrepresenting Java as an open standard, trying to sabotage Harmony, failing to follow through on their commitment to having Java become an ISO/ANSI standard, their involvement with SCO, their involvement with Microsoft, not accepting contributions under open source licenses to projects like Java, etc. That's in addition to foisting lousy technologies like NFS on the world.
Right now, they support open source. As long as they keep supporting open source, I will support them.
Well, my advice to you would be to check your facts and not take their word for it. If, after checking, you find that they support open source projects that matter to you, go ahead and support them (and I hope your contributions aren't limited to posting on Slashdot).
I did check, and I found that none of Sun's open source contributions matter to me, but that I do find several of their activities objectionable, and that's why I don't support them.