Yet Microsoft patent encumbered so many aspects of.NET very few people know what, if any, parts of the C#/.NET beast is not so encumbered,
What patents Microsoft may or may not have on.NET don't matter to OSS Mono developers because OSS developers using Mono generaly don't use.NET.
OSS Mono developers use ECMA C# plus existing open source libraries like Gtk+ that have been given C# interfaces. ECMA C# is clearly open, because of ECMA's submission requirements. Furthermore, Microsoft has stated that they consider ECMA C# open.
Also, issues of ownership aside, use of existing open source libraries and APIs as part of Mono means that it's far easier to switch from writing Gnome apps in C/C++ to writing Gnome apps in Mono than it is to switch to Java or.NET. And the resulting apps also integrate much better with the Gnome desktop than Java or.NET apps.
and it's certainly raised equivalent uncertainty to sun's ownership of the java platform
Sun's ownership of the Java platform isn't at all uncertain: they own the trademark, they own the only implementation of key parts of the specification, they own the specifications themselves, and they own several key patents. They argue that this ownership is a benefit because it lets them enforce cross-platform compatibility (and they have demonstrated that they have the legal muscle to do that), but whether it's a benefit or not, their ownership is clear.
Look at the most popular current languages: for "real" programming, we have C and C++
Do you have any data to back that up? I would guess that the largest number of programmers write in something like Basic (mostly VisualBasic), most cycles are spent on interpreted languages, and most LOC are probably still in COBOL.
You'd figure that if C and C++, with all their quirks, are so difficult to develop with, and time consuming, etc, that developers would jump on these new languages.
C and C++ aren't necessarily difficult to develop with, they are, however, difficult to develop with correctly. So, lots of C/C++ code gets written, but almost all of it crashes with regularity and has security problems.
Yes, but Sather, unfortunately is pretty much dead. So is another great language, Modula-3.
OCAML whomps all of the above on design and codability.
Not quite. I love O'CAML, but its syntax is too tricky for mainstream programmers and it lacks some important features (foremost, good support for efficient numerical programming).
Java is excusable because of GCJ,
Sun has complete control over what is and what isn't Java (they own the trademark, the specifications, and lots of patents). Gcj isn't Java, and if it were, it would probably violate some of Sun's intellectual property.
C# would be sheer madness.
Why? C# is an open, non-proprietary standard and a fairly decently designed language. Mono is an open source, high-quality implementation of C# with a full completement of open source libraries. Mono and its open source libraries are completely unencumbered by Microsoft or Sun patents, and they are based on APIs OSS developers already know well (Gtk+, Gnome, etc.). (Mono also happens to have a separate set of.NET-compatible libraries but if you are an OSS developer, you shouldn't use those.)
If you are looking for an open language with plenty of open source libraries, an efficient open source implementation, and no legal strings attached, C# is pretty much the only game in town right now.
failed to come even close to implementing the de-facto standard set by Eiffelstudio (no compatible thread implementation, no method pointers, incomplete library implementation)
failed to come even within an order of magnitude of equivalent C++ code in terms of performance
Furthermore, Eiffel is hardly an open language standard in the same sense as C, C++, or C#; the evolution of the Eiffel language has been driven by Meyer's whims, not by any kind of independent community or standards body. The language definition had some serious problems (requirement for global type checking, covariance, lack of method pointers, etc.), some of which remain. Eiffel could have been a winner, a worthy successor to Pascal and Modula-2, back when those were still fashionable, more than a decade ago before Java, but its proponents blew it big time, both technically and business-wise. Let's not beat a dead horse.
In my opinion, C# is, in every way, a better-designed language than Eiffel, C# has better open source implementations, better open source libraries, better C/C++ interfaces, and more widespread industry acceptance.
We don't try to hide this, but even the Free Software Foundation require that you assign/grant unlimited copyright to them on contributions. So I don't think it's unfair for us to ask the same thing.
Why do you drag philosophy into this? Why are you getting defensive? I just wanted to know what your policies are because that tells me how likely you are to succeed.
Also, a commercial version is a good thing for the community as well.
You say that as if it's an established fact. But many of the most successful open source projects are not dual-licensed. And many GPL-only projects have excellent commercial acceptance and commercial support.
Dual-licensed projects, on the other hand, raise concerns about their governance, since one party to the project, the commercial owners, may want to take the project in a different direction from the OSS developers, and the commercial developers are in a different position relative to the other contributors.
Yes, but [active OSS developer communities] don't come overnight.
In fact, often they don't come at all. That's why knowing about the current user community, history, commercial ties, and governance of a new project is important. Hence my questions.
There's also a commercial version, and commercial support available (this was the qualm that the reviewer had about Plone) at simian.ca. We also sell commercial add-ons (gotta eat too, right?;)).
Yes, but does it have a large, active open source developer community? The community site seems kind of dead. Where is the CVS site? Are OSS contributors required to license their changes for the corporate version?
Without an active OSS developer community, it matters fairly little what license it comes with.
You may mark this off-topic, but I strongly suspect that the moment I want to do something that Plone cannot, I am required to use Python (and/or Zope). [...] Now I'm all for learning new skills, but as I said, I just don't get it. What is so special about Python and why should I care?
Python is pretty similar to other scripting languages. It shouldn't take an experienced programmer any significant amount of time to learn enough Python to extend Plone (just like it shouldn't take an experienced programmer any significant amount of time to learn enough PHP to extend a PHP-based CMS).
OTOH, if you are so afraid of using Python that it keeps you from using Plone, then you perhaps shouldn't be writing any kind of web application code, in any language.
Most of my development these days is in PHP - the language seems elegant,
PHP is a practical, straightforward scripting language (I use it a lot myself), but I wouldn't exactly call it "elegant". Its scoping, parameter passing, and use of strings to represent functions seem pretty awkward and inelegant to me.
People keep saying that OSS games are not possible because people don't create high quality game content (levels, models, etc.) for free. Modding shows that they do. Now, the only thing that's missing is connecting OSS game engines with the effort that goes into creating free mods.
I doubt there are many outsorced devs who have seen the entrails of the Windows or Solaris kernels or the guts of DB2.
Well, first of all, as some other response to the parent shows, shops in China, India, and Russia are seeing the guts of those systems.
Second, as I was saying, any code those people contribute can be used to plant a Trojan horse, it doesn't have to be "core dev".
That stuff is too valuable and sensitive to be managed that way.
What way? Russia, China, and India have some of the smartest developers in the world. And, of course, they develop code that goes into operating system kernels and databases. They wouldn't even need access to the source code--drivers, plug-ins, and blades are often developed using only public APIs and they are still shipped with those systems. Of course, it's not like Solaris or Windows source code is a secret.
I doubt Trojan horses are much of an issue in embedded systems: since embedded systems don't generally have external Internet access, it would be hard to trigger a Trojan horse in an embedded system, so any failures it would introduce would have to show up randomly and not just in response to a trigger.
Furthermore, for embedded code to try and infer what kind of system it's running on (military/non-military, essential/non-essential, deployed/non-deployed) and only fail in the essential, deployed, military systems is essentially impossible with the kind of minimalist code that could be hidden in an open source project and not noticed.
That means that if anybody planted a Trojan horse in OSS that was of any military significance, it would show up during testing as random failures, and that is just taken care of by normal testing procedures.
Note that the same argument doesn't work for closed source: something like a Green Hills embedded kernel could easily ship with a huge Trojan horse that looks for specific strings in system output/logs ("military", "target", "live munitions", "vehicle speed", whatever the military lingo is) and/or looks for specific sensor types, output devices, and/or communications channels and only triggers under specific circumstances likely to represent actual combat situations. While such attempts to identify combat situations would be blatantly obvious in 100% open source software and be noticed right away, they could easily be hidden in any big binary component of any closed source system.
I wouldn't trust it yet as an OS for our warships or other vehicles,
I would trust it more in that application than Windows or even Green Hills.
Free markets are great, but in this case the military has to perform a more core mission: defend the US from attack. If that means violating free market principles by pouring taxpayer dollars into a free OS for public use, then they should and most likely will do it eventually.
What makes you think that is not part of the free market? When the military invests money in the development of Linux, it's because they decided that it's cheaper to get the software that way than to keep paying licensing fees to Microsoft or Green Hills. That is very much a free market decision.
Just because something is GPL'ed doesn't place it outside the free market. The choice of "free software" is a free market choice like any other.
Would you like to provide some proof that said companies outsource core dev to said countries?
Don't get hung up on the term "core dev". Those companies are paying Chinese, Russian, and Indian developers to develop software that ships with their OSes and applications, and just about any piece of software that gets shipped could be used to put in a Trojan horse: device drivers, compilers, optimizers, code generators, installers, help systems, database code, network servers, CGI scripts, etc.
Wireless security is broken beyond repair, and incremental attempts to fix it, like LEAP, just aren't working.
I think we should just treat all networking transports (wired, wireless) as inherently insecure and implement security separately with systems like IPsec, ssh, and SSL.
Then, we won't have to upgrade our hardware every time another flaw surfaces. Or is that perhaps the plan, actually?
How would you put a password protection on this? Would every hearing person have to register a spoken password to be able to call a deaf person?
No. Every hearing person already is authenticated to the phone system, either because they are using a land line or because they are using a cell phone. So, if you dial into the TTY service, you wouldn't have to authenticate. The TTY service should, however, pass on your Caller-ID when you make it available or when calling 1-800 numbers (as it is done for regular calls).
The suggestion is that people trying to use the system through the Internet would have to use a password. That's, again, no different from when you or I use Internet VoIP services: hearing users have to do the same thing. It's an anomaly that Internet access to these services doesn't require that, and something that threatens the services.
Almost all hosting services offer app server capabilities, such as PHP+Mysql combinations. These do need resources.
PHP and MySQL running on a virtual server can be configured to use very little resources for each additional user. And even if they were expensive, a PHP+MySQL server that is hardly being used will still hardly put a load on a machine.
No. A response to customer demand in an expanding high-end server market.
You think company execs wake up and say "hey, I'll ask Sun for a partitionable mainframe"? That demand is generated by promises of easier maintainability and lower costs. It appeals to the mainframe and centralization mentality of many organizations.
Also, how do you think those "massively multiprocessing Unix mainframes" are implemented? They are increasingly just expensively packaged, expensively networked collections of individual machines.
You are confusing web servers with app servers.
It was you who talked about web servers being run on virtual hosts; I just responded to it.
Makes me wonder if a nationalization of this sales tax deal will end up dinging the bottom line of online retailers.
Well, and presumably it would increase the bottom line of your local retailers.
Furthermore, at least in theory, if the government gets more out-of-state sales tax revenue and the revenue is significant, they can lower sales taxes overall, or at least delay increasing them, which also helps all retailers.
Most web servers are the exact opposite of distributed - they run on virtual hosts on a single machine.
That's because most web servers don't even come close to needing the resources of even a single low-end machine. But that isn't Sun's business.
There is no evidence for this. True distributed database are very hard to implement and very expensive to buy.
I don't know what you mean by "true" distributed databases; if you mean fully transparent, efficient support of all SQL statements as if it ran on a local machine, that will probably never happen. But that isn't necessary in the real world. Distributed database architectures are already appearing on open source platforms, they have restrictions, but they get the job done.
Where clustering is implemented, its usually between a few machines, not a huge network of small servers.
You don't need clustering technology to build large, distributed web farms--people usually do that sort of thing at the application level. Clustering technologies are a convenience solution.
The big new thing in the enterprise industry is partitioning - providing very vast and dynamic virtual machines on massively multiprocessing Unix mainframes.
Yes, a last-gasp effort by big iron vendors to stem the tide.
SharePoint is is $5619 in retail pricing, you can no doubt get it cheaper from the partners. If your rate for this organization is $56 per hour ask yourself whether you can develop a similar functionality within a 100 hour project. If not, get a Sharepoint license, you're hired to save money with software, not push some petty philosophies.
Did you read anything I wrote? This isn't about the purchase price or "petty philosophies". The initial licensing costs are irrelevant, as are the licensing cost saving you get from open source. What matters is the business risk you accept when you depend on Sharepoint: you have no control over what directions Microsoft takes that product into and if they decide to screw you, you have no substitute.
If writing, testing, debugging and implementing an open-source solution is going to cover 2 years of Sharepoint license, then yeah, I am all for it. But if after two years of developing and debugging you still get a half-assed solution capable of, as some people suggested, "providing input in an HTML form", then who cares whether it's open-source or closed-source if it's not usable?
You don't need to spend 2 years of your own time to write open source alternatives to Sharepoint--they already exist. And even if they didn't exist, you could get together with other people and share the effort.
The open source solutions may or may not be as easy to deploy as Sharepoint and they may or may not work quite as well, but they are probably good enough, and they have none of the risk associated with choosing a proprietary solution. And that's why it is probably a better business decision to pick the open source solution. It has nothing to do with "philosophy".
Closed source products are risky. Here are some of the risks:
Microsoft discontinues the product.
Microsoft greatly increasees the price from one year to the next.
Microsoft makes it increasingly hard to get your data out and migrate to another product, either because you don't like to pay anymore or because Sharepoint doesn't satisfy your needs anymore.
Yes, implementing an OSS solution is almost certainly costlier and more work in the short run. But it is also almost certainly cheaper and less risky in the long run.
You can see the attitude Schwartz has towards open source in this quote:
Schwartz: Everyone in the marketplace seems to believe that if you build a bucket of parts then you can deliver it and if it has a user interface it is a desktop. We have spent hundreds of man-years building an integrated desktop which, if you saw the demo, it's beautiful, it's gorgeous, and that took a huge amount of work. The other guys [he must be referring to Gnome, KDE, RedHat, SuSE, etc.] are just kind of assembling open-source crap and saying, "Hey, we're done."
Here's another one:
Sun does not "believe that Linux plays a role on the server. Period," said Schwartz, also in Santa Clara. "If you want to buy it, we will sell it to you. But we believe that Solaris is a better alternative that is safer, more robust, higher quality and dramatically less expensive in purchase price."
Note that there is also a big difference whether you ship your own proprietary components or someone else's.
SuSE probably would rather have Java, RealPlayer and MPEG be open source and free.
However, when Sun ships Java on top of Linux, then Sun has an interest in the proprietary software they ship with Linux. That's an entirely different situation.
(SuSE used to be in the same position with YaST, and I think people are happy that they changed.)
disk I/O, multi proc sclability, OS hardening (Trusted Solaris)
100 PCs have a lot more aggregate disk I/O and "multi-proc sclability" than a similarly priced Sun Enterprise server. They are also a lot more robust because they don't all go down at once.
During the Internet bubble, companies were buying Sun's big boxes because a single big box is a little easier to install initially--companies were flush with cash and short on staff. Now, they are still buying some of them on inertia and because moving to some other platform costs them.
But companies are waking up. In another couple of years, most databases are going to be distributed databases running on networks of PCs, just like web servers and middle ware already are. Sun's server business is going to implode.
They just work. All the time.
Everybody claims that about their favorite platform. Fact is: none of them "just work". They all develop hardware problems, they all have bugs, etc.
Slashdot Mirror
Yet Microsoft patent encumbered so many aspects of .NET very few people know what, if any, parts of the C#/.NET beast is not so encumbered,
.NET don't matter to OSS Mono developers because OSS developers using Mono generaly don't use .NET.
.NET. And the resulting apps also integrate much better with the Gnome desktop than Java or .NET apps.
What patents Microsoft may or may not have on
OSS Mono developers use ECMA C# plus existing open source libraries like Gtk+ that have been given C# interfaces. ECMA C# is clearly open, because of ECMA's submission requirements. Furthermore, Microsoft has stated that they consider ECMA C# open.
Also, issues of ownership aside, use of existing open source libraries and APIs as part of Mono means that it's far easier to switch from writing Gnome apps in C/C++ to writing Gnome apps in Mono than it is to switch to Java or
and it's certainly raised equivalent uncertainty to sun's ownership of the java platform
Sun's ownership of the Java platform isn't at all uncertain: they own the trademark, they own the only implementation of key parts of the specification, they own the specifications themselves, and they own several key patents. They argue that this ownership is a benefit because it lets them enforce cross-platform compatibility (and they have demonstrated that they have the legal muscle to do that), but whether it's a benefit or not, their ownership is clear.
Look at the most popular current languages: for "real" programming, we have C and C++
Do you have any data to back that up? I would guess that the largest number of programmers write in something like Basic (mostly VisualBasic), most cycles are spent on interpreted languages, and most LOC are probably still in COBOL.
You'd figure that if C and C++, with all their quirks, are so difficult to develop with, and time consuming, etc, that developers would jump on these new languages.
C and C++ aren't necessarily difficult to develop with, they are, however, difficult to develop with correctly. So, lots of C/C++ code gets written, but almost all of it crashes with regularity and has security problems.
Sather whomps Eiffel on design and openness.
.NET-compatible libraries but if you are an OSS developer, you shouldn't use those.)
Yes, but Sather, unfortunately is pretty much dead. So is another great language, Modula-3.
OCAML whomps all of the above on design and codability.
Not quite. I love O'CAML, but its syntax is too tricky for mainstream programmers and it lacks some important features (foremost, good support for efficient numerical programming).
Java is excusable because of GCJ,
Sun has complete control over what is and what isn't Java (they own the trademark, the specifications, and lots of patents). Gcj isn't Java, and if it were, it would probably violate some of Sun's intellectual property.
C# would be sheer madness.
Why? C# is an open, non-proprietary standard and a fairly decently designed language. Mono is an open source, high-quality implementation of C# with a full completement of open source libraries. Mono and its open source libraries are completely unencumbered by Microsoft or Sun patents, and they are based on APIs OSS developers already know well (Gtk+, Gnome, etc.). (Mono also happens to have a separate set of
If you are looking for an open language with plenty of open source libraries, an efficient open source implementation, and no legal strings attached, C# is pretty much the only game in town right now.
Furthermore, Eiffel is hardly an open language standard in the same sense as C, C++, or C#; the evolution of the Eiffel language has been driven by Meyer's whims, not by any kind of independent community or standards body. The language definition had some serious problems (requirement for global type checking, covariance, lack of method pointers, etc.), some of which remain. Eiffel could have been a winner, a worthy successor to Pascal and Modula-2, back when those were still fashionable, more than a decade ago before Java, but its proponents blew it big time, both technically and business-wise. Let's not beat a dead horse.
In my opinion, C# is, in every way, a better-designed language than Eiffel, C# has better open source implementations, better open source libraries, better C/C++ interfaces, and more widespread industry acceptance.
We don't try to hide this, but even the Free Software Foundation require that you assign/grant unlimited copyright to them on contributions. So I don't think it's unfair for us to ask the same thing.
Why do you drag philosophy into this? Why are you getting defensive? I just wanted to know what your policies are because that tells me how likely you are to succeed.
Also, a commercial version is a good thing for the community as well.
You say that as if it's an established fact. But many of the most successful open source projects are not dual-licensed. And many GPL-only projects have excellent commercial acceptance and commercial support.
Dual-licensed projects, on the other hand, raise concerns about their governance, since one party to the project, the commercial owners, may want to take the project in a different direction from the OSS developers, and the commercial developers are in a different position relative to the other contributors.
Yes, but [active OSS developer communities] don't come overnight.
In fact, often they don't come at all. That's why knowing about the current user community, history, commercial ties, and governance of a new project is important. Hence my questions.
There's also a commercial version, and commercial support available (this was the qualm that the reviewer had about Plone) at simian.ca. We also sell commercial add-ons (gotta eat too, right? ;)).
Yes, but does it have a large, active open source developer community? The community site seems kind of dead. Where is the CVS site? Are OSS contributors required to license their changes for the corporate version?
Without an active OSS developer community, it matters fairly little what license it comes with.
You may mark this off-topic, but I strongly suspect that the moment I want to do something that Plone cannot, I am required to use Python (and/or Zope). [...] Now I'm all for learning new skills, but as I said, I just don't get it. What is so special about Python and why should I care?
Python is pretty similar to other scripting languages. It shouldn't take an experienced programmer any significant amount of time to learn enough Python to extend Plone (just like it shouldn't take an experienced programmer any significant amount of time to learn enough PHP to extend a PHP-based CMS).
OTOH, if you are so afraid of using Python that it keeps you from using Plone, then you perhaps shouldn't be writing any kind of web application code, in any language.
Most of my development these days is in PHP - the language seems elegant,
PHP is a practical, straightforward scripting language (I use it a lot myself), but I wouldn't exactly call it "elegant". Its scoping, parameter passing, and use of strings to represent functions seem pretty awkward and inelegant to me.
Note that Typo3's WYSIWYG editor only works with IE. I don't think any of the others have WYSIWYG browser-based editing.
People keep saying that OSS games are not possible because people don't create high quality game content (levels, models, etc.) for free. Modding shows that they do. Now, the only thing that's missing is connecting OSS game engines with the effort that goes into creating free mods.
I doubt there are many outsorced devs who have seen the entrails of the Windows or Solaris kernels or the guts of DB2.
Well, first of all, as some other response to the parent shows, shops in China, India, and Russia are seeing the guts of those systems.
Second, as I was saying, any code those people contribute can be used to plant a Trojan horse, it doesn't have to be "core dev".
That stuff is too valuable and sensitive to be managed that way.
What way? Russia, China, and India have some of the smartest developers in the world. And, of course, they develop code that goes into operating system kernels and databases. They wouldn't even need access to the source code--drivers, plug-ins, and blades are often developed using only public APIs and they are still shipped with those systems. Of course, it's not like Solaris or Windows source code is a secret.
I doubt Trojan horses are much of an issue in embedded systems: since embedded systems don't generally have external Internet access, it would be hard to trigger a Trojan horse in an embedded system, so any failures it would introduce would have to show up randomly and not just in response to a trigger.
Furthermore, for embedded code to try and infer what kind of system it's running on (military/non-military, essential/non-essential, deployed/non-deployed) and only fail in the essential, deployed, military systems is essentially impossible with the kind of minimalist code that could be hidden in an open source project and not noticed.
That means that if anybody planted a Trojan horse in OSS that was of any military significance, it would show up during testing as random failures, and that is just taken care of by normal testing procedures.
Note that the same argument doesn't work for closed source: something like a Green Hills embedded kernel could easily ship with a huge Trojan horse that looks for specific strings in system output/logs ("military", "target", "live munitions", "vehicle speed", whatever the military lingo is) and/or looks for specific sensor types, output devices, and/or communications channels and only triggers under specific circumstances likely to represent actual combat situations. While such attempts to identify combat situations would be blatantly obvious in 100% open source software and be noticed right away, they could easily be hidden in any big binary component of any closed source system.
I wouldn't trust it yet as an OS for our warships or other vehicles,
I would trust it more in that application than Windows or even Green Hills.
Free markets are great, but in this case the military has to perform a more core mission: defend the US from attack. If that means violating free market principles by pouring taxpayer dollars into a free OS for public use, then they should and most likely will do it eventually.
What makes you think that is not part of the free market? When the military invests money in the development of Linux, it's because they decided that it's cheaper to get the software that way than to keep paying licensing fees to Microsoft or Green Hills. That is very much a free market decision.
Just because something is GPL'ed doesn't place it outside the free market. The choice of "free software" is a free market choice like any other.
Would you like to provide some proof that said companies outsource core dev to said countries?
Don't get hung up on the term "core dev". Those companies are paying Chinese, Russian, and Indian developers to develop software that ships with their OSes and applications, and just about any piece of software that gets shipped could be used to put in a Trojan horse: device drivers, compilers, optimizers, code generators, installers, help systems, database code, network servers, CGI scripts, etc.
Wireless security is broken beyond repair, and incremental attempts to fix it, like LEAP, just aren't working.
I think we should just treat all networking transports (wired, wireless) as inherently insecure and implement security separately with systems like IPsec, ssh, and SSL.
Then, we won't have to upgrade our hardware every time another flaw surfaces. Or is that perhaps the plan, actually?
How would you put a password protection on this? Would every hearing person have to register a spoken password to be able to call a deaf person?
No. Every hearing person already is authenticated to the phone system, either because they are using a land line or because they are using a cell phone. So, if you dial into the TTY service, you wouldn't have to authenticate. The TTY service should, however, pass on your Caller-ID when you make it available or when calling 1-800 numbers (as it is done for regular calls).
The suggestion is that people trying to use the system through the Internet would have to use a password. That's, again, no different from when you or I use Internet VoIP services: hearing users have to do the same thing. It's an anomaly that Internet access to these services doesn't require that, and something that threatens the services.
Almost all hosting services offer app server capabilities, such as PHP+Mysql combinations. These do need resources.
PHP and MySQL running on a virtual server can be configured to use very little resources for each additional user. And even if they were expensive, a PHP+MySQL server that is hardly being used will still hardly put a load on a machine.
No. A response to customer demand in an expanding high-end server market.
You think company execs wake up and say "hey, I'll ask Sun for a partitionable mainframe"? That demand is generated by promises of easier maintainability and lower costs. It appeals to the mainframe and centralization mentality of many organizations.
Also, how do you think those "massively multiprocessing Unix mainframes" are implemented? They are increasingly just expensively packaged, expensively networked collections of individual machines.
You are confusing web servers with app servers.
It was you who talked about web servers being run on virtual hosts; I just responded to it.
Makes me wonder if a nationalization of this sales tax deal will end up dinging the bottom line of online retailers.
Well, and presumably it would increase the bottom line of your local retailers.
Furthermore, at least in theory, if the government gets more out-of-state sales tax revenue and the revenue is significant, they can lower sales taxes overall, or at least delay increasing them, which also helps all retailers.
Most web servers are the exact opposite of distributed - they run on virtual hosts on a single machine.
That's because most web servers don't even come close to needing the resources of even a single low-end machine. But that isn't Sun's business.
There is no evidence for this. True distributed database are very hard to implement and very expensive to buy.
I don't know what you mean by "true" distributed databases; if you mean fully transparent, efficient support of all SQL statements as if it ran on a local machine, that will probably never happen. But that isn't necessary in the real world. Distributed database architectures are already appearing on open source platforms, they have restrictions, but they get the job done.
Where clustering is implemented, its usually between a few machines, not a huge network of small servers.
You don't need clustering technology to build large, distributed web farms--people usually do that sort of thing at the application level. Clustering technologies are a convenience solution.
The big new thing in the enterprise industry is partitioning - providing very vast and dynamic virtual machines on massively multiprocessing Unix mainframes.
Yes, a last-gasp effort by big iron vendors to stem the tide.
SharePoint is is $5619 in retail pricing, you can no doubt get it cheaper from the partners. If your rate for this organization is $56 per hour ask yourself whether you can develop a similar functionality within a 100 hour project. If not, get a Sharepoint license, you're hired to save money with software, not push some petty philosophies.
Did you read anything I wrote? This isn't about the purchase price or "petty philosophies". The initial licensing costs are irrelevant, as are the licensing cost saving you get from open source. What matters is the business risk you accept when you depend on Sharepoint: you have no control over what directions Microsoft takes that product into and if they decide to screw you, you have no substitute.
If writing, testing, debugging and implementing an open-source solution is going to cover 2 years of Sharepoint license, then yeah, I am all for it. But if after two years of developing and debugging you still get a half-assed solution capable of, as some people suggested, "providing input in an HTML form", then who cares whether it's open-source or closed-source if it's not usable?
You don't need to spend 2 years of your own time to write open source alternatives to Sharepoint--they already exist. And even if they didn't exist, you could get together with other people and share the effort.
The open source solutions may or may not be as easy to deploy as Sharepoint and they may or may not work quite as well, but they are probably good enough, and they have none of the risk associated with choosing a proprietary solution. And that's why it is probably a better business decision to pick the open source solution. It has nothing to do with "philosophy".
Yes, implementing an OSS solution is almost certainly costlier and more work in the short run. But it is also almost certainly cheaper and less risky in the long run.
Here's another one:
Just like their commercial competitors...
Why bother? Sun hasn't demonstrated that SPARC is a better architecture in practice than modern x86 implementations.
Note that there is also a big difference whether you ship your own proprietary components or someone else's.
SuSE probably would rather have Java, RealPlayer and MPEG be open source and free.
However, when Sun ships Java on top of Linux, then Sun has an interest in the proprietary software they ship with Linux. That's an entirely different situation.
(SuSE used to be in the same position with YaST, and I think people are happy that they changed.)
disk I/O, multi proc sclability, OS hardening (Trusted Solaris)
100 PCs have a lot more aggregate disk I/O and "multi-proc sclability" than a similarly priced Sun Enterprise server. They are also a lot more robust because they don't all go down at once.
During the Internet bubble, companies were buying Sun's big boxes because a single big box is a little easier to install initially--companies were flush with cash and short on staff. Now, they are still buying some of them on inertia and because moving to some other platform costs them.
But companies are waking up. In another couple of years, most databases are going to be distributed databases running on networks of PCs, just like web servers and middle ware already are. Sun's server business is going to implode.
They just work. All the time.
Everybody claims that about their favorite platform. Fact is: none of them "just work". They all develop hardware problems, they all have bugs, etc.