Well, that's fine as a general ideal to work towards, but compromises will always have to be made in an organization that isn't entirely composed of IT people.
Quite to the contrary: organizations composed primarily of non-IT people are the ones that most appreciate machines that "just work". You run into problems when every workgroup gets its own little IT "expert". Of course, if you run Windows, every workgroup needs its own little IT "expert" because machines constantly screw up, lock up, freeze, and do other weird things.
Hell, just adding a few Linux developers to the mix is enough to screw up any tightly controlled management scheme.
Huh? Why would professional Linux developers screw up management? In fact, UNIX developers, just like other users, traditionally also appreciate not having to bother with system management, and on UNIX machines, they don't have to. Again, it's only on Windows where every developer needs to become a system manager to make sure their machines have just the right combinations of tools, patches, IDEs, libraries, etc., and get reinstalled every few weeks.
That only works if the workstations are tightly controlled, secured and integrated into the server environment
Yes, the way a well-run IT department should operate. Microsoft shops have been trying to achieve that sort of operation for years, largely unsuccessfully and at enormous cost.
In a real-world organization with large numbers of loosely-coupled desktops and laptops, such a scheme is really painful to maintain.
Yes, many real-world organizations are incompetently run. In fact, many real-world organizations are incompetently run because their IT managers simply don't know anything other than Microsoft. And your point is what? That because many people don't know how to run an efficient IT infrastructure, everybody else should screw up in the same way?
And probably very insecure. At least SMB doesn't put too much trust in the client.
NFS's traditional security model was justified on traditional hardware and network setups, and it still works well in many environments. However, current versions of NFS do, in fact, support other security models as well, so you get your pick.
Well, the argument is obviously bogus. However, I think it's probably a good thing for free software if people who don't understand the GPL don't use GPL'ed code. Otherwise, we are going to get more groundless lawsuits like the one from SCO, and that is going to do a lot more harm than if some clueless C?O buys another few copies of Microsfot Office.
It seems that SCO are saying that the issue is not actually about copyrighted code being in Linux at all. The issue is about IBM putting it there in contravention of their contract to "keep it secret, keep it safe".
The way IBM released that code was over years, and each release was usually preceded by months of pre-announcements of what was going to happen. SCO clearly knew about it and if SCO had found any of that objectionable, they could have complained.
Simply put, if SCO-Caldera can prove that IBM-developed AIX code... are derivate works and therefore part of the Unix Software Product and that IBM disclosed the code, methods, secrets and for them to the Linux developers, then SCO wins its IBM lawsuit.
Well, that's for IBM to worry about; it is of no relevance or consequence to Linux users.
As for IBM, it is inconceivable that IBM would have signed a contract that would let SCO win such a lawsuit.
The complaints that the GPL is "viral" would be fair if the consequences went beyond that: if, say, the result of this was that the whole of SCO Unix, not just that part in Linux, suddenly has to be GPL'd. This is not the case, as no part of SCO Unix has been copyrighted by an entity other than SCO or one that's licenced the code to SCO under the GPL.
Of course, if it turns out that the reason why there is (if there is) identical code in SCO UNIX and Linux is because SCO copied it from Linux, we may yet end up with SCO UNIX under the GPL, horrid as that may seem...
If the copyright holder did not Know they had code in Linux, they should not be obligated to have that code be considered GPLed because they distribute it.
While I might agree with that in some cases, here I think that argument doesn't apply.
The Linux kernel source wasn't just some piece of code that randomly found its way onto an SCO distribution medium. SCO was a kernel developer and contributor, so they were working with the code in question and they knew of its capabilities and that there might be a possibility that it violated their copyright.
If SCO was concerned about copyright violations vis-a-vis their own code base, it would have taken only a few minutes for them to check before redistributing the code. SCO was competent, knowledgeable, and the test was cheap and easy to do; the presumption should be that they did whatever they intended to do, and if they didn't complain at the time it was because they either didn't care or didn't exercise due dilligence.
And if they can convince a judge and jury that they have derivative rights to the AIX code base copyrighted by IBM, either by contract or by copyright, then the contribution of that code base to the Linux kernel is a violation of either the contract or the copyright on System V.
Well, excuse me, but there is a huge difference between "the contract" and "the copyright".
If IBM violated a contract with SCO, that's IBM's problem and IBM would have to pay the bill for that. If you have ever dealt with IBM's lawyers, you'd know that it is essentially an impossibility that IBM would have agreed to any contract that would open them up to such claims. But, whatever, IBM's contractual problems with SCO don't concern anybody other than IBM.
SCO only has copyright and patent laws to make claims against people it doesn't have contracts with. If those hypothetical "derivative rights" are based in copyright law, they don't cover "gaining experience from" or any other such vague constructions.
That is the strategy, it seems, and its not something that anyone should be scoffing at, becuase it just might be enough to win.
Well, bribing the judge might also be enough to win. However, as long as we discuss legal issues rationally, terminal stupidity, incompetence, or bribery are not things that it makes a lot of sense to spend a lot of time arguing about.
Why the sudden maintenance of SCO's secrecy, when there's an industry-wide history of violating similar NDAs at the first opportunity?
The most obvious explanation is: there simply is no infringing code and SCO made it all up.
If there is identical code at all, it was/is probably copied from public sources into both Linux and SCO UNIX, or it was copied into SCO UNIX from Linux. We may end up being able to force SCO to release all of SCO UNIX under the GPL (blech).
Browsing and ACLs were popularized by Novell long before MS added them.
Novell was part of the first wave of Microsoft's bottom-up invasion of business, so that is my point.
And Unix was late to get these features because general fileserver applications were never a salespoint for Sun and the other Unix vendors.
You've got to be kidding. "General file server applications" have been such a natural, integral, and unobtrusive part of UNIX systems for so long that people like you seem to miss the fact that they are even there. Since almost the day UNIX workstations got networking hardware, the general setup of a UNIX network is to have central file servers serve home directories, most system software, and shared data directories, in a single unified namespace. Most people don't even ever notice that there exists things like file servers, it just all works seamlessly. And adding a new machine requires little more than plugging it into the network.
What Microsoft offers today in terms of file systems is still cumbersome compared to the services UNIX workstations have had for nearly two decades.
Kaffe is the open source one that isn't based on Sun code. I suspect that there are a few clean-room embedded VMs out there too, but I can't prove it.
Kaffe is not an implementation of the Java platform: it lacks numerous APIs and it is clearly not compliant with Sun's Java specification.
Technically, Kaffe is also far behind Mono, and Kaffe and gcj lack the user communities that Mono has. What makes Mono so successful is that, unlike Kaffe or gcj, Mono code can very easily access native libraries. Mono doesn't try to be primarily cross-platform or WORA, it tries to be a better system for Linux programming than C/C++, and it is succeeding admirably at that. Even if Sun Java weren't proprietary, it doesn't compete with that.
Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.
All of those implementations are based on code licensed from Sun, so all of them are under Sun's control and none of them are open source.
You are right that they are widely used, but this is not a good thing for Linux because it means that anybody that relies on that software is subject to Sun's whims and problems. Sun could decide to charge for Java licenses at any time, and we have to assume that they could force BEA and IBM to do the same thing. Of, some company hostile to Java and cross-platform software could acquire Sun and kill Java altogether.
I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.
The more the merrier, but I don't view Perl 6, a dynamically typed runtime, as being in the same league as Java or Mono.
And which of those is a browsable file sharing protocol? WebDAV?!? you can't be serious... [...] Sounds like they actually needed [wanted anyways] a file server that gave them ACL based permissions.
Browsable file sharing and ACLs are misfeatures that come out of Microsoft's bottom-up invasion of the enterprise. They make managing large installations a headache: you really don't want people setting up little servers everywhere and setting up weird and unmanageable permissions for their files. It really is no accident that UNIX has been slow in getting support for either feature even though UNIX has been used at sites with thousands of machines since before Windows NT even existed.
Having said that, Linux supports both of them, and, by definition, the way Linux supports those features is open (i.e., open source and hence open protocol). So, you can replace Microsoft's proprietary servers with open Linux servers, and you can even support those misfeatures if you like (and even serve Windows clients for the occasional Windows client software that doesn't yet have good Linux equivalents).
No, it's not. I have administered machines for organizations of that size, and trust me, UNIX-based systems are far less work. The fewer Windows servers and clients you have, the easier your workload will get.
Even if I could afford to throw it all out, I have to think about what I'd use to replace things like Blackbaud (school admin software - non-profits),
Why would you replace it? You could still run a few Windows boxes with oddball software like that.
MS ISA with Surfcontrol,
Surfcontrol runs on Linux.
how to roll out public use Linux boxen with home directories.
There's nothing to "roll out"--on a well-run network, you just plug them in, set them up to boot over the network, and you are done.
Of course, if you don't know anything about Linux, then all of that is hard. But the fact that you don't know Linux doesn't make Microsoft a better or cheaper solution; it's just that your organization pays a premium for their software and support in order to accomodate your limited skill set.
Yes, of course Java is proprietary. As you may notice, I didn't list it as one of the open alternatives to.NET. In fact, I recommend you don't use Java for open source software development precisely because it is proprietary.
Re:Nice to see the sideswipe at .NET (not)
on
Nat Demos Dashboard
·
· Score: 2, Insightful
First, have they just said they would let the public use it, or have they actually licensed the patent for public use?
They have done the same thing Sun has done with its numerous Java patents: they have stated that open source projects can use it. Can they go back on their word? Probably, just like Sun can. The real test will be for Mono to try to get something in writing from Microsoft permitting them to implement the.NET APIs. But it doesn't make much sense to do that before the patent has actually issued.
I doubt you have reviewed all of Microsoft's current patent holdings, so what are you basing your opinion on?
Patent "holdings" are public. I have looked through Microsoft's patents and patent applications, as have many other people; they are available at the USPTO site. Nobody has yet identified any problems.
I fail to see how you can claim there's nothing to worry about with.NET.
I didn't make any such claim. There are some minor concerns surrounding patent issues and.NET, not as serious as those surrounding Java, but you can legitimately worry about them if you like.
What you keep doing, however, is confusing.NET with Mono and C#. Even if.NET were completely off-limits to open source implementations, Mono would still be a thriving and useful project and a great platform for writing Linux applications because most of the APIs people use for writing Linux applications are not based on.NET.
and found it wanting. A key problem area was interacting with the corporate Windows network.
Well, actually the real problem is that Windows server software is wanting: it fails to conform to standard protocols and formats. If Windows server software was built from the ground up around IMAP, XML, HTML, HTTP, WebDAV, and other such protocols, then Linux desktops and Mac desktops would work well with it. While Windows currently nominally supports many of those protocols and formats, they are second class compared to Microsoft's proprietary protocols.
What's the solution? Get rid of the Windows servers. That also lowers licensing, administrative, and maintenance costs. And Windows clients can talk fairly well to Linux servers running open source software.
Re:Nice to see the sideswipe at .NET (not)
on
Nat Demos Dashboard
·
· Score: 1
I have one word for you: Patents.
Microsoft has applied for one patent on the.NET APIs and they have stated publicly that they will let open source implementations use it.
Mono, however, is not primarily an implementation of the.NET APIs, it's a C# compiler and runtime, as well as a large set of non-.NET APIs. Even if Mono had to remove all the.NET APIs covered by the potential patent, it would still be a great platform.
Also, I'd suggest you check the USPTO web site for Sun patents related to Java; there isn't just one, there are dozens, and they cover every aspect of Java. Java's patent situation is far worse than the.NET patent situation, and unlike.NET, there is not even an attempt at an open source implementation of the Java platform. Nor, for that matter, does there exist a useful patent-unencumbered subset of Java, while with C#, we get ECMA C#.
By all means, take a look at C# and.NET. I think C# is a nice language, but you want to stay away from the.NET APIs if you can. Fortunately, Mono is developing a large set of non-.NET APIs for Linux. Those have the additional advantage that if you already know libraries like Gtk+, you don't have to learn an entirely new set of APIs..NET is what it is: a Microsoft-proprietary solution, similar to what MFC and Win32 used to be. Mono's attempts at cloning them are similar to Wine's attempts at cloning Win32: a nice effort, but they probably won't succeed in the long run at making something fully compatible. If all you ever want to do is write Microsoft apps, there is nothing wrong with using the.NET APIs. Otherwise, using C# with non-.NET APIs is a good choice.
microsoft is finally supporting a community effort to port their technology to the open source community
Microsoft is not supporting Mono, they are at best tolerating it.
but why would you not throw everything you have behind mono? if anything, it will make a java-style write-once, run-anywhere implimentation no longer language specific, and no-longer a mess of cross-compatibility problems.
Seven years with Java have shown that WORA is useless: it doesn't really work, and the limited degree to which it does work is bought by lousy performance and non-native behavior on platforms like Linux.
What makes C# interesting is that it gives you all the nice language features of Java (plus some enhancements), but lets you access native libraries like Gtk+ easily.
with mono running, you could more easily make the case to business who run.Net sites and services to switch over to better linux solutions. [...] and here's the big one: Businesses could distribute a single code package and customers could install it on whatever system (MS or OSS) that they like.
That won't happen. What will happen is that if C# catches on at all, itwill end up being a better language for developing Linux native solutions, just like Microsoft's use of C++ boosted C++'s popularity and resulted in more C++ code on Linux.
or should we just blindly support java, and shun all things.net
We should support neither Java, nor C#, nor.NET blindly. We should think about what we support and why. Java will probably continue to be used for applets and a few cross-platform applications..NET will largely be a Microsoft-only solution. Mono and C#, however, have the potential of making application development on Linux much easier, and that's a good thing.
Mono is always going to be on shaky ground legally [...] Think before you endorse C#.
Maybe you should do some background research before you post. C# is an open, unencumbered language. The only thing that is at issue is whether Microsoft gets a patent on the totality of the.NET APIs and what that means. But for most of Mono, that doesn't matter because most applications in Mono are probably going to be written using the open ECMA C# core, Gtk#, and other bindings to native Linux libraries.
but it will let people begin their critical application development on Linux before deciding that for safety they need to move to Windows. If they wrote their application for Java instead,
If they wrote their applications in Java instead, they'd be killing Linux. Unlike C#, even the Java core APIs are encumbered by Sun patents, and there exists no open source implementation of the Java 2 platform (only very incomplete, partial implementations). Furthermore, Sun's Java implementation integrates poorly with Linux desktops. And Sun is as much of an enemy of Linux as Microsoft, as Sun's recent FUD about Linux and SCO reminds us of again. Sun would like to insert their proprietary APIs between open source applications and open source kernels in order to get some control back again.
If you are concerned about Mono's legal status, don't use it--there are plenty of alternatives. But Java isn't one of them. Java is a greater threat to open source software than Mono, both legally and practically. Whatever you do, don't use Java for writing open source software.
It's sad, really, that they don't understand that Java runs on win32 as well.
If you don't want to use.NET because of vendor lock-in, then Java isn't the answer. Despite the JCP and all the other fluff Sun puts out, Java is effectively Sun proprietary. If you pick Java, you get something that works less well than.NET on Windows, and you are locked into Sun's platform.
Just say no to both Java and.NET--there are plenty of alternatives out there.
It is a big, Microsoft-proprietary software package. It doesn't matter how good it is--the fact that a single company controls it is itself bad.
Note that that objection does not apply to Mono, ECMA C#, and the non-.NET APIs. Those are open, and they are good technologies to use. Presumably, that's what Ximian is using for Dashboard.
If you need to work on the Windows platform it's a godsend!
If you need to work on the Windows platform, use open APIs and languages, not Microsoft-proprietary APIs. You have plenty of choices: Mono is being ported, you can use wxWindows, Python, etc.
Neither the approach nor the results are particularly unique: statistical models are all the rage in natural language processing--and for good reasons. There are probably a few dozen research groups working on these kinds of systems.
But such systems also have well-understood limitations. Translation often does require a deeper understanding of the subject matter, and you simply cannot get that from aligning two large corpora.
The only Java implementations you can get are all based on code licensed from Sun. With the JCP, Sun stifles innovation and progress. And Sun holds numerous patents on Java technologies, making it unlikely that the platform will ever be truly open. With so much control over Java, it is particularly worrisome to see Sun's market evaporate--Sun is a company on the way down, and the question is: what will they do to/with Java before they hit bottom? An SCO-like scenario involving Sun, IBM, and open source implementations seems entirely plausible.
Both Java and.NET are attempts by two big competitors to establish new proprietary platforms and to do an end-run around open source systems like Linux. If a large fraction of the software on Linux were done in Java, for example, Sun could basically give their own platform an advantage by tinkering with the Java-on-Linux implementation.
The solution? Don't use either. Mono may be a way out because, in addition to a.NET compatible set of libraries (which you shouldn't use and which may be encumbered by patents), it is getting its own, native set of APIs.
But if you want to avoid the issue altogether, just don't use either Java or C#--there are plenty of good alternatives around. In fact, most software these days should probably be written in languages like Python, with a few core C/C++ libraries for numerical and other high-performance subroutines.
C# seems like a very nice programming language, but I really don't give a damn about.NET--as far as I'm concerned, Microsoft has never been able to put together a good set of APIs and.NET doesn't look like that has changed.
What I would like to see is a book on Mono, the core ECMA C# APIs, and the Mono-specific APIs like Gtk#. Is anybody working on that?
Slashdot Mirror
Well, that's fine as a general ideal to work towards, but compromises will always have to be made in an organization that isn't entirely composed of IT people.
Quite to the contrary: organizations composed primarily of non-IT people are the ones that most appreciate machines that "just work". You run into problems when every workgroup gets its own little IT "expert". Of course, if you run Windows, every workgroup needs its own little IT "expert" because machines constantly screw up, lock up, freeze, and do other weird things.
Hell, just adding a few Linux developers to the mix is enough to screw up any tightly controlled management scheme.
Huh? Why would professional Linux developers screw up management? In fact, UNIX developers, just like other users, traditionally also appreciate not having to bother with system management, and on UNIX machines, they don't have to. Again, it's only on Windows where every developer needs to become a system manager to make sure their machines have just the right combinations of tools, patches, IDEs, libraries, etc., and get reinstalled every few weeks.
That only works if the workstations are tightly controlled, secured and integrated into the server environment
Yes, the way a well-run IT department should operate. Microsoft shops have been trying to achieve that sort of operation for years, largely unsuccessfully and at enormous cost.
In a real-world organization with large numbers of loosely-coupled desktops and laptops, such a scheme is really painful to maintain.
Yes, many real-world organizations are incompetently run. In fact, many real-world organizations are incompetently run because their IT managers simply don't know anything other than Microsoft. And your point is what? That because many people don't know how to run an efficient IT infrastructure, everybody else should screw up in the same way?
And probably very insecure. At least SMB doesn't put too much trust in the client.
NFS's traditional security model was justified on traditional hardware and network setups, and it still works well in many environments. However, current versions of NFS do, in fact, support other security models as well, so you get your pick.
Well, the argument is obviously bogus. However, I think it's probably a good thing for free software if people who don't understand the GPL don't use GPL'ed code. Otherwise, we are going to get more groundless lawsuits like the one from SCO, and that is going to do a lot more harm than if some clueless C?O buys another few copies of Microsfot Office.
It seems that SCO are saying that the issue is not actually about copyrighted code being in Linux at all. The issue is about IBM putting it there in contravention of their contract to "keep it secret, keep it safe".
... are derivate works and therefore part of the Unix Software Product and that IBM disclosed the code, methods, secrets and for them to the Linux developers, then SCO wins its IBM lawsuit.
The way IBM released that code was over years, and each release was usually preceded by months of pre-announcements of what was going to happen. SCO clearly knew about it and if SCO had found any of that objectionable, they could have complained.
Simply put, if SCO-Caldera can prove that IBM-developed AIX code
Well, that's for IBM to worry about; it is of no relevance or consequence to Linux users.
As for IBM, it is inconceivable that IBM would have signed a contract that would let SCO win such a lawsuit.
The complaints that the GPL is "viral" would be fair if the consequences went beyond that: if, say, the result of this was that the whole of SCO Unix, not just that part in Linux, suddenly has to be GPL'd. This is not the case, as no part of SCO Unix has been copyrighted by an entity other than SCO or one that's licenced the code to SCO under the GPL.
Of course, if it turns out that the reason why there is (if there is) identical code in SCO UNIX and Linux is because SCO copied it from Linux, we may yet end up with SCO UNIX under the GPL, horrid as that may seem...
If the copyright holder did not Know they had code in Linux, they should not be obligated to have that code be considered GPLed because they distribute it.
While I might agree with that in some cases, here I think that argument doesn't apply.
The Linux kernel source wasn't just some piece of code that randomly found its way onto an SCO distribution medium. SCO was a kernel developer and contributor, so they were working with the code in question and they knew of its capabilities and that there might be a possibility that it violated their copyright.
If SCO was concerned about copyright violations vis-a-vis their own code base, it would have taken only a few minutes for them to check before redistributing the code. SCO was competent, knowledgeable, and the test was cheap and easy to do; the presumption should be that they did whatever they intended to do, and if they didn't complain at the time it was because they either didn't care or didn't exercise due dilligence.
And if they can convince a judge and jury that they have derivative rights to the AIX code base copyrighted by IBM, either by contract or by copyright, then the contribution of that code base to the Linux kernel is a violation of either the contract or the copyright on System V.
Well, excuse me, but there is a huge difference between "the contract" and "the copyright".
If IBM violated a contract with SCO, that's IBM's problem and IBM would have to pay the bill for that. If you have ever dealt with IBM's lawyers, you'd know that it is essentially an impossibility that IBM would have agreed to any contract that would open them up to such claims. But, whatever, IBM's contractual problems with SCO don't concern anybody other than IBM.
SCO only has copyright and patent laws to make claims against people it doesn't have contracts with. If those hypothetical "derivative rights" are based in copyright law, they don't cover "gaining experience from" or any other such vague constructions.
That is the strategy, it seems, and its not something that anyone should be scoffing at, becuase it just might be enough to win.
Well, bribing the judge might also be enough to win. However, as long as we discuss legal issues rationally, terminal stupidity, incompetence, or bribery are not things that it makes a lot of sense to spend a lot of time arguing about.
Why the sudden maintenance of SCO's secrecy, when there's an industry-wide history of violating similar NDAs at the first opportunity?
The most obvious explanation is: there simply is no infringing code and SCO made it all up.
If there is identical code at all, it was/is probably copied from public sources into both Linux and SCO UNIX, or it was copied into SCO UNIX from Linux. We may end up being able to force SCO to release all of SCO UNIX under the GPL (blech).
Sorry, but your argument is illinformed.
No, you're just reading things too narrowly.
Browsing and ACLs were popularized by Novell long before MS added them.
Novell was part of the first wave of Microsoft's bottom-up invasion of business, so that is my point.
And Unix was late to get these features because general fileserver applications were never a salespoint for Sun and the other Unix vendors.
You've got to be kidding. "General file server applications" have been such a natural, integral, and unobtrusive part of UNIX systems for so long that people like you seem to miss the fact that they are even there. Since almost the day UNIX workstations got networking hardware, the general setup of a UNIX network is to have central file servers serve home directories, most system software, and shared data directories, in a single unified namespace. Most people don't even ever notice that there exists things like file servers, it just all works seamlessly. And adding a new machine requires little more than plugging it into the network.
What Microsoft offers today in terms of file systems is still cumbersome compared to the services UNIX workstations have had for nearly two decades.
Kaffe is the open source one that isn't based on Sun code. I suspect that there are a few clean-room embedded VMs out there too, but I can't prove it.
Kaffe is not an implementation of the Java platform: it lacks numerous APIs and it is clearly not compliant with Sun's Java specification.
Technically, Kaffe is also far behind Mono, and Kaffe and gcj lack the user communities that Mono has. What makes Mono so successful is that, unlike Kaffe or gcj, Mono code can very easily access native libraries. Mono doesn't try to be primarily cross-platform or WORA, it tries to be a better system for Linux programming than C/C++, and it is succeeding admirably at that. Even if Sun Java weren't proprietary, it doesn't compete with that.
Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.
All of those implementations are based on code licensed from Sun, so all of them are under Sun's control and none of them are open source.
You are right that they are widely used, but this is not a good thing for Linux because it means that anybody that relies on that software is subject to Sun's whims and problems. Sun could decide to charge for Java licenses at any time, and we have to assume that they could force BEA and IBM to do the same thing. Of, some company hostile to Java and cross-platform software could acquire Sun and kill Java altogether.
I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.
The more the merrier, but I don't view Perl 6, a dynamically typed runtime, as being in the same league as Java or Mono.
And which of those is a browsable file sharing protocol? WebDAV?!? you can't be serious... [...] Sounds like they actually needed [wanted anyways] a file server that gave them ACL based permissions.
Browsable file sharing and ACLs are misfeatures that come out of Microsoft's bottom-up invasion of the enterprise. They make managing large installations a headache: you really don't want people setting up little servers everywhere and setting up weird and unmanageable permissions for their files. It really is no accident that UNIX has been slow in getting support for either feature even though UNIX has been used at sites with thousands of machines since before Windows NT even existed.
Having said that, Linux supports both of them, and, by definition, the way Linux supports those features is open (i.e., open source and hence open protocol). So, you can replace Microsoft's proprietary servers with open Linux servers, and you can even support those misfeatures if you like (and even serve Windows clients for the occasional Windows client software that doesn't yet have good Linux equivalents).
Face it, MS is EASIER for this type of thing.
No, it's not. I have administered machines for organizations of that size, and trust me, UNIX-based systems are far less work. The fewer Windows servers and clients you have, the easier your workload will get.
Even if I could afford to throw it all out, I have to think about what I'd use to replace things like Blackbaud (school admin software - non-profits),
Why would you replace it? You could still run a few Windows boxes with oddball software like that.
MS ISA with Surfcontrol,
Surfcontrol runs on Linux.
how to roll out public use Linux boxen with home directories.
There's nothing to "roll out"--on a well-run network, you just plug them in, set them up to boot over the network, and you are done.
Of course, if you don't know anything about Linux, then all of that is hard. But the fact that you don't know Linux doesn't make Microsoft a better or cheaper solution; it's just that your organization pays a premium for their software and support in order to accomodate your limited skill set.
Yes, of course Java is proprietary. As you may notice, I didn't list it as one of the open alternatives to .NET. In fact, I recommend you don't use Java for open source software development precisely because it is proprietary.
First, have they just said they would let the public use it, or have they actually licensed the patent for public use?
.NET APIs. But it doesn't make much sense to do that before the patent has actually issued.
.NET.
.NET, not as serious as those surrounding Java, but you can legitimately worry about them if you like.
.NET with Mono and C#. Even if .NET were completely off-limits to open source implementations, Mono would still be a thriving and useful project and a great platform for writing Linux applications because most of the APIs people use for writing Linux applications are not based on .NET.
They have done the same thing Sun has done with its numerous Java patents: they have stated that open source projects can use it. Can they go back on their word? Probably, just like Sun can. The real test will be for Mono to try to get something in writing from Microsoft permitting them to implement the
I doubt you have reviewed all of Microsoft's current patent holdings, so what are you basing your opinion on?
Patent "holdings" are public. I have looked through Microsoft's patents and patent applications, as have many other people; they are available at the USPTO site. Nobody has yet identified any problems.
I fail to see how you can claim there's nothing to worry about with
I didn't make any such claim. There are some minor concerns surrounding patent issues and
What you keep doing, however, is confusing
and found it wanting. A key problem area was interacting with the corporate Windows network.
Well, actually the real problem is that Windows server software is wanting: it fails to conform to standard protocols and formats. If Windows server software was built from the ground up around IMAP, XML, HTML, HTTP, WebDAV, and other such protocols, then Linux desktops and Mac desktops would work well with it. While Windows currently nominally supports many of those protocols and formats, they are second class compared to Microsoft's proprietary protocols.
What's the solution? Get rid of the Windows servers. That also lowers licensing, administrative, and maintenance costs. And Windows clients can talk fairly well to Linux servers running open source software.
I have one word for you: Patents.
.NET APIs and they have stated publicly that they will let open source implementations use it.
.NET APIs, it's a C# compiler and runtime, as well as a large set of non-.NET APIs. Even if Mono had to remove all the .NET APIs covered by the potential patent, it would still be a great platform.
.NET patent situation, and unlike .NET, there is not even an attempt at an open source implementation of the Java platform. Nor, for that matter, does there exist a useful patent-unencumbered subset of Java, while with C#, we get ECMA C#.
Microsoft has applied for one patent on the
Mono, however, is not primarily an implementation of the
Also, I'd suggest you check the USPTO web site for Sun patents related to Java; there isn't just one, there are dozens, and they cover every aspect of Java. Java's patent situation is far worse than the
By all means, take a look at C# and .NET. I think C# is a nice language, but you want to stay away from the .NET APIs if you can. Fortunately, Mono is developing a large set of non-.NET APIs for Linux. Those have the additional advantage that if you already know libraries like Gtk+, you don't have to learn an entirely new set of APIs. .NET is what it is: a Microsoft-proprietary solution, similar to what MFC and Win32 used to be. Mono's attempts at cloning them are similar to Wine's attempts at cloning Win32: a nice effort, but they probably won't succeed in the long run at making something fully compatible. If all you ever want to do is write Microsoft apps, there is nothing wrong with using the .NET APIs. Otherwise, using C# with non-.NET APIs is a good choice.
microsoft is finally supporting a community effort to port their technology to the open source community
.Net sites and services to switch over to better linux solutions. [...] and here's the big one: Businesses could distribute a single code package and customers could install it on whatever system (MS or OSS) that they like.
.net
.NET blindly. We should think about what we support and why. Java will probably continue to be used for applets and a few cross-platform applications. .NET will largely be a Microsoft-only solution. Mono and C#, however, have the potential of making application development on Linux much easier, and that's a good thing.
Microsoft is not supporting Mono, they are at best tolerating it.
but why would you not throw everything you have behind mono? if anything, it will make a java-style write-once, run-anywhere implimentation no longer language specific, and no-longer a mess of cross-compatibility problems.
Seven years with Java have shown that WORA is useless: it doesn't really work, and the limited degree to which it does work is bought by lousy performance and non-native behavior on platforms like Linux.
What makes C# interesting is that it gives you all the nice language features of Java (plus some enhancements), but lets you access native libraries like Gtk+ easily.
with mono running, you could more easily make the case to business who run
That won't happen. What will happen is that if C# catches on at all, itwill end up being a better language for developing Linux native solutions, just like Microsoft's use of C++ boosted C++'s popularity and resulted in more C++ code on Linux.
or should we just blindly support java, and shun all things
We should support neither Java, nor C#, nor
Mono is always going to be on shaky ground legally [...] Think before you endorse C#.
.NET APIs and what that means. But for most of Mono, that doesn't matter because most applications in Mono are probably going to be written using the open ECMA C# core, Gtk#, and other bindings to native Linux libraries.
Maybe you should do some background research before you post. C# is an open, unencumbered language. The only thing that is at issue is whether Microsoft gets a patent on the totality of the
but it will let people begin their critical application development on Linux before deciding that for safety they need to move to Windows. If they wrote their application for Java instead,
If they wrote their applications in Java instead, they'd be killing Linux. Unlike C#, even the Java core APIs are encumbered by Sun patents, and there exists no open source implementation of the Java 2 platform (only very incomplete, partial implementations). Furthermore, Sun's Java implementation integrates poorly with Linux desktops. And Sun is as much of an enemy of Linux as Microsoft, as Sun's recent FUD about Linux and SCO reminds us of again. Sun would like to insert their proprietary APIs between open source applications and open source kernels in order to get some control back again.
If you are concerned about Mono's legal status, don't use it--there are plenty of alternatives. But Java isn't one of them. Java is a greater threat to open source software than Mono, both legally and practically. Whatever you do, don't use Java for writing open source software.
It's sad, really, that they don't understand that Java runs on win32 as well.
.NET because of vendor lock-in, then Java isn't the answer. Despite the JCP and all the other fluff Sun puts out, Java is effectively Sun proprietary. If you pick Java, you get something that works less well than .NET on Windows, and you are locked into Sun's platform.
.NET--there are plenty of alternatives out there.
If you don't want to use
Just say no to both Java and
So what exactly is wrong with .NET?
It is a big, Microsoft-proprietary software package. It doesn't matter how good it is--the fact that a single company controls it is itself bad.
Note that that objection does not apply to Mono, ECMA C#, and the non-.NET APIs. Those are open, and they are good technologies to use. Presumably, that's what Ximian is using for Dashboard.
If you need to work on the Windows platform it's a godsend!
If you need to work on the Windows platform, use open APIs and languages, not Microsoft-proprietary APIs. You have plenty of choices: Mono is being ported, you can use wxWindows, Python, etc.
Neither the approach nor the results are particularly unique: statistical models are all the rage in natural language processing--and for good reasons. There are probably a few dozen research groups working on these kinds of systems.
But such systems also have well-understood limitations. Translation often does require a deeper understanding of the subject matter, and you simply cannot get that from aligning two large corpora.
The only Java implementations you can get are all based on code licensed from Sun. With the JCP, Sun stifles innovation and progress. And Sun holds numerous patents on Java technologies, making it unlikely that the platform will ever be truly open. With so much control over Java, it is particularly worrisome to see Sun's market evaporate--Sun is a company on the way down, and the question is: what will they do to/with Java before they hit bottom? An SCO-like scenario involving Sun, IBM, and open source implementations seems entirely plausible.
.NET are attempts by two big competitors to establish new proprietary platforms and to do an end-run around open source systems like Linux. If a large fraction of the software on Linux were done in Java, for example, Sun could basically give their own platform an advantage by tinkering with the Java-on-Linux implementation.
.NET compatible set of libraries (which you shouldn't use and which may be encumbered by patents), it is getting its own, native set of APIs.
Both Java and
The solution? Don't use either. Mono may be a way out because, in addition to a
But if you want to avoid the issue altogether, just don't use either Java or C#--there are plenty of good alternatives around. In fact, most software these days should probably be written in languages like Python, with a few core C/C++ libraries for numerical and other high-performance subroutines.
C# seems like a very nice programming language, but I really don't give a damn about .NET--as far as I'm concerned, Microsoft has never been able to put together a good set of APIs and .NET doesn't look like that has changed.
What I would like to see is a book on Mono, the core ECMA C# APIs, and the Mono-specific APIs like Gtk#. Is anybody working on that?
Class 1 Bluetooth has a range of 100m (=300ft), comparable to 802.11.