People think that if they just put the toolkit into the server, things will get consistent:
UNIX desktop environments are a mess. The proliferation of incompatible and inconsistent user interface toolkits is now the primary factor in the failure of enterprises to adopt UNIX as a desktop solution.
There is no way to get consistency in a window system. People will port their favorite window managers and toolkits to whatever window system you create. MS Windows runs many of the same toolkits that X11 does. Apple is even worse, officially supporting OS 9, Carbon, Swing, and Cocoa-based applications on the same desktop, and now also X11; and in addition to all that, toolkits like Gtk+, FLTK, Swing are also being ported to native Quartz backends.
If you want consistency on your desktop, just choose to use a consistent set of applications. Most non-computer experts can't even tell the difference between an MFC, Gnome, KDE, and wxWindows application: they all look equally flaky and confusing to them. And most people incorrectly think that something is an OS X native application if it has shiny gumdrop buttons. In short, most people neither know nor care.
Lots of operating systems have had disk-at-a-time encryption. You can already get it for Windows, but that was apparently not good enough to have that PPT junkie use it either.
Disk-at-a-time (or file-system-at-a-time) encryption just doesn't seem to be convenient enough. Most files simply do not need to be encrypted, and the risk of losing an entire disk due to bugs or losing the pass phrase is just too high, as is the computational cost. People need to be able to decide on a per-file basis what gets encrypted and pick different pass phrases for different files.
In fact, file-at-a-time encryption shouldn't be in the kernel, it is implementable in user code if you have the right hooks. You can build that on top of Plan 9's file system hooks or on top of the CODA hooks in the Linux kernel. Something like the Plastic file system for Linux also would work. But it can also be done at the kernel level; ReiserFS may get file-at-a-time encryption soon.
By the way, if you do want disk-at-a-time encryption, StegFS strikes me as a better choice.
we need reliable connectionless messages
on
HyperSCSI Examined
·
· Score: 1
While UDP clearly was the wrong choice, TCP isn't the right choice either: TCP is a reliable, connection-oriented stream protocol. But for file and device access, you want a reliable connectionless protocol.
There are a number of choices. Plan 9 defined IL for just this purpose, there is SCTP for telephony applications, and several operating systems support RDM ("reliably delivered message"). Maybe people should just start using one of them, rather than reinventing the wheel by building on top of unreliable datagrams or by using protocols with unnecessary overhead.
Venter published the human genome years ahead schedules.
So what? It's still a mechanical process with little scientific insight. If anything, the people who developed the sequencing machines should be rewarded, but even that was more of an engineering feat.
The array syntax in F9X can be applied to arbitrary classes (or "derived types" as they are known) via operator overloading
Too bad that those derivation mechanisms and operator overloading are not sufficiently powerful to actually implement efficient, general purpose array-like classes like you can in C++.
[No Fortran compiler can keep up with [handcrafted libraries]] Of course not, but neither can a C or C++ compiler. I'm not seeing your point here
In C++, those libraries can be wrapped up so that they look and feel exactly like any other built-in datatype. In Fortran, that is impossible.
From your comment, I can see that you are one of those people who likes to talk about Fortran, but actually knows nothing about it. [...] I don't find it so; but you, with yourcompletly-unwarranted prejudices about a language you obviously know nothing of, are free to do so
I gave Fortran 90 and Fortran 95 a good try when they came out. I picked apart the language and its semantics carefully. I downloaded, benchmarked, and bought several compilers. I ported quite a bit of my Fortran 77 and C++ code to it. Initially, it seemed like a promising alternative to C++, but the evolution of Fortran went off on a side-track and it never fulfilled its promise. In contrast, the C++ committee pulled through and did a lot of really hard work to beat C++ into shape, and they created a winner.
If your needs are simple enough that current Fortran standards satisfy them, good for you. But there won't be a "Fortran renaissance". Modern scientific and engineering computing has moved resolutely away from Fortran. You don't need to look any further than at what languages scientists and engineers are actually taught at university.
So, animals are not indiginous to the americas. I say we remove them all, restoring the land to it's natural state.
Your cynicism is misplaced and betrays a lack of understanding. The motivation behind restoring ecosystems to their "natural state" is not to make them conform to some silly romantic ideals, it is a simple, practical motivation: when foreign species invade, the consequences are often diseases, pests, reduced productivity, and erosion. Restoring the ecosystem to its "natural" state, a state that may have existed stably for millions of years is simply prudent, practical resource management.
After all there's a Nobel Prize out there for someone in the genome business.
I dunno--is there a Nobel Prize out there for the head librarian at the Library of Congress? If you think about it, sequencing genomes is a pretty mechanical process, and pushing it ahead by a few years, like Venter did, is not necessarily such a big deal either.
F9x is an absolute joy to program in -- just the array syntax alone makes it so.
C++ supports equivalent array syntax. Furthermore, in C++, library developers can create natural syntax for arbitrary classes, not just the few things that are built-in.
And, despite what some C++ advocates may claim, it still holds the edge in terms of efficiency, when it comes to numerical simulations.
Even if that were true, it wouldn't matter. Using Fortran involves extra programming time and extra expenses for software. Overall, you get less bang-for-the-buck even if your Fortran program were to run somewhat faster.
But it isn't even true. C++ compilers are very good, and Fortran compilers are being neglected more and more. Furthermore, for the truly high-performance stuff, people are increasingly relying on large libraries of hand-crafted, processor-specific routines (BLAS, SparseBLAS, OpenGL, etc.). No Fortran compiler can keep up with that.
Think about it: most people who program in Fortran are actually using the language to solve numerical problems in some other discipline (such as engineering, or in my case astrophysics);
Yes, but your reasoning is backwards. Of course, "most" Fortran programmers are satisfied with its limited feature set. But most people who write scientific and engineering applications aren't solving purely numerical problems and Fortran is far too limiting for them. The fraction of scientists and engineers whose needs are actually addressed by Fortran is small and shrinking.
Since these typical users are either embedded in a university department or a corporation, there are ample funds to buy whatever F9X compiler they might need.
"Ample funds" at a university or a corporation? What rock are you living under? Having worked in both environments, I can assure you that any expense is an obstacle to adoption. It's not insurmountable--if you make enough noise, you can get the few dozen copies of some Fortran compiler that you need--but if something is free, it's much more likely to be used.
Non-free compilers are also a big headache to install. When I install a Linux cluster, the free compilers and runtimes are just there and work. If I buy a third party compiler, I need to worry about licenses and separate installation. Who needs that hassle?
my current project [...] is relying on the fact that there will be free [Fortran 9x] compilers around when it is released.
This is actually a good point. MS, by promoting a ruthlessly standardized desktop environment, has managed to get large numbers of people quite used to doing things one way (the MS way, that is)
Which "ruthlessly standard desktop environment" would that be? 95? 98? ME? NT? 2000? XP? They are all quite a bit different, you know, and they all require retraining and relearning. And each of them can be customized in lots and lots of ways. With third party apps, you can completely change their behavior.
Sorry, Microsoft's secret isn't some great master plan or some fundamental insight into technology or marketing, it's having a near monopoly on desktop systems. That's why they can get away with everything.
By eleminating diversity, the MS designers have quite neatly gotten a psychological lock into the minds of many people. Gamers tend to switch more easily because games don't follow the MS standard interface, but non-gamers are very used to/addicted to the MS look and feel.
If that were all that mattered, then Linux could take over easily: there are plenty of window managers and toolkits that emulate Windows more closely than one release of Windows emulates a previous one.
I use it everywhere. It works, it does just the things one wants a desktop environment to do, out of the box, and it's light and fast, as advertised. It's basically Macintosh simplicity come to Linux, without the sluggishness and memory usage of Macintosh system software. XFCE3 looked a bit too much like CDE, but XFCE4 looks nicer in addition to working well.
X11 has had dxpc, the "Differential X Protocol Compressor" for many years. Yes, it works. Of course, LBX is now built into the server, although dxpc seems better. JCraft has a Java implementation of dxpc.
While it's a vast improvement over Fortran 77, I suspect most modernprogrammers Fortran 9x is not a particularly pleasant language to program in compared to many other languages; most developers probably wouldn't use it even if it had decent Linux support.
The "F" compiler breaks the one thing that makes Fortran 9x still somewhat attractive: fairly seamless backwards compatibility with Fortran 77. With Fortran 9x, at least you can take dusty deck Fortran 77 programs and without too much work add "advanced" features like dynamic memory allocation to them.
However, the fact that there are no open source Fortran 9x compilers for Linux is probably an additional problem for its adoption. People who might otherwise try to port Fortran 77 programs to Fortran 9x now just rewrite the stuff in C++. But, hey, overall, we are probably better off because of that.
I fail to see the reason for sarcasm. Yes, it sounds like in this case, punctuality may not have mattered. But in other cases, the difference between 11:59pm and 12:01am could be billions of dollars.
When a court sets a deadline, people should be expected to stick to it. If, in this case, the court decided that it wanted to ignore its own deadline, that's its choice. But would have been perfectly acceptable and entirely reasonable for it to throw out any documents submitted even a second late.
[HP] is sending a message that it believes that the risk of there ultimately being a problem is lower than the losses it will suffer if its customers don't trust Linux.
Yes, and what that is saying is that HP may believe the risk to be modest or small, but not negligible. If HP believed the risk to be negligible, then nobody would need indemnification in the first place. By analogy, people have homeowners insurance, but they don't have insurance against a meteor hitting them no the head--it's just too improbable to worry about.
And, in fact, even if SCO had a 50-50 chance of prevailing, it would probably still make sense for HP to indemnify: they probably make far more on each Linux sale than what SCO would win per copy, and gains in marketshare from HP's indemnification offer may further make offering indemnification quite rational for HP even if SCO had a reasonable case.
Indemnification does not imply that what is being indemnified against is a valid claim.
Do you have insurance against a meteor hitting you on the head? I kind of doubt it: the probability is far too low. But you probably have homeowners insurance and car insurance because those losses are fairly probable.
If someone tries to sell you an indemnification (which is really just a kind of insurance), then they are telling you that there is a real risk that you may get sued. So, by offering you indemnification, Sun and HP are telling you that there is a non-negligible probability that SCO will prevail.
Furthermore, if Sun and HP manage to cement the perception that corporations cannot run Linux without paying some deep-pocketed UNIX licensee, then Linux has effectively become non-free. Therefore, Sun's and HP's indemnification is an attack on the open source and free software nature of Linux.
I think trying to design office space like that is self-defeating. Some of the most exciting science and engineering has happened in basements, shacks, Soviet-style office buildings, etc. Those places work not because some architect came in and set them up according to some fancy ideas, but because the people working in them adapted them to their work. Fancy furniture and construction is more of an obstacle to that than an aid, since they make occupant-driven changes much harder. If the place looks like a dump to begin with, you won't mind putting stuff where it is most useful, rather than where it looks best.
Top 0.1% of what? Windows programmers? Do many people really have any ambition to be in that slice of the population?
And is the company really so attractive? What do they produce? A bunch of small desktop apps for content management, ground out laboriously using Microsoft's dull development tools. Where is the vision in that? Where is the excitement in that?
And then, as a company, where are the retirement benefits? Stability? Career path? Where are those employees going to be 10 years from now? 20 years from now?
HP's and Sun's indemnification of Linux users who have purchased Linux from them is bad for open source. SCO is right: it acknowledges that SCO's claims are plausible.
Furthermore, it points the way by which companies could make open source software effectively proprietary: company A gets company B to make allegations and threaten lawsuits and then company A sells indemnifications. If company A plays their cards right, they come out looking OK, they don't run afoul of the GPL intellectual property provisions, yet they still can make money off the software when others can't as easily.
To me, these "indemnifications" from Sun and HP really amount to an insult of open source developers and an attack on the integrity of open source. The sooner Sun and HP stop this practice, the better.
These attempts at indemnification are not good. Why? Because they are some way down the road of taking an open source project and making it proprietary. Imagine Sun or HP had wanted to make money from Linux. They could have paid SCO to do what they did and then planned on making money from indemnifications.
Note also that th indemnification is probably not worth all that much: do you really think you are the one they would come after? And how much could they realistically get for a piece of software you used in good faith?
And if it were to turn out that the indemnification was needed, you wouldn't be able to use Linux much longer anyway because its redistribution would automatically become impossible under the GPL.
Do we really, or have enough people believing that made it a self fulfilling prophecy?
No, we really do know that increasing greenhouse gas concentrations cause increasing temperatures--that's very simple thermodynamics. The thing we don't know is how significant the influence of positive and negative feedback mechanisms is on top of that.
Without feedback, the rise in global temperatures due to greenhouse gas emissions right now would still be quite small. The question climatologists are debating is to what degree there are already positive feedback mechanisms in play.
All the models that climatologists and meteorologists run are based on assumptions and limited variables.
The models that climatologists run explore different feedback mechanisms; all of them involve global warming.
Some pretty plausible scenarios actually say that the global warming effect of current emissions is still pretty small, but that, once we cross some threshold, there is runaway global warming.
Given the fossil record of ice age / thaw that has occured in the past I can't even begin to discount that we are just approaching the high point of a natural cycle and that no matter what we do the planet will get hotter for a few years, then start to cool again.
Again, that's completely irrelevant to the question of whether continued production of increasing quantities of greenhouse gases is safe.
Even if we knew with 100% certainty that the current temperature trends were entirely unrelated to human activity, it would not have any significant policy implications. At issue is not whether the current greenhouse gas levels are safe, at issue is the question of whether increasing greenhouse gas levels further is safe, and basic physics tells us that there exists a level beyond which we are in serious trouble. And because it is quite likely that there are positive feedback mechanisms and because it takes a long time to clear greenhouse gases from the atmosphere, by the time we actually observe trouble empirically, it is probably far too late to do anything about it.
It's like Russian roulette: while you are able to play it, you have no concrete evidence that it is dangerous; when you get a demonstration of the danger, it's too late to do you any good.
Meanwhile, continue to try to commoditize hardware by pushing Java, even though you are a hardware company and that's the last thing in the world you should want.
You don't understand Sun's Java strategy. Despite all the talk of openness and the smokescreen of the JCP, the cold hard fact is that Sun owns Java: they own the patents, they control certification, and they own the only implementations of key parts of the platform, like Swing.
Every Linux or Windows programmer that uses Java is directly or indirectly under Sun's control. And that is Sun's goal and purpose with Java.
Also: "IBM is being so hypocritical. If the issue is a non-issue, why don't they indemnify their customers?"
No, IBM is consistent, Sun is being hypocritical. Sun is using SCO to create fear so that they can make money from selling Linux by "indemnifying" their users. If SCO didn't exist, Sun would have to create them in order to make money from Linux (if they aren't actually one of the sponsors of SCO anyway).
Here is another quote from Sun's Schwartz:
Sun Executive Vice President of Software Jonathan Schwartz told an audience here at LinuxWorld Conference & Expo on Tuesday to worry more about the quality of their code than the software licenses that govern it.
This is exceptionally bad advice. Open source developers always need to worry about software licenses first. The SCO lawsuit has demonstrated that again very clearly.
Both what Sun is doing with SCO and what Sun is doing with Java/JCP is to try and make open source software somehow dependent on Sun. In the case of SCO, they are trying to make Linux into a Sun commercial product with the argument that it may not be legal unless you buy it from Sun. In the case of Java, Sun is trying to replace Linux APIs and toolkits and make their own proprietary platform an essential requirement for running any software.
And that's not where it ends either; if you actually read the Sun licenses attached to Java, the Java specifications, and the JCP carefully, you'll see that open source projects based on them may well end up under the control of Sun.
Don't trust Sun: Sun and their policies are a huge threat to open source. And what makes them particularly dangerous is that, unlike Microsoft, many people don't understand how dangerous Sun really is.
To state that the increase in CO2 is undeniably causing the increase in temperature is just bad science.
We don't know whether all the temperature increase we are seeing right now is due to greenhouse gases, but we know beyond any reasonable doubt that emission of greenhouse gases increases global temperatures. The only thing we don't know is whether we have yet reached the point where our emissions are already harmful, or whether that will just take a few more decades.
I have no agenda but to get at truth.
But the "truth" you are concerned with is not relevant to the question of climate change. The truth that we can't be completely certain whether we already are experiencing harmful climage change to greenhouse gas emissions simply doesn't matter. The truth we need to worry about is whether greenhouse gas emissions can cause harmful climate change in principle, and that truth is beyond doubt. Do you need to shoot yourself in the head before you are convinced that a gun is dangerous?
In fact, whether you know it or not, you do have an agenda: the same agenda of people who, for selfish economic reasons, prefer the status quo. For society as a whole, reducing greenhouse gas emissions substantially is economically beneficial and the only environmentally sound choice.
Slashdot Mirror
There is no way to get consistency in a window system. People will port their favorite window managers and toolkits to whatever window system you create. MS Windows runs many of the same toolkits that X11 does. Apple is even worse, officially supporting OS 9, Carbon, Swing, and Cocoa-based applications on the same desktop, and now also X11; and in addition to all that, toolkits like Gtk+, FLTK, Swing are also being ported to native Quartz backends.
If you want consistency on your desktop, just choose to use a consistent set of applications. Most non-computer experts can't even tell the difference between an MFC, Gnome, KDE, and wxWindows application: they all look equally flaky and confusing to them. And most people incorrectly think that something is an OS X native application if it has shiny gumdrop buttons. In short, most people neither know nor care.
Lots of operating systems have had disk-at-a-time encryption. You can already get it for Windows, but that was apparently not good enough to have that PPT junkie use it either.
Disk-at-a-time (or file-system-at-a-time) encryption just doesn't seem to be convenient enough. Most files simply do not need to be encrypted, and the risk of losing an entire disk due to bugs or losing the pass phrase is just too high, as is the computational cost. People need to be able to decide on a per-file basis what gets encrypted and pick different pass phrases for different files.
In fact, file-at-a-time encryption shouldn't be in the kernel, it is implementable in user code if you have the right hooks. You can build that on top of Plan 9's file system hooks or on top of the CODA hooks in the Linux kernel. Something like the Plastic file system for Linux also would work. But it can also be done at the kernel level; ReiserFS may get file-at-a-time encryption soon.
By the way, if you do want disk-at-a-time encryption, StegFS strikes me as a better choice.
While UDP clearly was the wrong choice, TCP isn't the right choice either: TCP is a reliable, connection-oriented stream protocol. But for file and device access, you want a reliable connectionless protocol.
There are a number of choices. Plan 9 defined IL for just this purpose, there is SCTP for telephony applications, and several operating systems support RDM ("reliably delivered message"). Maybe people should just start using one of them, rather than reinventing the wheel by building on top of unreliable datagrams or by using protocols with unnecessary overhead.
Venter published the human genome years ahead schedules.
So what? It's still a mechanical process with little scientific insight. If anything, the people who developed the sequencing machines should be rewarded, but even that was more of an engineering feat.
The array syntax in F9X can be applied to arbitrary classes (or "derived types" as they are known) via operator overloading
Too bad that those derivation mechanisms and operator overloading are not sufficiently powerful to actually implement efficient, general purpose array-like classes like you can in C++.
[No Fortran compiler can keep up with [handcrafted libraries]] Of course not, but neither can a C or C++ compiler. I'm not seeing your point here
In C++, those libraries can be wrapped up so that they look and feel exactly like any other built-in datatype. In Fortran, that is impossible.
From your comment, I can see that you are one of those people who likes to talk about Fortran, but actually knows nothing about it. [...] I don't find it so; but you, with yourcompletly-unwarranted prejudices about a language you obviously know nothing of, are free to do so
I gave Fortran 90 and Fortran 95 a good try when they came out. I picked apart the language and its semantics carefully. I downloaded, benchmarked, and bought several compilers. I ported quite a bit of my Fortran 77 and C++ code to it. Initially, it seemed like a promising alternative to C++, but the evolution of Fortran went off on a side-track and it never fulfilled its promise. In contrast, the C++ committee pulled through and did a lot of really hard work to beat C++ into shape, and they created a winner.
If your needs are simple enough that current Fortran standards satisfy them, good for you. But there won't be a "Fortran renaissance". Modern scientific and engineering computing has moved resolutely away from Fortran. You don't need to look any further than at what languages scientists and engineers are actually taught at university.
So, animals are not indiginous to the americas. I say we remove them all, restoring the land to it's natural state.
Your cynicism is misplaced and betrays a lack of understanding. The motivation behind restoring ecosystems to their "natural state" is not to make them conform to some silly romantic ideals, it is a simple, practical motivation: when foreign species invade, the consequences are often diseases, pests, reduced productivity, and erosion. Restoring the ecosystem to its "natural" state, a state that may have existed stably for millions of years is simply prudent, practical resource management.
After all there's a Nobel Prize out there for someone in the genome business.
I dunno--is there a Nobel Prize out there for the head librarian at the Library of Congress? If you think about it, sequencing genomes is a pretty mechanical process, and pushing it ahead by a few years, like Venter did, is not necessarily such a big deal either.
F9x is an absolute joy to program in -- just the array syntax alone makes it so.
C++ supports equivalent array syntax. Furthermore, in C++, library developers can create natural syntax for arbitrary classes, not just the few things that are built-in.
And, despite what some C++ advocates may claim, it still holds the edge in terms of efficiency, when it comes to numerical simulations.
Even if that were true, it wouldn't matter. Using Fortran involves extra programming time and extra expenses for software. Overall, you get less bang-for-the-buck even if your Fortran program were to run somewhat faster.
But it isn't even true. C++ compilers are very good, and Fortran compilers are being neglected more and more. Furthermore, for the truly high-performance stuff, people are increasingly relying on large libraries of hand-crafted, processor-specific routines (BLAS, SparseBLAS, OpenGL, etc.). No Fortran compiler can keep up with that.
Think about it: most people who program in Fortran are actually using the language to solve numerical problems in some other discipline (such as engineering, or in my case astrophysics);
Yes, but your reasoning is backwards. Of course, "most" Fortran programmers are satisfied with its limited feature set. But most people who write scientific and engineering applications aren't solving purely numerical problems and Fortran is far too limiting for them. The fraction of scientists and engineers whose needs are actually addressed by Fortran is small and shrinking.
Since these typical users are either embedded in a university department or a corporation, there are ample funds to buy whatever F9X compiler they might need.
"Ample funds" at a university or a corporation? What rock are you living under? Having worked in both environments, I can assure you that any expense is an obstacle to adoption. It's not insurmountable--if you make enough noise, you can get the few dozen copies of some Fortran compiler that you need--but if something is free, it's much more likely to be used.
Non-free compilers are also a big headache to install. When I install a Linux cluster, the free compilers and runtimes are just there and work. If I buy a third party compiler, I need to worry about licenses and separate installation. Who needs that hassle?
my current project [...] is relying on the fact that there will be free [Fortran 9x] compilers around when it is released.
Hope springs eternal.
I'm not sure why saying much about XFce's use of Java should get even more mention.
Let's be clear: XFCE doesn't use Java. If it did, it would neither be small, light, fast, or free.
This is actually a good point. MS, by promoting a ruthlessly standardized desktop environment, has managed to get large numbers of people quite used to doing things one way (the MS way, that is)
Which "ruthlessly standard desktop environment" would that be? 95? 98? ME? NT? 2000? XP? They are all quite a bit different, you know, and they all require retraining and relearning. And each of them can be customized in lots and lots of ways. With third party apps, you can completely change their behavior.
Sorry, Microsoft's secret isn't some great master plan or some fundamental insight into technology or marketing, it's having a near monopoly on desktop systems. That's why they can get away with everything.
By eleminating diversity, the MS designers have quite neatly gotten a psychological lock into the minds of many people. Gamers tend to switch more easily because games don't follow the MS standard interface, but non-gamers are very used to/addicted to the MS look and feel.
If that were all that mattered, then Linux could take over easily: there are plenty of window managers and toolkits that emulate Windows more closely than one release of Windows emulates a previous one.
I use it everywhere. It works, it does just the things one wants a desktop environment to do, out of the box, and it's light and fast, as advertised. It's basically Macintosh simplicity come to Linux, without the sluggishness and memory usage of Macintosh system software. XFCE3 looked a bit too much like CDE, but XFCE4 looks nicer in addition to working well.
X11 has had dxpc, the "Differential X Protocol Compressor" for many years. Yes, it works. Of course, LBX is now built into the server, although dxpc seems better. JCraft has a Java implementation of dxpc.
While it's a vast improvement over Fortran 77, I suspect most modernprogrammers Fortran 9x is not a particularly pleasant language to program in compared to many other languages; most developers probably wouldn't use it even if it had decent Linux support.
The "F" compiler breaks the one thing that makes Fortran 9x still somewhat attractive: fairly seamless backwards compatibility with Fortran 77. With Fortran 9x, at least you can take dusty deck Fortran 77 programs and without too much work add "advanced" features like dynamic memory allocation to them.
However, the fact that there are no open source Fortran 9x compilers for Linux is probably an additional problem for its adoption. People who might otherwise try to port Fortran 77 programs to Fortran 9x now just rewrite the stuff in C++. But, hey, overall, we are probably better off because of that.
I fail to see the reason for sarcasm. Yes, it sounds like in this case, punctuality may not have mattered. But in other cases, the difference between 11:59pm and 12:01am could be billions of dollars.
When a court sets a deadline, people should be expected to stick to it. If, in this case, the court decided that it wanted to ignore its own deadline, that's its choice. But would have been perfectly acceptable and entirely reasonable for it to throw out any documents submitted even a second late.
[HP] is sending a message that it believes that the risk of there ultimately being a problem is lower than the losses it will suffer if its customers don't trust Linux.
Yes, and what that is saying is that HP may believe the risk to be modest or small, but not negligible. If HP believed the risk to be negligible, then nobody would need indemnification in the first place. By analogy, people have homeowners insurance, but they don't have insurance against a meteor hitting them no the head--it's just too improbable to worry about.
And, in fact, even if SCO had a 50-50 chance of prevailing, it would probably still make sense for HP to indemnify: they probably make far more on each Linux sale than what SCO would win per copy, and gains in marketshare from HP's indemnification offer may further make offering indemnification quite rational for HP even if SCO had a reasonable case.
Indemnification does not imply that what is being indemnified against is a valid claim.
Do you have insurance against a meteor hitting you on the head? I kind of doubt it: the probability is far too low. But you probably have homeowners insurance and car insurance because those losses are fairly probable.
If someone tries to sell you an indemnification (which is really just a kind of insurance), then they are telling you that there is a real risk that you may get sued. So, by offering you indemnification, Sun and HP are telling you that there is a non-negligible probability that SCO will prevail.
Furthermore, if Sun and HP manage to cement the perception that corporations cannot run Linux without paying some deep-pocketed UNIX licensee, then Linux has effectively become non-free. Therefore, Sun's and HP's indemnification is an attack on the open source and free software nature of Linux.
I think trying to design office space like that is self-defeating. Some of the most exciting science and engineering has happened in basements, shacks, Soviet-style office buildings, etc. Those places work not because some architect came in and set them up according to some fancy ideas, but because the people working in them adapted them to their work. Fancy furniture and construction is more of an obstacle to that than an aid, since they make occupant-driven changes much harder. If the place looks like a dump to begin with, you won't mind putting stuff where it is most useful, rather than where it looks best.
Top 0.1% of what? Windows programmers? Do many people really have any ambition to be in that slice of the population?
And is the company really so attractive? What do they produce? A bunch of small desktop apps for content management, ground out laboriously using Microsoft's dull development tools. Where is the vision in that? Where is the excitement in that?
And then, as a company, where are the retirement benefits? Stability? Career path? Where are those employees going to be 10 years from now? 20 years from now?
HP's and Sun's indemnification of Linux users who have purchased Linux from them is bad for open source. SCO is right: it acknowledges that SCO's claims are plausible.
Furthermore, it points the way by which companies could make open source software effectively proprietary: company A gets company B to make allegations and threaten lawsuits and then company A sells indemnifications. If company A plays their cards right, they come out looking OK, they don't run afoul of the GPL intellectual property provisions, yet they still can make money off the software when others can't as easily.
To me, these "indemnifications" from Sun and HP really amount to an insult of open source developers and an attack on the integrity of open source. The sooner Sun and HP stop this practice, the better.
These attempts at indemnification are not good. Why? Because they are some way down the road of taking an open source project and making it proprietary. Imagine Sun or HP had wanted to make money from Linux. They could have paid SCO to do what they did and then planned on making money from indemnifications.
Note also that th indemnification is probably not worth all that much: do you really think you are the one they would come after? And how much could they realistically get for a piece of software you used in good faith?
And if it were to turn out that the indemnification was needed, you wouldn't be able to use Linux much longer anyway because its redistribution would automatically become impossible under the GPL.
Do we really, or have enough people believing that made it a self fulfilling prophecy?
No, we really do know that increasing greenhouse gas concentrations cause increasing temperatures--that's very simple thermodynamics. The thing we don't know is how significant the influence of positive and negative feedback mechanisms is on top of that.
Without feedback, the rise in global temperatures due to greenhouse gas emissions right now would still be quite small. The question climatologists are debating is to what degree there are already positive feedback mechanisms in play.
All the models that climatologists and meteorologists run are based on assumptions and limited variables.
The models that climatologists run explore different feedback mechanisms; all of them involve global warming.
Some pretty plausible scenarios actually say that the global warming effect of current emissions is still pretty small, but that, once we cross some threshold, there is runaway global warming.
Given the fossil record of ice age / thaw that has occured in the past I can't even begin to discount that we are just approaching the high point of a natural cycle and that no matter what we do the planet will get hotter for a few years, then start to cool again.
Again, that's completely irrelevant to the question of whether continued production of increasing quantities of greenhouse gases is safe.
Even if we knew with 100% certainty that the current temperature trends were entirely unrelated to human activity, it would not have any significant policy implications. At issue is not whether the current greenhouse gas levels are safe, at issue is the question of whether increasing greenhouse gas levels further is safe, and basic physics tells us that there exists a level beyond which we are in serious trouble. And because it is quite likely that there are positive feedback mechanisms and because it takes a long time to clear greenhouse gases from the atmosphere, by the time we actually observe trouble empirically, it is probably far too late to do anything about it.
It's like Russian roulette: while you are able to play it, you have no concrete evidence that it is dangerous; when you get a demonstration of the danger, it's too late to do you any good.
Meanwhile, continue to try to commoditize hardware by pushing Java, even though you are a hardware company and that's the last thing in the world you should want.
You don't understand Sun's Java strategy. Despite all the talk of openness and the smokescreen of the JCP, the cold hard fact is that Sun owns Java: they own the patents, they control certification, and they own the only implementations of key parts of the platform, like Swing.
Every Linux or Windows programmer that uses Java is directly or indirectly under Sun's control. And that is Sun's goal and purpose with Java.
Also: "IBM is being so hypocritical. If the issue is a non-issue, why don't they indemnify their customers?"
No, IBM is consistent, Sun is being hypocritical. Sun is using SCO to create fear so that they can make money from selling Linux by "indemnifying" their users. If SCO didn't exist, Sun would have to create them in order to make money from Linux (if they aren't actually one of the sponsors of SCO anyway).
Here is another quote from Sun's Schwartz:
Sun Executive Vice President of Software Jonathan Schwartz told an audience here at LinuxWorld Conference & Expo on Tuesday to worry more about the quality of their code than the software licenses that govern it.
This is exceptionally bad advice. Open source developers always need to worry about software licenses first. The SCO lawsuit has demonstrated that again very clearly.
Both what Sun is doing with SCO and what Sun is doing with Java/JCP is to try and make open source software somehow dependent on Sun. In the case of SCO, they are trying to make Linux into a Sun commercial product with the argument that it may not be legal unless you buy it from Sun. In the case of Java, Sun is trying to replace Linux APIs and toolkits and make their own proprietary platform an essential requirement for running any software.
And that's not where it ends either; if you actually read the Sun licenses attached to Java, the Java specifications, and the JCP carefully, you'll see that open source projects based on them may well end up under the control of Sun.
Don't trust Sun: Sun and their policies are a huge threat to open source. And what makes them particularly dangerous is that, unlike Microsoft, many people don't understand how dangerous Sun really is.
To state that the increase in CO2 is undeniably causing the increase in temperature is just bad science.
We don't know whether all the temperature increase we are seeing right now is due to greenhouse gases, but we know beyond any reasonable doubt that emission of greenhouse gases increases global temperatures. The only thing we don't know is whether we have yet reached the point where our emissions are already harmful, or whether that will just take a few more decades.
I have no agenda but to get at truth.
But the "truth" you are concerned with is not relevant to the question of climate change. The truth that we can't be completely certain whether we already are experiencing harmful climage change to greenhouse gas emissions simply doesn't matter. The truth we need to worry about is whether greenhouse gas emissions can cause harmful climate change in principle, and that truth is beyond doubt. Do you need to shoot yourself in the head before you are convinced that a gun is dangerous?
In fact, whether you know it or not, you do have an agenda: the same agenda of people who, for selfish economic reasons, prefer the status quo. For society as a whole, reducing greenhouse gas emissions substantially is economically beneficial and the only environmentally sound choice.
Actually, there is a statement on McCarthy's site after all: here.