It's worth remembering that Darl is likely to walk away with millions of dollars in his pocket. Linus gets at most a sense of vindication. There is no justice.
Yes, to date SCO have not sued a non-customer in regard to Linux. Take home lesson: don't deal with SCO.
However, they have subpoenaed various Linux contributors and other parties who didn't have any business relationship to SCO. In some cases this seems to be merely a fishing expedition or harrassment. Not as bad as a suit, but still not something I'd like to see in my mailbox.
SCO have also sent letters to non-SCO-customer Linux users threatening a lawsuit, although they have not actually filed suit against one of them as far as we know. It would be accurate for the original poster to ask that SCO stop *threatening to sue* non-customers.
So people should be precise in what they say about SCO, but SCO still suck. I welcome their new future as a Caldera (literally "crater").
As The SCO Group Inc.'s reseller and developer community gathers for its annual SCO Forum convention in Las Vegas this week, one question on many attendees' minds will be whether the company's future will be as a software vendor or as a litigator.
The answer is No, they do not have a future as a software vendor or litigator.
I agree that it would be a good idea for some distros to just pick one. Or at least it makes sense for end-user environments; developers and power users are probably going to want to be able to mix and match.
However, you are going to get some killer applications that are written for only one or the other. I use distccmon-gnome and kcachegrind all the time in development. A machine that didn't have at least the basic libraries for both systems would be far less useful to me. Once the distribution's decided to support both, making them play nicely could be worthwhile.
Anyhow, I think freedesktop will reduce the amount of integration needed, and it will mostly be a choice for application authors. KDE will aim towards C++ and many features (coincidence or not?), GNOME will concentrate on C and elegant simplicity.
Arguably open standards are more important than open source. An open source product can splinter and produce two competing incompatible products, even though they are both open source.
I agree, but standards can fork too. If they fork less often it is only because standards committees tend to move far slower than open source projects. No simple example comes to minds but there have been things standardized slightly differently by both ANSI and ISO.
So in general it's really nice if people will cooperate rather than gratuituously fork either standards or software. But competition can sometimes be helpful (and sometimes destructive.)
Good standards also tend to be written post-hoc; otherwise you tend to get design by commitee. For things we understand well already they're fine.
Be glad you have IP not the government-mandated OSI stack. Be glad you have all the features that went into Linux despite not being standardized yet.
Let's assume for the sake of argument that Microsoft document completely and absolutely every interface and every way it can be used. (Not that *anyone* does that, but let's pretend.)
Microsoft product developers still have more access to the OS developers and to early information about upcoming OS releases than external developers. They probably have more opportunities to ask for new features that would help. Certainly other developers can try, but they're never going to have the same level of access as people who eat in the same cafeteria.
Microsoft apps are going to have anywhere from a few months to a year of lead time on exploiting new OS features. That's worth a lot.
This doesn't make Microsoft evil or anything. (Lying in court does though.) It is pretty rational competitive behaviour. Anyone would exploit synergy between products.
So, if you develop apps on Windows, you're playing on your competitor's home ground. OK, maybe the prize is high enough to justify it, but don't complain if you get beaten up in the carpark. Is it any wonder that ISVs would prefer to play on the more neutral territory of Linux, despite all the other difficulties?
p.s. "ultimate" doesn't mean "best", it really means "final", "last", "eventual". (Though it is kind of drifting towards "supreme".)
The source is your eventual and final destination when you don't find the answer anywhere else. Or maybe the code's author will be, if you can get an answer from them. But if they've forgotten then you're back to the source.
I didn't say "the source is the perfect documentation", or "the source is a substitute for other documentation." I mean that when the documentation fails, as it ultimately will, it's better to be able to read the source than not.
I kind of expected someone would bring out the "Microsoft/Apple/SCO documentation is better than Linux" canard. That may be true in some cases but it's not the point I was making.
Having good docs and also source is better than either alone... much as the best is to have it written by a programmer who's also a good writer.
If you don't already have Robert Love's new kernel book it might be worth reading.
I think that explains why they're doing it. People will use it in the same way that (good) support engineers now use the Linux source.
Someone at work was trying to help a customer with a particular error they got. On Linux it's really easy to look through the source, and see what paths cause that error from that syscall, and that helps in debugging the problem. The source is the ultimate documentation.
Being able to do that on Windows would be nice for people who have to use or support it. I don't suppose Microsoft will get any useful patches back, seeing as people probably won't be able to build it.
Have a look through a few issues of Microsoft Systems Journal. I haven't read it recently, but a few years ago you would regularly see article introductions like "You may have been wondering how Microsoft application XX did cool feature YY..." It goes on to document an interface not previously publicly mentioned (and says so).
Therefore, from Microsoft's own press organ, we know that there are interfaces which are used by shipping Windows applications before they're publicly documented. Some of these are later revealed in MSJ, but there's no reason to think that they necessarily reveal all of them. At the very least Microsoft apps have a one-cycle lead time on competitors; at most the competitors never find out.
There is no reason to think the API documents an existing one, although there are very many duplicated interfaces on Windows. It might do something not otherwise possible, or might wrap up several existing functions.
But anyhow: why would there *not* be such an interface? Microsoft never promised they would document every aspect of their systems. Clearly it is in there interests for the OS to help their own applications.
The point is that once you see the code you are contaminated and any code you write can be considered suspect.
Perhaps you'll be contaminated in the sense of feeling sick in your guts at how awful it is. But I don't think you'll be legally contaminated.
Let's return to the basics: the classes of intellectual property.
1- Patents. Doesn't matter whether you saw the code or not, because independent creation is no defense.
2- Copyright. Only matters if you copy the literal code. Reading the code does not pollute you as long as you don't rewrite the same thing from memory.
3- Trade secrets. Here, there is a possibility of mental contamination. However, trade secrets are only valid if the owner made a reasonable attempt to keep the thing secret in the first place. If they put it up on their web site with only a fine-print footer, it's unlikely (ianal) to be a trade secret.
Maybe MS will try a SCO-style attack on Linux, but intentionally leaking trade secrets is unlikely to be the tactic.
A similar confusion is one reason why SCO are scheduled to be torn limb from limb in a couple of months.
Source code escrow does fix some of the problems with proprietary code from the customer's point of view, but only some:
Most obviously, it's only available for particular large packages. However much money you had, you would not be able to continue with a fork of MS-DOS, because the supplier doesn't want it.
The conditions under which the code becomes available may be limited. If the supplier goes broke or flat-out discontinues the product maybe the code is released. If the project just becomes moribund, uncompetitive or the supplier wants to force an upgrade then you typically cannot get the code.
At a technical level code that was once closed is harder for people to work on. Rather than dozens or hundreds of developers experienced with the internals of a large open-source package there are only a handful of people who know how to work on the code you mention. Even those people might have trouble just getting it to build. Big projects that are built by one group tend to develop lots of hidden dependencies.
Some people have proposed that a condition of copyright registration for software should be that the code is sent to the Library of Congress, to be released when the copyright expires or the work goes effectively out of print. I don't suppose it will happen but it seems like a good idea.
Right, but you could make exactly the same argument about Microsoft. They've pretty much destroyed the market for commercial operating systems, languages and office suites. Seeing as they did actual break the law several times to build and enforce their monopoly I think they're far more culpable than people who merely choose a generous licence for their work.
If customers find that OSS doesn't provide a good solution, or it costs too much to customize/maintain then I'm sure Microsoft will be happy to sell them proprietary software.
The biggest point is probably that Cook requires you to do your builds through Cook, but distcc can fit in with any build system: Make, SCons, Cons, or probably even Cook.
If you don't trust your network, you can run distcc over ssh, just like cvs, svn, rsync,... That gives you good protection against network atacks, and doesn't increase the exposure of the machine at all. Just set DISTCC_HOSTS="me@otherhost"
Of course confidentiality and integrity protection takes cycles, so if you *do* trust your network, you don't need to use it.
Using SSH is a far better approach than a handcrafted authentication system, which would probably be broken in various ways, if other protocols are any indication.
gcc will never be secure against untrusted input, it's just far too complex. Even trying would be an enormous waste of time.
You know, there are few better ways to turn people off Plan9 than to say that every other project sucks. If you want to make sure p9 continues to be ignored, you're doing just the right thing.
I've had a good impression of Plan 9 since I first read about it >10 years ago... until I read your post history. Congratulations.
Slashdot Mirror
Is this a Google job ad? If so, 66b24eeeacbccd0baa0c582982f751ab.
none of the companies that I *would* have bought from (wisely) don't use spam in the first place.
Isn't that kind of tortured grammar banned by the Geneva convention?
FP!
Oh fragjus day!
So what is Jesus Christ's position on heavy weapons? I always pictured him as a double-barrel shotgun kind of guy, but maybe I'm projecting.
It's worth remembering that Darl is likely to walk away with millions of dollars in his pocket. Linus gets at most a sense of vindication. There is no justice.
Yes, to date SCO have not sued a non-customer in regard to Linux. Take home lesson: don't deal with SCO.
However, they have subpoenaed various Linux contributors and other parties who didn't have any business relationship to SCO. In some cases this seems to be merely a fishing expedition or harrassment. Not as bad as a suit, but still not something I'd like to see in my mailbox.
SCO have also sent letters to non-SCO-customer Linux users threatening a lawsuit, although they have not actually filed suit against one of them as far as we know. It would be accurate for the original poster to ask that SCO stop *threatening to sue* non-customers.
So people should be precise in what they say about SCO, but SCO still suck. I welcome their new future as a Caldera (literally "crater").
As The SCO Group Inc.'s reseller and developer community gathers for its annual SCO Forum convention in Las Vegas this week, one question on many attendees' minds will be whether the company's future will be as a software vendor or as a litigator.
The answer is No, they do not have a future as a software vendor or litigator.
I agree that it would be a good idea for some distros to just pick one. Or at least it makes sense for end-user environments; developers and power users are probably going to want to be able to mix and match.
However, you are going to get some killer applications that are written for only one or the other. I use distccmon-gnome and kcachegrind all the time in development. A machine that didn't have at least the basic libraries for both systems would be far less useful to me. Once the distribution's decided to support both, making them play nicely could be worthwhile.
Anyhow, I think freedesktop will reduce the amount of integration needed, and it will mostly be a choice for application authors. KDE will aim towards C++ and many features (coincidence or not?), GNOME will concentrate on C and elegant simplicity.
Arguably open standards are more important than open source. An open source product can splinter and produce two competing incompatible products, even though they are both open source.
I agree, but standards can fork too. If they fork less often it is only because standards committees tend to move far slower than open source projects. No simple example comes to minds but there have been things standardized slightly differently by both ANSI and ISO.
So in general it's really nice if people will cooperate rather than gratuituously fork either standards or software. But competition can sometimes be helpful (and sometimes destructive.)
Good standards also tend to be written post-hoc; otherwise you tend to get design by commitee. For things we understand well already they're fine.
Be glad you have IP not the government-mandated OSI stack. Be glad you have all the features that went into Linux despite not being standardized yet.
Let's assume for the sake of argument that Microsoft document completely and absolutely every interface and every way it can be used. (Not that *anyone* does that, but let's pretend.)
Microsoft product developers still have more access to the OS developers and to early information about upcoming OS releases than external developers. They probably have more opportunities to ask for new features that would help. Certainly other developers can try, but they're never going to have the same level of access as people who eat in the same cafeteria.
Microsoft apps are going to have anywhere from a few months to a year of lead time on exploiting new OS features. That's worth a lot.
This doesn't make Microsoft evil or anything. (Lying in court does though.) It is pretty rational competitive behaviour. Anyone would exploit synergy between products.
So, if you develop apps on Windows, you're playing on your competitor's home ground. OK, maybe the prize is high enough to justify it, but don't complain if you get beaten up in the carpark. Is it any wonder that ISVs would prefer to play on the more neutral territory of Linux, despite all the other difficulties?
I meant, "API duplicates an existing one".
p.s. "ultimate" doesn't mean "best", it really means "final", "last", "eventual". (Though it is kind of drifting towards "supreme".)
The source is your eventual and final destination when you don't find the answer anywhere else. Or maybe the code's author will be, if you can get an answer from them. But if they've forgotten then you're back to the source.
I didn't say "the source is the perfect documentation", or "the source is a substitute for other documentation." I mean that when the documentation fails, as it ultimately will, it's better to be able to read the source than not.
I kind of expected someone would bring out the "Microsoft/Apple/SCO documentation is better than Linux" canard. That may be true in some cases but it's not the point I was making.
Having good docs and also source is better than either alone... much as the best is to have it written by a programmer who's also a good writer.
If you don't already have Robert Love's new kernel book it might be worth reading.
I think that explains why they're doing it. People will use it in the same way that (good) support engineers now use the Linux source.
Someone at work was trying to help a customer with a particular error they got. On Linux it's really easy to look through the source, and see what paths cause that error from that syscall, and that helps in debugging the problem. The source is the ultimate documentation.
Being able to do that on Windows would be nice for people who have to use or support it. I don't suppose Microsoft will get any useful patches back, seeing as people probably won't be able to build it.
Have a look through a few issues of Microsoft Systems Journal. I haven't read it recently, but a few years ago you would regularly see article introductions like "You may have been wondering how Microsoft application XX did cool feature YY..." It goes on to document an interface not previously publicly mentioned (and says so).
Therefore, from Microsoft's own press organ, we know that there are interfaces which are used by shipping Windows applications before they're publicly documented. Some of these are later revealed in MSJ, but there's no reason to think that they necessarily reveal all of them. At the very least Microsoft apps have a one-cycle lead time on competitors; at most the competitors never find out.
There is no reason to think the API documents an existing one, although there are very many duplicated interfaces on Windows. It might do something not otherwise possible, or might wrap up several existing functions.
But anyhow: why would there *not* be such an interface? Microsoft never promised they would document every aspect of their systems. Clearly it is in there interests for the OS to help their own applications.
The point is that once you see the code you are contaminated and any code you write can be considered suspect.
Perhaps you'll be contaminated in the sense of feeling sick in your guts at how awful it is. But I don't think you'll be legally contaminated.
Let's return to the basics: the classes of intellectual property.
1- Patents. Doesn't matter whether you saw the code or not, because independent creation is no defense.
2- Copyright. Only matters if you copy the literal code. Reading the code does not pollute you as long as you don't rewrite the same thing from memory.
3- Trade secrets. Here, there is a possibility of mental contamination. However, trade secrets are only valid if the owner made a reasonable attempt to keep the thing secret in the first place. If they put it up on their web site with only a fine-print footer, it's unlikely (ianal) to be a trade secret.
Maybe MS will try a SCO-style attack on Linux, but intentionally leaking trade secrets is unlikely to be the tactic.
A similar confusion is one reason why SCO are scheduled to be torn limb from limb in a couple of months.
I see the penile inversion page says "category: stub". So true!
Source code escrow does fix some of the problems with proprietary code from the customer's point of view, but only some:
Most obviously, it's only available for particular large packages. However much money you had, you would not be able to continue with a fork of MS-DOS, because the supplier doesn't want it.
The conditions under which the code becomes available may be limited. If the supplier goes broke or flat-out discontinues the product maybe the code is released. If the project just becomes moribund, uncompetitive or the supplier wants to force an upgrade then you typically cannot get the code.
At a technical level code that was once closed is harder for people to work on. Rather than dozens or hundreds of developers experienced with the internals of a large open-source package there are only a handful of people who know how to work on the code you mention. Even those people might have trouble just getting it to build. Big projects that are built by one group tend to develop lots of hidden dependencies.
Some people have proposed that a condition of copyright registration for software should be that the code is sent to the Library of Congress, to be released when the copyright expires or the work goes effectively out of print. I don't suppose it will happen but it seems like a good idea.
Right, but you could make exactly the same argument about Microsoft. They've pretty much destroyed the market for commercial operating systems, languages and office suites. Seeing as they did actual break the law several times to build and enforce their monopoly I think they're far more culpable than people who merely choose a generous licence for their work.
If customers find that OSS doesn't provide a good solution, or it costs too much to customize/maintain then I'm sure Microsoft will be happy to sell them proprietary software.
Yes, you can limit the command if people are allowed to use the machine for compiling and nothing else.
I agree if you find something that makes gcc crash then it should be fixed.
distcc compared to Cook.
The biggest point is probably that Cook requires you to do your builds through Cook, but distcc can fit in with any build system: Make, SCons, Cons, or probably even Cook.
That is true. If you really meant "Apple ship it with a pretty GUI", then you should have said so.
It's a bit bad that the article doesn't mention security, but security has been considered in distcc.
... That gives you good protection against network atacks, and doesn't increase the exposure of the machine at all. Just set DISTCC_HOSTS="me@otherhost"
If you don't trust your network, you can run distcc over ssh, just like cvs, svn, rsync,
Of course confidentiality and integrity protection takes cycles, so if you *do* trust your network, you don't need to use it.
Using SSH is a far better approach than a handcrafted authentication system, which would probably be broken in various ways, if other protocols are any indication.
gcc will never be secure against untrusted input, it's just far too complex. Even trying would be an enormous waste of time.
"Another reason to buy a Mac", when you get the same thing for free with Linux? Uh-huh.
You know, there are few better ways to turn people off Plan9 than to say that every other project sucks. If you want to make sure p9 continues to be ignored, you're doing just the right thing.
I've had a good impression of Plan 9 since I first read about it >10 years ago... until I read your post history. Congratulations.