Re:McBride and capitalism
on
SCO Roundup
·
· Score: 1
Americans understand irony. But Americans also understand that irony is misplaced in the discussion of important matters because it leads to misunderstandings and allows people to quote out of context.
So, either the Economist's use of irony was out of line, or they simply don't consider what's happening between SCO and Linux to justify more than having a little bit of editorial fun. Either possibility warrants a non-ironic response.
Re:McBride and capitalism
on
SCO Roundup
·
· Score: 1
While your argument isn't necessarily false, I think you missed the point here. If you had read the rest of the article you probably wouldn't have posted this.
I did read the entire article.
The headline is not a value judgement against the CEO or linux users--it's an intentionally over-emphasised statement to give you a glimpse of what it looks like from SCO's point of view.
I was responding to McBride's point of view.
Reading the Economist requires a higher level of comprehension than slashdot, and you need to keep that in mind when following links. Slashdot is written for roughly the middle-school level of reading comprehension (a rough guess), while some of the sites linked here presume a readership that's well-read. Sometimes it's like switching from first to fourth gear.
Perhaps if you weren't so eager to find fault in others, you'd get more out of what you read yourself.
As for the Economist, yes, it is somewhat better written than the average US publication, but, come on, it's not exactly complex prose. After all, a large part of its audience is financial types, who don't exactly value picking apart complex sentences, not intellectuals or academics.
Besides, it is unwise for a publication like the Economist to put "intentionally over-emphasized statements" in bold face and without quotation marks on the top of their pages because there are lots of people who, unlike me, don't read the entire article. And there are lots of people who won't hesitate to quote out of context: "The Economist described the fight between Linux and SCO as...". But perhaps that is something the Economist still needs to learn from those US publications aimed at "a middle-school level of reading comprehension".
As far as I'm concerned the Fresco/Berlin project was the right way already several years ago. Today, the hardware has caught up and there is nothing to be lost in user space with vector graphics everywhere.
X11 doesn't support "vector graphics" any more or less than it used to. What has changed is that X11 now has an imaging model similar to PostScript (subpixel addressing, antialiasing, etc.) in addition to its older bitblit model (pixel-accurate, using boolean operations for drawing).
(Subpixel addressing also allows you to do zoomable or "resolution independent" graphics, while the bitblit model is resolution dependent. However, the term "resolution independent" is somewhat of a misnomer--even if your imaging model supports arbitrary zooming, you can't just zoom user interfaces up and down and expect them to be usable.)
When people talk about "vector graphics" in the context of window systems, that usually means the use of display lists: you give the server a list of "objects" to display (lines, triangles, rectangles, etc.), and the server takes care of displaying them when needed. But they might mean something else as well.
Display lists in X11 are still handled the way it has always been handled: by client-side libraries. Eventually, there may be a server-side extension for handling display lists and perhaps even the ability to transfer display lists and structured graphics in the form of SVG data. That would give you Quartz-like redrawing and rescaling, although while that looks nice it has few real advantages.
Now, what about Berlin vs. X11? First of all, one big thing in Berlin is the incorporation of GUI components into the server. That is an anathema to X11 designers. Also, while resolution-independent graphics is nice (the same thing X11 now supports with Cairo), it is a poor choice as the only graphics model: well-designed application for low-resolution and/or low-depth screens (e.g., a 160x160 Palm) must be able to draw with pixel-accurate drawing operations and precisely predictable results on every bit on the screen.
I don't think Berlin "got it right". Berlin concentrated on the obvious, convenient, clean, high-level stuff. Berlin would give you slick-looking OS X-like desktops if it ever caught on, but the Berlin designers have neglected the other imaging models that are really important to real window systems, and they have put way too much policy into the server.
Fortunately, the way X11 is evolving, we won't have to make a choice: you can have all the slick antialiased, structured graphics you like, and yet still have pixel-accurate drawing in a bounded memory X11 implementation. The only difference will be that X11 still won't enforce policy on the server side, and that's a good thing as far as I am concerned. But the market will decide that issue.
In fact, we have no idea what kind of possibilities may open up here. If we're unlucky, yes, it might be a can of worms...;)
There is no "can of worms". We have had window systems with antialiased drawing, structured graphics, and all that at least since the 1980s; maybe you remember NeXT and NeWS. The feature is nice, but it doesn't radically change what people do with GUIs.
McBride and capitalism
on
SCO Roundup
·
· Score: 3, Insightful
Darl McBride, capitalist crusader against the commie horde of Linux users
There is nothing "capitalist" or "fundamentalist" about McBride--his is a campaign of lies and stock manipulation, and McBride's company is apparently engaging in intellectual property theft. Like so many other dishonest people before him, he is hiding his misdeeds by accusing his opponents of being un-American and communists.
There is nothing "communist" about Linux. Linux has thrived in free market economies because it's a highly efficient way for commercial entities to develop software. Linux is about free markets at their best: goods being produced at marginal costs, which, in the case of software, happens to be zero.
Yes, and given the quality of code engineers commonly produce,
Whoops. We're right back up to the allegory again.
Quite correct: I am making a point about engineers in general. If all you have is an engineering education, you shouldn't be writing software because you really don't know what you are doing.
How about you go over there and write some specifications and fancy documentation while we finish the code. You can use all your latest 'scientific' methods to produce test cases for the QA people to use. We'll have code for you to test in a little while.
How about you go over there and do your silly architectural drawings and load calculations while I just get some stuff from Home Depot and slap together your new house quickly? It will be done much faster and cheaper. Really.
I agree that the shift of IT jobs overseas is unstoppable. Actually, I don't even think it's a bad thing: to me, VB or ASP hacking seems like the intellectual equivalent of cleaning toilets.
In any case, there is a sure-fire way to accelerate this shift of jobs overseas: restrict H-1b visas. You see, right now, the smartest IT workers from overseas want to come to the US, and employers eager to hire them will accommodate their wishes. But if H-1b quotas make it impossible to hire those people in the US, the potential employees understand that they can't move to the US and employers can hire them in their countries of origin at a fraction of the cost.
Whether that's a good thing or not depends on your perspective. It probably is a good thing for countries like the UK, China, and India, who have lost their best and brightest to the US, people who are desparately needed for contributing to their domestic economies.
His 'job title' doesn't matter. He's been beheaded.
Perhaps you don't understand that the piece is an allegory, rather than a description of a real event. For an allegory, the job title is all that matters since it compares the profession of "engineer" with the profession of "computer scientist".
The engineer, meanwhile, has the code for the 4-bit microcontroller locked down, all the QA testing has been done, and the first-release mask programmed parts are due back from Hitachi next Tuesday.
Yes, and given the quality of code engineers commonly produce, the microcontroller will probably go into an infinite loop when the user sets the toaster to "zero", the toaster will catch fire and burn down the house.
Engineers should not do programming of any kind--they simply lack the qualifications and training. And industrial programmers always need more education and need to get less religious, in order to catch up with the state of the art.
As for computer scientists, a lot of them are working furiously on creating tools to let people build reliable, saef, flexible, power-efficient embedded system using fewer gates than even a 4-bit microcontroller uses.
Did you even read what I typed? I said that they take a stock linux kernal source tarball. They run configure on it, they build.
Did you even read what I wrote? It is your assertion that they can just "point to the source" that is wrong. If they ship a Linux kernel, even unmodified, they must make the source to that kernel available. That matters because while they may not have modified the code, someone upstream may have, and because it lets users run the kernel on that hardware.
And there's nice functionality built into the linux kernal these days to implement binary plugin module device drivers.
No, the functionality is not "nice"; if it were, we wouldn't have to upgrade our complete set of modules every time we install a new kernel.
The Linux binary module interface needs a lot of work. But whether or not that work gets done should be purely a technical issue. If people don't want companies to develop closed-source binary modules for Linux, then the Linux license should simply be changed to not allow it.
It's pretty much a design decision for the company to decide wether or not they want to disclose source.
You say that as if it's a bad thing or as if it's anything new. The GPL is doing exactly what it was intended to do. If people had wanted different obligations on the part of users or companies, they would/should have used a different license.
They can point to the source for the stock Linux they incorporated into their product.
No, they can't. That option is only available under Section (3c) of the GPL, and it doesn't apply to commercial entities.
If they modify the Linux kernel, or any other LGPL/GPL software, they have to make the modified source available, period.
They don't have to make the source available for any software that doesn't link with GPL'ed code, and that is they way the GPL was intended to work.
And if enough people whine and holler, they can just use NetBSD instead.
That, too, is as it should be. Fortunately, the GPL seems to strike a good balance between the needs of the Linux community and the needs of these kinds of companies. Otherwise, they it would be the CEBSDF, not the CELF.
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. [...] "With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry.
Sorry, but that's probably an industrial programmer/analyst, not a computer scientist. Object oriented programming ceased being at the cutting edge of computer science many years ago.
I just hope all these corporation continue to respect GPL and not find a way to tear Linux apart.
If companies wanted to "tear Linux apart", why would they get together in the CELF? The main point of using Linux is to get a market in which programmers and tools can be shared among many projects and companies. If companies wanted their own proprietary embedded operating systems, they wouldn't have to take Linux and hack it up, they could just keep using whatever they are already using.
If some companies end up making proprietary versions of Linux for their own use, we'd still be better off than we are now, since their systems would still be basically Linux and POSIX-based. That at least means they are contributing to the pool of Linux and POSIX programmers. It also means that any externally visible interfaces, file formats, and protocols are more likely to be open and interoperable.
Just a little caution needed after what happened to UNIX.
What killed commercial UNIX was high cost, poor marketing, high hardware requirements, and Microsoft's sneak-attack from the low end. None of those apply to Linux.
These companies are going to use what has already been developed and then they aren't going to continue adding those features to the kernel to be worked on by others.
If they ship the software as part of their hardware, they have to make the source available.
So Postgres is one feature closer to what Oracle was several years ago.
And, while this may come as a surprise to you, most people today are running Oracle using the same feature set that Oracle had several years ago: software doesn't get hacked up to use every latest feature every time Oracle ships a new version. Therefore, when you (a UNIX/Oracle specialist) are saying that Postgres is where Oracle was a few years ago, that means that Postgres is technically good enough for most applications.
Oracle, is pushing the edge on the database front, and doesn't show any signs of stopping.
Perhaps not. But the ability to absorb, and need for, new features in database based applications is slowing down.
I like PostgreSQL, and Open Source deserves capitalization, but I'd like to hear an enterprise DBA's perspective on if this really compares to Oracle's configurability, clustering capabilities, or the seamless swapping of redundant database packages
I am not a (full-time) DBA, and neither are probably 99% of the people, like me, who use RDBMSs in their work. The problem with Oracle is that it pretty much requires a DBA in order to work well. Alternatives to Oracle (commercial or open source) may not have all the whiz-bang features, but they are much easier to deal with if you aren't a full time DBA.
Oracle may or may not be the Ferrari of databases, but a Honda Civic is probably more practical transportation for most people.
Please! While this may help win the hearts and minds of OOS geeks, it does little to improve their standing in the business world. Oracle is as established in the database world as Microsoft is on the desktop.
We're geeks: we can't do anything about terminal stupidity or give managers brain transplants. What we can do is make software good enough so that it becomes a viable alternative. The smarter ones will pick it up, the others will just keep paying Oracle or Microsoft.
Fortunately, it's a free market. Eventually, the poor support and enormous costs that come with the commercial products will hopefully bankrupt their companies. Then, the leaner and meaner and smarter companies using open source will survive, and that will take care of the stupidity problem.
If you look at.NET and C#, you'll see that they are just cleaned up versions of j2ee and java.
Yes, that's what I was saying.
And neither Java nor C# really are anything new, nor was COM/DCOM. Just about anything in those object and component systems was worked out some time in the Smalltalk-80 days. And if you want to argue that Smalltalk-80 was just impractical, Objective-C and NeXTStep brought those models to UNIX/NT-like platforms a few years later, still many years before COM/DCOM or Java.
The tactic of associating peaceful populations with the antisocial or criminal acts of a few militant people is standard behavior in international politics. Politically, it plays really well to one's own crowd to say "the others are evil terrorists, therefore we are justified in 'protecting' ourselves by any means possible".
We don't assume that Microsoft endorses or orchestrates DOS attacks against Linux sites when attacks occur against Linux sites. Similarly, we shouldn't tie DOS attacks against SCO to the Linux community. People who are launching DOS attacks against anybody are just uncivilized script kiddies. If they happen to be Linux users as well, that's incidental.
DOS attacks on SCO have nothing to do with Linux or the Linux community. SCO's legal attacks on Linux are outrageous and unfounded, but the Linux community is responding to them with facts and will, if ever presented with a real legal challenge, respond in court.
If you knew about the SPECcpu2000 suite, you'd know that every program comes with a corresponding "correct" output file against which the output must be checked. To report a SPEC result, the output has to WORK.
Yes, and the output probably would work, too, if you enabled the same optimizations in gcc. That doesn't make the optimizations "semantics preserving".
For example, gcc doesn't use x86 transcendental instructions by default because they give wrong results for large arguments. Most programs never encounter that case for most input data, but the program has different semantics and the optimization is not semantics preserving. The fact that those changes only show up under rare circumstances makes the problem worse.
May I humbly suggested that you stop using the word 'semantics', at least if you don't know the meaning of the word, which you don't seem to.
Yes, you should be quite humble because you erroneously think that "I ran the program and it gave the same answer" means that the compiler compiled it correctly.
IBM's benchmarks comparing gcc and xlc on SPECint2000 and SPECfp2000 seem not very meaningful to me. First of all, note that both -O2 and -O3 are semantics preserving in gcc, while -O4 and -O5 in xlc are not. That is, in particular on the SPECint2000 benchmarks, the xlc compiler is faster simply because it changes the behavior of your program. The same may even be true for xlc compiling SPECfp2000 at lower optimization settings; the Intel compiler on P4, for example, achieves large gains in performance on some benchmarks by inlining math functions that gcc uses a library for--because the P4 instructions aren't quite right.
In my experience, you can usually match the performance of those other "fast" compilers with gcc by using the "-f" and "-m" flags. The main difference is that gcc forces you to be explicit about which semantic changes the compiler is allowed to make, rather than lumping things together under some generic "-O5" setting. That's a good thing.
(Note that my comments apply to gcc; g77 may well be a much worse performer than commercial Fortran compilers even though it shares the same back-end with gcc. That affects the SPECfp2000 scores. Fortran just doesn't seem to be a high priority for gcc.)
The lack of starndardized libraries. KParts, Bonbobo, XParts, DCOP, XUL, OpenOffice are all competing technologies. No one component model for linux. Wan't the KHTML part to display a webpage in your gnumeric spreadshit? No, you can't do it yet.
And you never will be able to. And that's a good thing. To many people, it's questionable whether component models are ever a good thing, and there are big differences in how to implement them. By creating many different desktops and having them compete, good concepts survive and bad ones die. That's how a free market works.
COM/DCOM are a messy hack on top of C++ virtual tables. They are not a good thing, nor is there anything new in COM/DCOM relative to earlier OO component architectures. They are, in fact, so much not a good thing that Microsoft cloned Java in order to replace COM/DCOM with the C# object model.
J2EE is a mess, but you can't fault the underlying object and component model for that.
Good news: doesn't matter what "Executive Editor Russell" says. Russell may thinks that the appearance of Linux should be planned by a Central Committee, which would avoid the waste and duplicated effort of a free market. People in the Soviet Union also thought that central planning was more efficient than a messy market, but it didn't work that way. Choice and variety is an intrinsic part of Linux and open source. And in the long run, they avoid the stagnation that is intrinsic in centrally planned systems, like the USSR or Microsoft.
Pehaps one way in which people like Russell can get happier with Linux is to think of Linux not as a single system with an inconsistent user interface, but as several different systems. Then his argument becomes about as sensible as arguing that computer users would be a lot happier if Apple just killed the Macintosh because then commercial user interfaces would all look like Windows and hence be less inconsistent.
Let me second this. I did an analysis of the actual access controls that existed on an AFS system after about two years of use. The ACLs made no sense and created big potential security holes.
Yes, setting up UNIX-style groups is a pain for administrators. But giving users the ability to put arbitrary combinations of permissions onto their files is worse, at least in large, multi-user environments.
Slashdot Mirror
Americans understand irony. But Americans also understand that irony is misplaced in the discussion of important matters because it leads to misunderstandings and allows people to quote out of context.
So, either the Economist's use of irony was out of line, or they simply don't consider what's happening between SCO and Linux to justify more than having a little bit of editorial fun. Either possibility warrants a non-ironic response.
While your argument isn't necessarily false, I think you missed the point here. If you had read the rest of the article you probably wouldn't have posted this.
I did read the entire article.
The headline is not a value judgement against the CEO or linux users--it's an intentionally over-emphasised statement to give you a glimpse of what it looks like from SCO's point of view.
I was responding to McBride's point of view.
Reading the Economist requires a higher level of comprehension than slashdot, and you need to keep that in mind when following links. Slashdot is written for roughly the middle-school level of reading comprehension (a rough guess), while some of the sites linked here presume a readership that's well-read. Sometimes it's like switching from first to fourth gear.
Perhaps if you weren't so eager to find fault in others, you'd get more out of what you read yourself.
As for the Economist, yes, it is somewhat better written than the average US publication, but, come on, it's not exactly complex prose. After all, a large part of its audience is financial types, who don't exactly value picking apart complex sentences, not intellectuals or academics.
Besides, it is unwise for a publication like the Economist to put "intentionally over-emphasized statements" in bold face and without quotation marks on the top of their pages because there are lots of people who, unlike me, don't read the entire article. And there are lots of people who won't hesitate to quote out of context: "The Economist described the fight between Linux and SCO as...". But perhaps that is something the Economist still needs to learn from those US publications aimed at "a middle-school level of reading comprehension".
As far as I'm concerned the Fresco/Berlin project was the right way already several years ago. Today, the hardware has caught up and there is nothing to be lost in user space with vector graphics everywhere.
;)
X11 doesn't support "vector graphics" any more or less than it used to. What has changed is that X11 now has an imaging model similar to PostScript (subpixel addressing, antialiasing, etc.) in addition to its older bitblit model (pixel-accurate, using boolean operations for drawing).
(Subpixel addressing also allows you to do zoomable or "resolution independent" graphics, while the bitblit model is resolution dependent. However, the term "resolution independent" is somewhat of a misnomer--even if your imaging model supports arbitrary zooming, you can't just zoom user interfaces up and down and expect them to be usable.)
When people talk about "vector graphics" in the context of window systems, that usually means the use of display lists: you give the server a list of "objects" to display (lines, triangles, rectangles, etc.), and the server takes care of displaying them when needed. But they might mean something else as well.
Display lists in X11 are still handled the way it has always been handled: by client-side libraries. Eventually, there may be a server-side extension for handling display lists and perhaps even the ability to transfer display lists and structured graphics in the form of SVG data. That would give you Quartz-like redrawing and rescaling, although while that looks nice it has few real advantages.
Now, what about Berlin vs. X11? First of all, one big thing in Berlin is the incorporation of GUI components into the server. That is an anathema to X11 designers. Also, while resolution-independent graphics is nice (the same thing X11 now supports with Cairo), it is a poor choice as the only graphics model: well-designed application for low-resolution and/or low-depth screens (e.g., a 160x160 Palm) must be able to draw with pixel-accurate drawing operations and precisely predictable results on every bit on the screen.
I don't think Berlin "got it right". Berlin concentrated on the obvious, convenient, clean, high-level stuff. Berlin would give you slick-looking OS X-like desktops if it ever caught on, but the Berlin designers have neglected the other imaging models that are really important to real window systems, and they have put way too much policy into the server.
Fortunately, the way X11 is evolving, we won't have to make a choice: you can have all the slick antialiased, structured graphics you like, and yet still have pixel-accurate drawing in a bounded memory X11 implementation. The only difference will be that X11 still won't enforce policy on the server side, and that's a good thing as far as I am concerned. But the market will decide that issue.
In fact, we have no idea what kind of possibilities may open up here. If we're unlucky, yes, it might be a can of worms...
There is no "can of worms". We have had window systems with antialiased drawing, structured graphics, and all that at least since the 1980s; maybe you remember NeXT and NeWS. The feature is nice, but it doesn't radically change what people do with GUIs.
Darl McBride, capitalist crusader against the commie horde of Linux users
There is nothing "capitalist" or "fundamentalist" about McBride--his is a campaign of lies and stock manipulation, and McBride's company is apparently engaging in intellectual property theft. Like so many other dishonest people before him, he is hiding his misdeeds by accusing his opponents of being un-American and communists.
There is nothing "communist" about Linux. Linux has thrived in free market economies because it's a highly efficient way for commercial entities to develop software. Linux is about free markets at their best: goods being produced at marginal costs, which, in the case of software, happens to be zero.
Yes, and given the quality of code engineers commonly produce,
Whoops. We're right back up to the allegory again.
Quite correct: I am making a point about engineers in general. If all you have is an engineering education, you shouldn't be writing software because you really don't know what you are doing.
How about you go over there and write some specifications and fancy documentation while we finish the code. You can use all your latest 'scientific' methods to produce test cases for the QA people to use. We'll have code for you to test in a little while.
How about you go over there and do your silly architectural drawings and load calculations while I just get some stuff from Home Depot and slap together your new house quickly? It will be done much faster and cheaper. Really.
I agree that the shift of IT jobs overseas is unstoppable. Actually, I don't even think it's a bad thing: to me, VB or ASP hacking seems like the intellectual equivalent of cleaning toilets.
In any case, there is a sure-fire way to accelerate this shift of jobs overseas: restrict H-1b visas. You see, right now, the smartest IT workers from overseas want to come to the US, and employers eager to hire them will accommodate their wishes. But if H-1b quotas make it impossible to hire those people in the US, the potential employees understand that they can't move to the US and employers can hire them in their countries of origin at a fraction of the cost.
Whether that's a good thing or not depends on your perspective. It probably is a good thing for countries like the UK, China, and India, who have lost their best and brightest to the US, people who are desparately needed for contributing to their domestic economies.
His 'job title' doesn't matter. He's been beheaded.
Perhaps you don't understand that the piece is an allegory, rather than a description of a real event. For an allegory, the job title is all that matters since it compares the profession of "engineer" with the profession of "computer scientist".
The engineer, meanwhile, has the code for the 4-bit microcontroller locked down, all the QA testing has been done, and the first-release mask programmed parts are due back from Hitachi next Tuesday.
Yes, and given the quality of code engineers commonly produce, the microcontroller will probably go into an infinite loop when the user sets the toaster to "zero", the toaster will catch fire and burn down the house.
Engineers should not do programming of any kind--they simply lack the qualifications and training. And industrial programmers always need more education and need to get less religious, in order to catch up with the state of the art.
As for computer scientists, a lot of them are working furiously on creating tools to let people build reliable, saef, flexible, power-efficient embedded system using fewer gates than even a 4-bit microcontroller uses.
Did you even read what I typed? I said that they take a stock linux kernal source tarball. They run configure on it, they build.
Did you even read what I wrote? It is your assertion that they can just "point to the source" that is wrong. If they ship a Linux kernel, even unmodified, they must make the source to that kernel available. That matters because while they may not have modified the code, someone upstream may have, and because it lets users run the kernel on that hardware.
And there's nice functionality built into the linux kernal these days to implement binary plugin module device drivers.
No, the functionality is not "nice"; if it were, we wouldn't have to upgrade our complete set of modules every time we install a new kernel.
The Linux binary module interface needs a lot of work. But whether or not that work gets done should be purely a technical issue. If people don't want companies to develop closed-source binary modules for Linux, then the Linux license should simply be changed to not allow it.
It's pretty much a design decision for the company to decide wether or not they want to disclose source.
You say that as if it's a bad thing or as if it's anything new. The GPL is doing exactly what it was intended to do. If people had wanted different obligations on the part of users or companies, they would/should have used a different license.
They can point to the source for the stock Linux they incorporated into their product.
No, they can't. That option is only available under Section (3c) of the GPL, and it doesn't apply to commercial entities.
If they modify the Linux kernel, or any other LGPL/GPL software, they have to make the modified source available, period.
They don't have to make the source available for any software that doesn't link with GPL'ed code, and that is they way the GPL was intended to work.
And if enough people whine and holler, they can just use NetBSD instead.
That, too, is as it should be. Fortunately, the GPL seems to strike a good balance between the needs of the Linux community and the needs of these kinds of companies. Otherwise, they it would be the CEBSDF, not the CELF.
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. [...] "With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry.
Sorry, but that's probably an industrial programmer/analyst, not a computer scientist. Object oriented programming ceased being at the cutting edge of computer science many years ago.
I just hope all these corporation continue to respect GPL and not find a way to tear Linux apart.
If companies wanted to "tear Linux apart", why would they get together in the CELF? The main point of using Linux is to get a market in which programmers and tools can be shared among many projects and companies. If companies wanted their own proprietary embedded operating systems, they wouldn't have to take Linux and hack it up, they could just keep using whatever they are already using.
If some companies end up making proprietary versions of Linux for their own use, we'd still be better off than we are now, since their systems would still be basically Linux and POSIX-based. That at least means they are contributing to the pool of Linux and POSIX programmers. It also means that any externally visible interfaces, file formats, and protocols are more likely to be open and interoperable.
Just a little caution needed after what happened to UNIX.
What killed commercial UNIX was high cost, poor marketing, high hardware requirements, and Microsoft's sneak-attack from the low end. None of those apply to Linux.
These companies are going to use what has already been developed and then they aren't going to continue adding those features to the kernel to be worked on by others.
If they ship the software as part of their hardware, they have to make the source available.
Ummm--it's X11. You don't even have to be near the machine:Geez, Windows refugees really shouldn't be let near UNIX machines without some serious re-education.
So Postgres is one feature closer to what Oracle was several years ago.
And, while this may come as a surprise to you, most people today are running Oracle using the same feature set that Oracle had several years ago: software doesn't get hacked up to use every latest feature every time Oracle ships a new version. Therefore, when you (a UNIX/Oracle specialist) are saying that Postgres is where Oracle was a few years ago, that means that Postgres is technically good enough for most applications.
Oracle, is pushing the edge on the database front, and doesn't show any signs of stopping.
Perhaps not. But the ability to absorb, and need for, new features in database based applications is slowing down.
I like PostgreSQL, and Open Source deserves capitalization, but I'd like to hear an enterprise DBA's perspective on if this really compares to Oracle's configurability, clustering capabilities, or the seamless swapping of redundant database packages
I am not a (full-time) DBA, and neither are probably 99% of the people, like me, who use RDBMSs in their work. The problem with Oracle is that it pretty much requires a DBA in order to work well. Alternatives to Oracle (commercial or open source) may not have all the whiz-bang features, but they are much easier to deal with if you aren't a full time DBA.
Oracle may or may not be the Ferrari of databases, but a Honda Civic is probably more practical transportation for most people.
Please! While this may help win the hearts and minds of OOS geeks, it does little to improve their standing in the business world. Oracle is as established in the database world as Microsoft is on the desktop.
We're geeks: we can't do anything about terminal stupidity or give managers brain transplants. What we can do is make software good enough so that it becomes a viable alternative. The smarter ones will pick it up, the others will just keep paying Oracle or Microsoft.
Fortunately, it's a free market. Eventually, the poor support and enormous costs that come with the commercial products will hopefully bankrupt their companies. Then, the leaner and meaner and smarter companies using open source will survive, and that will take care of the stupidity problem.
If you look at .NET and C#, you'll see that they are just cleaned up versions of j2ee and java.
Yes, that's what I was saying.
And neither Java nor C# really are anything new, nor was COM/DCOM. Just about anything in those object and component systems was worked out some time in the Smalltalk-80 days. And if you want to argue that Smalltalk-80 was just impractical, Objective-C and NeXTStep brought those models to UNIX/NT-like platforms a few years later, still many years before COM/DCOM or Java.
The tactic of associating peaceful populations with the antisocial or criminal acts of a few militant people is standard behavior in international politics. Politically, it plays really well to one's own crowd to say "the others are evil terrorists, therefore we are justified in 'protecting' ourselves by any means possible".
We don't assume that Microsoft endorses or orchestrates DOS attacks against Linux sites when attacks occur against Linux sites. Similarly, we shouldn't tie DOS attacks against SCO to the Linux community. People who are launching DOS attacks against anybody are just uncivilized script kiddies. If they happen to be Linux users as well, that's incidental.
DOS attacks on SCO have nothing to do with Linux or the Linux community. SCO's legal attacks on Linux are outrageous and unfounded, but the Linux community is responding to them with facts and will, if ever presented with a real legal challenge, respond in court.
If you knew about the SPECcpu2000 suite, you'd know that every program comes with a corresponding "correct" output file against which the output must be checked. To report a SPEC result, the output has to WORK.
Yes, and the output probably would work, too, if you enabled the same optimizations in gcc. That doesn't make the optimizations "semantics preserving".
For example, gcc doesn't use x86 transcendental instructions by default because they give wrong results for large arguments. Most programs never encounter that case for most input data, but the program has different semantics and the optimization is not semantics preserving. The fact that those changes only show up under rare circumstances makes the problem worse.
May I humbly suggested that you stop using the word 'semantics', at least if you don't know the meaning of the word, which you don't seem to.
Yes, you should be quite humble because you erroneously think that "I ran the program and it gave the same answer" means that the compiler compiled it correctly.
IBM's benchmarks comparing gcc and xlc on SPECint2000 and SPECfp2000 seem not very meaningful to me. First of all, note that both -O2 and -O3 are semantics preserving in gcc, while -O4 and -O5 in xlc are not. That is, in particular on the SPECint2000 benchmarks, the xlc compiler is faster simply because it changes the behavior of your program. The same may even be true for xlc compiling SPECfp2000 at lower optimization settings; the Intel compiler on P4, for example, achieves large gains in performance on some benchmarks by inlining math functions that gcc uses a library for--because the P4 instructions aren't quite right.
In my experience, you can usually match the performance of those other "fast" compilers with gcc by using the "-f" and "-m" flags. The main difference is that gcc forces you to be explicit about which semantic changes the compiler is allowed to make, rather than lumping things together under some generic "-O5" setting. That's a good thing.
(Note that my comments apply to gcc; g77 may well be a much worse performer than commercial Fortran compilers even though it shares the same back-end with gcc. That affects the SPECfp2000 scores. Fortran just doesn't seem to be a high priority for gcc.)
The lack of starndardized libraries. KParts, Bonbobo, XParts, DCOP, XUL, OpenOffice are all competing technologies. No one component model for linux. Wan't the KHTML part to display a webpage in your gnumeric spreadshit? No, you can't do it yet.
And you never will be able to. And that's a good thing. To many people, it's questionable whether component models are ever a good thing, and there are big differences in how to implement them. By creating many different desktops and having them compete, good concepts survive and bad ones die. That's how a free market works.
COM/DCOM are a messy hack on top of C++ virtual tables. They are not a good thing, nor is there anything new in COM/DCOM relative to earlier OO component architectures. They are, in fact, so much not a good thing that Microsoft cloned Java in order to replace COM/DCOM with the C# object model.
J2EE is a mess, but you can't fault the underlying object and component model for that.
Good news: doesn't matter what "Executive Editor Russell" says. Russell may thinks that the appearance of Linux should be planned by a Central Committee, which would avoid the waste and duplicated effort of a free market. People in the Soviet Union also thought that central planning was more efficient than a messy market, but it didn't work that way. Choice and variety is an intrinsic part of Linux and open source. And in the long run, they avoid the stagnation that is intrinsic in centrally planned systems, like the USSR or Microsoft.
Pehaps one way in which people like Russell can get happier with Linux is to think of Linux not as a single system with an inconsistent user interface, but as several different systems. Then his argument becomes about as sensible as arguing that computer users would be a lot happier if Apple just killed the Macintosh because then commercial user interfaces would all look like Windows and hence be less inconsistent.
causing headaches both for Symantec and unsuspecting buyers, who find out too late that the software isn't doing the job
Yes, let's protect buyers from the genuine Symantec versions; the fake ones simply have to be working better--they couldn't work any worse.
Let me second this. I did an analysis of the actual access controls that existed on an AFS system after about two years of use. The ACLs made no sense and created big potential security holes.
Yes, setting up UNIX-style groups is a pain for administrators. But giving users the ability to put arbitrary combinations of permissions onto their files is worse, at least in large, multi-user environments.