Microsoft programmers should look up "second system effect": they keep making the same mistake again and again.
If you want to see some good (or at least interesting) directions people have taken shells into, there are Plan 9 rc (same idea as sh, but cleaned up), fish (better interactive features), and Tcl/Tk (shell-like programming for a full scripting language, including the ability to embed Java and C#/CLR objects). And if you want a full scripting language, Perl, Python, and Ruby fit the bill.
A note to FOSS programmers: if you are really itching to clone Monad, please do yourself and everybody else a favor, implement your clone in Perl or Python: a Monad-like shell becomes almost trivial in those languages because they have all the reflection capabilities you need, and because they already have all the hookups to Java, C#, and COM that you might want.
All of the new console makers are going to be losing mega cash for each console sold, so why would they make any incentive for anyone to buy their consoles and use them as computers? The manufacturers lose money on the console and lose any possible revenue from game sales.
That's a hypothesis, not a fact. Right now, it looks like the Xbox 360 and PS/3 will be rather expensive, probably expensive enough to cover the hardware.
Furthermore, both machines will be far more general-purpose computers than current game consoles, meaning many people will buy them without games.
Finally, if all else fails, companies do what they are already doing: they don't sell the naked console but only sell bundles. They continue that until prices come down.
I doubt many people are going to offer their home console systems for this purpose.
But given the relatively low cost and simple setup of these machines, labs could buy racks of them and use them as compute nodes. Perhaps Sony and Microsoft can view any small per-unit loss they may take on these machines as subsidizing research.
First of all, that point has nothing to do with the difference in licenses: open source licenses guarantee that you can continue to maintain the software, no matter what its original creator decides to do, a guarantee proprietary licenses don't give you.
Secondly, it is merely your belief that this is a problem. In practice, it doesn't seem to be a problem. Why? Because open source software packages with small user communities require little maintenance, so they are trivial to maintain, and open source software packages with big user communities have a large pool of potential contributors and maintainers to draw on.
Look at the majority of projects. Very few of them have a lot of outside contributors.
An open source license gives you the guarantee that you can continue to use, maintain, and alter software, no matter what the original author decides to do.
Whether the software is well-written, well-documented, or easy to maintain is a completely irrelevant point.
Most people consume the projects and don't go beyond compiling binaries if even that since most projects also provide compiled binaries.
It doesn't matter what "most people" do. What matters is whether there is the legal and practical guarantee that the software can get taken over by someone else if the original maintainers decide to change terms. Open source licenses make that guarantee, proprietary licenses don't.
I'm not spreading FUD.
Yes, you are, first by incorrectly stating that proprietary and open source licenses have similar risks, and secondly by making unsubstantiated claims about the relative quality of proprietary and open source software.
Well, it looks like Sun came out with something bootable and runnable. That's nice. Now, users and developers can determine which is the better systems. The next thing after getting it compiled and booting will be to get some unbiased benchmarks and see how much hardware it is compatible with.
Personally, I don't give Solaris much of a chance: I think it scratches itches that few people have. But, hey, in a year or two, we'll know.
There is some confusion here. They didn't "Change the terms". What they did was LOWER THE PRICE.
Well, that's your interpretation. The grandparent post obviously doesn't agree with you. I suggest you read it.
Its not unreasonable for Apple to charge money for WebObjects-- its one hell of a great solution, and is currently unmatched in the market place, free or proprietary. For what it does, its a total bargain.
If it were such a great solution, then Apple wouldn't have to keep lowering the price for it. I suspect people won't be using it even once it goes open source.
As it is, web development frameworks are a dime a dozen.
With an open source project, you know exactly what you are getting: the license, the quality of the source code, and the documentation. You are guaranteed by the license that you can continue to use, maintain, distribute, sublicense, and enhance that source code.
That is a guarantee proprietary licenses do not give you.
The quality of the project has nothing to do with the license; a poorly documented closed source project also has a high risk of evaporating. And with open source software, you can look at the source and avoid projects that are poorly written or unmaintainable, another advantage over closed source software.
You are at the same risk with open source projects where only have code contributions from company employees.
No, you are not at the same risk.
Copyright owners always have the right to change licence terms.
If it's under an open source license, they can't change the license terms retroactively; whatever new license they choose only apply to code they distribute after the change.
So, you and other users of the existing open source code can then continue to maintain the existing code as an open source project.
Also, as always, causality cannot be inferred from correlation.
And the author didn't; he merely stated a correlation.
Note also that for his purposes (predicting performance from measurements), a correlation is sufficient.
Finally, if bigger heads really implied greater intelligence, wouldn't you expect offensive linemen on professional football teams
The paper specifically talks about brain size, not head size; head size is only a rough predictor of brain size, in particular in subpopulations like that.
Note that there are known correlations between body size, brain size, and brain size and age. Presumably, people who worry about correlations between brain size and intelligence have taken those into account in their analyses.
Well, that's one of the biggest risks with proprietary software: the company changes licensing terms on you. Another big risk is that they change APIs or other parts of the software.
The solution? Contribute to an open source project and make it do what you want it to do. There are plenty of open source systems like WebObjects; help improve them.
unless the US throws its weight around and gets all other nations to do the same thing. Otherwise, you can simply use mail servers and web proxies in nations that don't have logging requirements.
Even with complete record keeping and logging, this will at best permit traffic analysis, since E-mail and IM will increasingly rely on cryptography.
This is basically a variation on forward error correction, which has already been used as part of P2P systems before.
This paper proposes a slightly different way of implementing FEC. Potentially, that might result in modest performance improvements compared to previous FEC methods. Unfortunately, the paper fails to measure and demonstrate any performance improvements relative to previous FEC P2P approaches, so we don't know.
Since Microsoft's technology is likely to be patented, it will not be adopted by open P2P systems. However, incorporating standard FEC methods into BitTorrent might be a good idea.
Of course, a much bigger area of improvement for content distribution would be he deployment of multicast technology across the Internet.
If you want something that's going to be high quality and last you a few years, you get yourself a macintel box.
If it's high quality you want, there are plenty of very high quality Intel-based laptops and desktops, in a much greater variety than you get from Apple.
Gnustep's been around for a decade now, and it's still BARELY usable... it's no surprise that Apple is coding circles around them.
Yes, GNUStep isn't very good and hasn't made a lot of progress. But GNUStep is based on the same technologies as OS X: a vector graphics server and Objective-C. What does that tell us?
It tells us that, given a choice, the GNUStep/Cocoa APIs are not popular with programmers (since most FOSS programmers prefer Gnome, KDE, and other toolkits), and it tells us that GNUStep/Cocoa programming is hard.
And that pretty much goes to disprove Apple's claims that OS X and Cocoa are a software revolution.
You know, nothing ever prevented anyone from writing Solaris drivers back when the OS was closed.
What's the point of writing open source drivers for a proprietary operating system? As long Solaris was closed source, it was Sun's responsibility to develop their own drivers.
Meanwhile, Linux kernel modules are seldom compatable (once compiled into a binary) across minor sub-version variants.
While I don't necessarily agree with it, that is by design rather than by accident.
GNU had a big hand in making Solaris a success: when Sun was still successful at universities and in research, everybody was installing GNU tools and X11 on Solaris.
Rather than information about the frequency of profanities in the source code, I'd like to know whether the Solaris release is reasonably complete and open now. Has anybody actually succeeded in downloading, compiling, and running it? What's the FSF's take on the license?
True, Windows has additional problems above and beyond its extensive use of C/C++. But every buffer overflow or related exploit in it is directly attributable to the use of C/C++.
Bad programming is bad programming. You can write vulnerable code in ANY language.
There are people who know about safety and security. They know that it's all about risk and probabilities.
And then there are people like you, people who believe erroneously that safety and security is a black-and-white issue.
Windows is badly designed and badly implemented.
Yes, and do you know what kind of people create those bad designs and implementations? It's people like you: people who simply do not understand safety and security.
Requiring the creation of XP N was clearly an ineffective remedy. The problem isn't the presence of Microsoft's media player, it's the absence of pre-installed alternatives.
An effective remedy might be to require Microsoft to permit PC manufacturers to customize Windows XP in whatever way they see fit without suffering any economic disadvantages. That includes making some other media player the default, pre-installing StarOffice, changing the shell, etc.
Right now, the ability of manufacturers to do so seems to be restricted contractually, economically, and technically.
Of course, XP N is at least a start because it demonstrates that it can be done.
Slashdot Mirror
I can guarantee if this was an Objective-C based shell from Apple people would be slobbering all over it by now, and saying how innovative Apple were
Yeah, but that wouldn't make it any better either.
Microsoft programmers should look up "second system effect": they keep making the same mistake again and again.
If you want to see some good (or at least interesting) directions people have taken shells into, there are Plan 9 rc (same idea as sh, but cleaned up), fish (better interactive features), and Tcl/Tk (shell-like programming for a full scripting language, including the ability to embed Java and C#/CLR objects). And if you want a full scripting language, Perl, Python, and Ruby fit the bill.
A note to FOSS programmers: if you are really itching to clone Monad, please do yourself and everybody else a favor, implement your clone in Perl or Python: a Monad-like shell becomes almost trivial in those languages because they have all the reflection capabilities you need, and because they already have all the hookups to Java, C#, and COM that you might want.
All of the new console makers are going to be losing mega cash for each console sold, so why would they make any incentive for anyone to buy their consoles and use them as computers? The manufacturers lose money on the console and lose any possible revenue from game sales.
That's a hypothesis, not a fact. Right now, it looks like the Xbox 360 and PS/3 will be rather expensive, probably expensive enough to cover the hardware.
Furthermore, both machines will be far more general-purpose computers than current game consoles, meaning many people will buy them without games.
Finally, if all else fails, companies do what they are already doing: they don't sell the naked console but only sell bundles. They continue that until prices come down.
It really isn't a problem.
I doubt many people are going to offer their home console systems for this purpose.
But given the relatively low cost and simple setup of these machines, labs could buy racks of them and use them as compute nodes. Perhaps Sony and Microsoft can view any small per-unit loss they may take on these machines as subsidizing research.
First of all, that point has nothing to do with the difference in licenses: open source licenses guarantee that you can continue to maintain the software, no matter what its original creator decides to do, a guarantee proprietary licenses don't give you.
Secondly, it is merely your belief that this is a problem. In practice, it doesn't seem to be a problem. Why? Because open source software packages with small user communities require little maintenance, so they are trivial to maintain, and open source software packages with big user communities have a large pool of potential contributors and maintainers to draw on.
Look at the majority of projects. Very few of them have a lot of outside contributors.
An open source license gives you the guarantee that you can continue to use, maintain, and alter software, no matter what the original author decides to do.
Whether the software is well-written, well-documented, or easy to maintain is a completely irrelevant point.
Most people consume the projects and don't go beyond compiling binaries if even that since most projects also provide compiled binaries.
It doesn't matter what "most people" do. What matters is whether there is the legal and practical guarantee that the software can get taken over by someone else if the original maintainers decide to change terms. Open source licenses make that guarantee, proprietary licenses don't.
I'm not spreading FUD.
Yes, you are, first by incorrectly stating that proprietary and open source licenses have similar risks, and secondly by making unsubstantiated claims about the relative quality of proprietary and open source software.
Well, it looks like Sun came out with something bootable and runnable. That's nice. Now, users and developers can determine which is the better systems. The next thing after getting it compiled and booting will be to get some unbiased benchmarks and see how much hardware it is compatible with.
Personally, I don't give Solaris much of a chance: I think it scratches itches that few people have. But, hey, in a year or two, we'll know.
There is some confusion here. They didn't "Change the terms". What they did was LOWER THE PRICE.
Well, that's your interpretation. The grandparent post obviously doesn't agree with you. I suggest you read it.
Its not unreasonable for Apple to charge money for WebObjects-- its one hell of a great solution, and is currently unmatched in the market place, free or proprietary. For what it does, its a total bargain.
If it were such a great solution, then Apple wouldn't have to keep lowering the price for it. I suspect people won't be using it even once it goes open source.
As it is, web development frameworks are a dime a dozen.
Stop spreading FUD about open source projects.
With an open source project, you know exactly what you are getting: the license, the quality of the source code, and the documentation. You are guaranteed by the license that you can continue to use, maintain, distribute, sublicense, and enhance that source code.
That is a guarantee proprietary licenses do not give you.
The quality of the project has nothing to do with the license; a poorly documented closed source project also has a high risk of evaporating. And with open source software, you can look at the source and avoid projects that are poorly written or unmaintainable, another advantage over closed source software.
You are at the same risk with open source projects where only have code contributions from company employees.
No, you are not at the same risk.
Copyright owners always have the right to change licence terms.
If it's under an open source license, they can't change the license terms retroactively; whatever new license they choose only apply to code they distribute after the change.
So, you and other users of the existing open source code can then continue to maintain the existing code as an open source project.
Actually, you can fly anywhere you want, including towards the sun.
Also, as always, causality cannot be inferred from correlation.
And the author didn't; he merely stated a correlation.
Note also that for his purposes (predicting performance from measurements), a correlation is sufficient.
Finally, if bigger heads really implied greater intelligence, wouldn't you expect offensive linemen on professional football teams
The paper specifically talks about brain size, not head size; head size is only a rough predictor of brain size, in particular in subpopulations like that.
Note that there are known correlations between body size, brain size, and brain size and age. Presumably, people who worry about correlations between brain size and intelligence have taken those into account in their analyses.
Well, that's one of the biggest risks with proprietary software: the company changes licensing terms on you. Another big risk is that they change APIs or other parts of the software.
The solution? Contribute to an open source project and make it do what you want it to do. There are plenty of open source systems like WebObjects; help improve them.
unless the US throws its weight around and gets all other nations to do the same thing. Otherwise, you can simply use mail servers and web proxies in nations that don't have logging requirements.
Even with complete record keeping and logging, this will at best permit traffic analysis, since E-mail and IM will increasingly rely on cryptography.
This is basically a variation on forward error correction, which has already been used as part of P2P systems before.
This paper proposes a slightly different way of implementing FEC. Potentially, that might result in modest performance improvements compared to previous FEC methods. Unfortunately, the paper fails to measure and demonstrate any performance improvements relative to previous FEC P2P approaches, so we don't know.
Since Microsoft's technology is likely to be patented, it will not be adopted by open P2P systems. However, incorporating standard FEC methods into BitTorrent might be a good idea.
Of course, a much bigger area of improvement for content distribution would be he deployment of multicast technology across the Internet.
If you want something that's going to be high quality and last you a few years, you get yourself a macintel box.
If it's high quality you want, there are plenty of very high quality Intel-based laptops and desktops, in a much greater variety than you get from Apple.
Gnustep's been around for a decade now, and it's still BARELY usable... it's no surprise that Apple is coding circles around them.
Yes, GNUStep isn't very good and hasn't made a lot of progress. But GNUStep is based on the same technologies as OS X: a vector graphics server and Objective-C. What does that tell us?
It tells us that, given a choice, the GNUStep/Cocoa APIs are not popular with programmers (since most FOSS programmers prefer Gnome, KDE, and other toolkits), and it tells us that GNUStep/Cocoa programming is hard.
And that pretty much goes to disprove Apple's claims that OS X and Cocoa are a software revolution.
Look at cinit on Freshmeat.
You will probably not see this in major Linux distributions because it would break most system administration tools and many packages.
You know, nothing ever prevented anyone from writing Solaris drivers back when the OS was closed.
What's the point of writing open source drivers for a proprietary operating system? As long Solaris was closed source, it was Sun's responsibility to develop their own drivers.
Meanwhile, Linux kernel modules are seldom compatable (once compiled into a binary) across minor sub-version variants.
While I don't necessarily agree with it, that is by design rather than by accident.
GNU had a big hand in making Solaris a success: when Sun was still successful at universities and in research, everybody was installing GNU tools and X11 on Solaris.
I think this "story" is the second or third infomercial for Prolexic. Do the Slashdot editors have some kind of personal stake in the company?
Rather than information about the frequency of profanities in the source code, I'd like to know whether the Solaris release is reasonably complete and open now. Has anybody actually succeeded in downloading, compiling, and running it? What's the FSF's take on the license?
True, Windows has additional problems above and beyond its extensive use of C/C++. But every buffer overflow or related exploit in it is directly attributable to the use of C/C++.
Bad programming is bad programming. You can write vulnerable code in ANY language.
There are people who know about safety and security. They know that it's all about risk and probabilities.
And then there are people like you, people who believe erroneously that safety and security is a black-and-white issue.
Windows is badly designed and badly implemented.
Yes, and do you know what kind of people create those bad designs and implementations? It's people like you: people who simply do not understand safety and security.
Thanks for illustrating the problem.
Requiring the creation of XP N was clearly an ineffective remedy. The problem isn't the presence of Microsoft's media player, it's the absence of pre-installed alternatives.
An effective remedy might be to require Microsoft to permit PC manufacturers to customize Windows XP in whatever way they see fit without suffering any economic disadvantages. That includes making some other media player the default, pre-installing StarOffice, changing the shell, etc.
Right now, the ability of manufacturers to do so seems to be restricted contractually, economically, and technically.
Of course, XP N is at least a start because it demonstrates that it can be done.