The common thread between Sendmail, Mozilla, and even Cygnus, is that they all work with Windows.
The rationale goes like this; if you want to take over the desktop, you have to go about it in stages. First you get people used to the new tools they will need: the Cygnus port of the unix shell tools, the Netscape browser, the Apache server, the Sendmail server, etc. Then you point out how close they are to being able to change platforms altogether, and how much better their favorite tools run under Linux.
Anyway, the MPL is completely free, and the NPL is only unfree to the extent required for Navigator to continue to exist while Mozilla evolves.
I don't think Netscape were holding back, they just somewhat realistically realized that killing off Navigator to get Mozilla would be sort of stupid. The situation that Mozilla was in was similar to that of BSD when it was first released. They were still dependent on proprietary code for parts of the product.
The problem with the MPL isn't that it is not free, rather that some corporations refuse to contribute to it because it isn't as well understood as the GPL, and the cross licensing of patents is scary for a big company.
Well, for what it is worth, we've been planning to open source the product since the project started.
The reason for that isn't to save a dying product, or even to leverage free development. It is simply that for this bird to fly it has to be set free; one company trying to own and control the marketplace leads to division. To create a universal marketplace we must be willing to give up control and compete after the fact instead of before.
Fundamentally this is the same argument that Tim Berners-Lee makes about releasing the source to the original web daemon unencumbered:
We are already asking people to put their most valuable asset (their business) online using our product; asking anything more is too much.
Interesting read. I'm not sure I agree with their reasoning; in fact I don't even think they pointed out what are arguably their strongest advantages, which implies to me that this was written at a pretty low level without a lot of thought or input. The Halloween documents in my opinion had a much better analysis of what we are doing right and what we are doing wrong.
I started working last winter on a real competitive analysis of Microsoft that I haven't had time to finish. I suppose I never will if I don't put it out for review, so in the interest of understanding our competitor, please feel free to drop by posit.net take a look over the competitive analysis and let me know what you think.
With luck we can form a strong vision of the distinction between Linux and Windows which will help people to understand exactly why Linux is better for their needs.
I have friends who keep all kinds of data on their pilots. e-Books, Travel Guides, phone numbers for all of the service stations/hotels/ airlines in the U.S.
In fact I have a friend who just had his palm stolen (together with his laptop, ouch!) and replaced it with the 3x mostly because he couldn't fit the data he usually keeps around on the 5.
Even most Linux users wouldn't claim that Linux is set to overrun the desktop. In its desktop role Linux is in a niche market of computer hobbyists. Most would argue that the cost of administrating any UNIX system will be too high for mom and dad to get interested in using the system.
What Sun is arguing IMHO is that new users coming on line in the future will be less and less interested in managing their systems (upgrading software, operating systems, managing access, etc.) and only interested in running the latest app which the system should ideally automatically offer them.
As such Sun doesn't need to kill off Linux, they need Linux and Windows compatibility to show that they are offering a reasonable alternative that is just less work.
Over time it is possible that some people who are fed up with maintaining their own systems will move over to NCs, but I think that killing the standalone StarOffice would only be shooting themselves in the foot by killing the credibility of the NC as other OS's are forced to move to new formats.
It is more secure because it requires that you actually have the card itself, not just the number on the card.
The card is described as having an intelligent chip. I presume that means that it isn't a simple swipe, but a negotiation between the card and the authorization agency. Ideally it would additionally require a secret that only the card owner knows.
Something you know, something you have, and something you are are the canonical authentication mechanisms. Most systems use only one or two of the three since for example retinal scanners are a bit expensive.
Slashdot only uses the something that you know (your login and password) since the results of compromise are not disastrous, and the difficulty of getting people to properly protect other forms of identity keys is tricky.
There is a mechanism for key revocation... they can just upgrade the OS. Over time the old key would be increasingly difficult to use despite having been compromised.
Since the keys are cryptographically secure, the most likely scenario is not that the key would be compromised by a hard-crack, but by someone within Microsoft who works with the private key (signing packages) and who decides to give it to someone who asks nicely.
Microsoft would (I imagine) immediately post a service patch which (among other things) removes the old key, and replaces all of the old crypto modules with new ones. The new modules would then work everywhere (even on unpatched machines), but the old modules would only work on old machines, which would gradually become obsolete. Since there isn't any way to force people to accept a certificate revocation, this seems as reasonable a way as any to manage such a problem (at least to me.)
To answer this question you'd have to understand how CPU architectures have changed in the last ten years. Optimization today requires that the compiler reorder instructions using internal knowledge of how the processor works, provide branch prediction information, instruction packing into compatible groups, prefetch and invalidation support, code for recovery from speculative execution failure, and indication to the CPU of what status register flags will be used in the future so that instruction scheduling can potentially be offloaded to a faster ALU if certain flags can be ignored.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
I don't write compilers myself, but I know that there is a lot of research being done in these areas, complete with just as many new patents on those algorithms as you would probably anticipate.
I have likewise worked as both contractor and as permanent employee, and I definitely treated my job very differently in those two situations.
As a contractor your job is to understand what your client wants, and to get it implemented as quickly as possible. Either you are being brought in to kick off a project, in which case funding for the project is probably contingent on getting a good demo working in internet time; or you are being brought in to get a product completed that is on short deadline (or overdue) and for which every day of delay is costing your client money.
My motto as a contractor was 'quick and dirty', the regular employees can rewrite as needed to get the code base back under control. (Which doesn't mean I wouldn't comment, but when it came down to a choice between elegance and speed, speed always wins.)
As an employee my job is to make sure that the project I am working on actually targets the market needs that the project has identified. Often I am writing the requirements rather than implementing them; and I spend more than half my time understanding what the real problem is, in addition to what my manager thinks that the problem is.
And when I code as an employee, I code for the long term. I've set schedules up front, and those schedules are sufficient to produce tight, elegant, maintainable code, which includes architecture docs, design docs, some analysis of market research, and reviews.
Slashdot Mirror
The common thread between Sendmail, Mozilla, and even Cygnus, is that they all work with Windows.
The rationale goes like this; if you want to take over the desktop, you have to go about it in stages. First you get people used to the new tools they will need: the Cygnus port of the unix shell tools, the Netscape browser, the Apache server, the Sendmail server, etc. Then you point out how close they are to being able to change platforms altogether, and how much better their favorite tools run under Linux.
Anyway, the MPL is completely free, and the NPL is only unfree to the extent required for Navigator to continue to exist while Mozilla evolves.
I don't think Netscape were holding back, they just somewhat realistically realized that killing off Navigator to get Mozilla would be sort of stupid. The situation that Mozilla was in was similar to that of BSD when it was first released. They were still dependent on proprietary code for parts of the product.
The problem with the MPL isn't that it is not free, rather that some corporations refuse to contribute to it because it isn't as well understood as the GPL, and the cross licensing of patents is scary for a big company.
Well, for what it is worth, we've been planning to open source the product since the project started.
The reason for that isn't to save a dying product, or even to leverage free development. It is simply that for this bird to fly it has to be set free; one company trying to own and control the marketplace leads to division. To create a universal marketplace we must be willing to give up control and compete after the fact instead of before.
Fundamentally this is the same argument that Tim Berners-Lee makes about releasing the source to the original web daemon unencumbered:
We are already asking people to put their most valuable asset (their business) online using our product; asking anything more is too much.
-kls
Interesting read. I'm not sure I agree with their reasoning; in fact I don't even think they pointed out what are arguably their strongest advantages, which implies to me that this was written at a pretty low level without a lot of thought or input. The Halloween documents in my opinion had a much better analysis of what we are doing right and what we are doing wrong.
I started working last winter on a real competitive analysis of Microsoft that I haven't had time to finish. I suppose I never will if I don't put it out for review, so in the interest of understanding our competitor, please feel free to drop by posit.net take a look over the competitive analysis and let me know what you think.
With luck we can form a strong vision of the distinction between Linux and Windows which will help people to understand exactly why Linux is better for their needs.
-kls
In fact I have a friend who just had his palm stolen (together with his laptop, ouch!) and replaced it with the 3x mostly because he couldn't fit the data he usually keeps around on the 5.
Even most Linux users wouldn't claim that Linux is set to overrun the desktop. In its desktop role Linux is in a niche market of computer hobbyists. Most would argue that the cost of administrating any UNIX system will be too high for mom and dad to get interested in using the system.
What Sun is arguing IMHO is that new users coming on line in the future will be less and less interested in managing their systems (upgrading software, operating systems, managing access, etc.) and only interested in running the latest app which the system should ideally automatically offer them.
As such Sun doesn't need to kill off Linux, they need Linux and Windows compatibility to show that they are offering a reasonable alternative that is just less work.
Over time it is possible that some people who are fed up with maintaining their own systems will move over to NCs, but I think that killing the standalone StarOffice would only be shooting themselves in the foot by killing the credibility of the NC as other OS's are forced to move to new formats.
-kls
Just add an SOA to your DNS configuration for
doubleclick.com and alias it to 127.0.0.1
-kls
It is more secure because it requires that you actually have the card itself, not just the number on the card.
The card is described as having an intelligent chip. I presume that means that it isn't a simple swipe, but a negotiation between the card and the authorization agency. Ideally it would additionally require a secret that only the card owner knows.
Something you know, something you have, and something you are are the canonical authentication mechanisms. Most systems use only one or two of the three since for example retinal scanners are a bit expensive.
Slashdot only uses the something that you know (your login and password) since the results of compromise are not disastrous, and the difficulty of getting people to properly protect other forms of identity keys is tricky.
There is a mechanism for key revocation... they can just upgrade the OS. Over time the old key would be increasingly difficult to use despite having been compromised.
Since the keys are cryptographically secure, the most likely scenario is not that the key would be compromised by a hard-crack, but by someone within Microsoft who works with the private key (signing packages) and who decides to give it to someone who asks nicely.
Microsoft would (I imagine) immediately post a service patch which (among other things) removes the old key, and replaces all of the old crypto modules with new ones. The new modules would then work everywhere (even on unpatched machines), but the old modules would only work on old machines, which would gradually become obsolete. Since there isn't any way to force people to accept a certificate revocation, this seems as reasonable a way as any to manage such a problem (at least to me.)
To answer this question you'd have to understand how CPU architectures have changed in the last ten years. Optimization today requires that the compiler reorder instructions using internal knowledge of how the processor works, provide branch prediction information, instruction packing into compatible groups, prefetch and invalidation support, code for recovery from speculative execution failure, and indication to the CPU of what status register flags will be used in the future so that instruction scheduling can potentially be offloaded to a faster ALU if certain flags can be ignored.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
I don't write compilers myself, but I know that there is a lot of research being done in these areas, complete with just as many new patents on those algorithms as you would probably anticipate.
I have likewise worked as both contractor and as permanent employee, and I definitely treated my job very differently in those two situations.
As a contractor your job is to understand what your client wants, and to get it implemented as quickly as possible. Either you are being brought in to kick off a project, in which case funding for the project is probably contingent on getting a good demo working in internet time; or you are being brought in to get a product completed that is on short deadline (or overdue) and for which every day of delay is costing your client money.
My motto as a contractor was 'quick and dirty', the regular employees can rewrite as needed to get the code base back under control. (Which doesn't mean I wouldn't comment, but when it came down to a choice between elegance and speed, speed always wins.)
As an employee my job is to make sure that the project I am working on actually targets the market needs that the project has identified. Often I am writing the requirements rather than implementing them; and I spend more than half my time understanding what the real problem is, in addition to what my manager thinks that the problem is.
And when I code as an employee, I code for the long term. I've set schedules up front, and those schedules are sufficient to produce tight, elegant, maintainable code, which includes architecture docs, design docs, some analysis of market research, and reviews.