Real advantage?
on
What is .NET?
·
· Score: 2, Insightful
You can write in "whatever language you want" as long as the language has been designed (or re-designed) to work with the CLR. You don't use VB with the CLR, you use VB.NET. You don't use C++, you use a bastard hybrid Managed-C++. You don't use Smalltalk or Scheme or Perl, you use something that's kind of like Smalltalk or Scheme or Perl. Not that big an advance, if you ask me.
Re:.NET good, not evil
on
What is .NET?
·
· Score: 4, Informative
They are developing a FreeBSD port of that incomplete and nearly useless portion that they are submitting as a standard. Real.NET apps will in fact be confined to the Windows platform, unless Mono is much more successful than I suspect it can be.
Finally? Java has been out for about 5 years
on
What is .NET?
·
· Score: 1
...and it has all the advantages of which you speak.
VB changes, C++ changes, J++ changes
on
What is .NET?
·
· Score: 2, Insightful
Which goes to show that "language-neutrality" is a myth. The CLR can't even support VB without changing it into a C#-work-alike.
There is another issue--
The CLR provides built-in support for some, but not other, models of higher-level language constructs (such as exception propagation and method dispatch). If the language implementation needs similar concepts but for one reason or another can not use the built-in support, it can still be implemented but it will run an order or magnitude slower (it will essentially be impractical). So the CLR is actually only useful as a target for a sub-set of languages and for other languages that have been designed specficially to use it.
The JVM is just as multi-language as the CLR. Both will run any language re-designed to run on top of them. CLR has a few more features than the JVM, but as other posts have pointed out, all languages running on the CLR end up looking like C#.
You betray a very limited understanding of the problem. The CLR (like the JVM) makes a number of assumptions about the nature of programs running upon it that a CPU can never make--things like the way stack frames are created, exceptions are propagated, methods are dispatched. If the language is not designed with the same assumptions, it can not run on the CLR (of course, if you are going to give up all efficiency, you could write another VM in C# and target the lanugage at that). All the languages that the CLR supports--even MS languages like VB--have been re-designed to work with the CLR.
The CLR does support some feature that the JVM does not (notably, pointers). However, it is not true to suggest that it supports multiple languages in a way that the JVM does not. Languages have to be re-designed to run within the CLR-- you can't run "real" C or Perl or Java on the CLR.
The point is, just like the JVM, the CLR can run any language as long as the language is re-designed to run with the CLR. The Common-Language part of CLR is basically marketing BS.
If you read the post you'd understand the difference between the Java standard and the Microsoft standard-- all the information required to do a useful implementation of the Java standard is publicly available. Sure Sun insists on maintaining control of the standard. At least they are being honest. Microsoft is submitting a carefully selected sub-set of.NET to a pliable standards body.
Likely the assailant is using anti-biotics (quite common ones work) to protect himself, so he hasn't died.
He may have run out of material, or he may be awaiting further orders. I don't believe the lone madman stuff, since I can't believe a lone nut would try to implicate someone else in his attacks (the Unabomber certainly didn't).
AFAIK The precedence in terms of legal weight of the Constitution with Amendments, Treaties, and Federal and State Laws is firmly established with lots of precedent.
Federal law trumps state law unless there is a constitutional question.
Duly adopted treaties have precedence over Federal laws.
The Constitution has precedence over all of the above; if a provision of a treaty is in conflict with the Constitution, it is invalid.
Article VI does not say that treaties can override the U.S. Constitution; it says that treaties can override State laws and Constitutions.
They are suing Fastrak as well, but it is a more difficult problem since they are not in the U.S. Hilary Rosen seems to think that the RIAA will be able to come to a settlement/buy-out Fastrak, which will leave all the Morpheus/KaZaA/MusicCity users in the lurch, since those companies are totally dependent on Fastrak to supply the software and run the network.
Best to switch to an open-source solution now. Gnucleus now, Freenet someday.
The 10K was just for the proxy server and related filter, not for the whole shop. I didn't have much trouble figuring that out, and I'm not even a MCSE:)
EFF.org does accept donations online, and they send you a nifty bumper sticker when you join up! Everyone who reads YRO on Slashdot should be a member.
and then Kazaa, Morpheus and MusicCity instantly become irrelevant. FastTrack is a small company in it for the money. The record companies could make them happy probably for less money then they would spend in legal fees suing the other companies.
FastTrack will probably announce its new, "rights-protecting" software at about the same time that the record company-sponsored download sites become available, so its large customer base will be in the lurch and vulnerable to being picked up by the record companies.
EFF should save its resources for defending file-sharing based on Open Source software.
The problem with this approach is that nobody writes "applications" for Windows, command-line, GUI, or otherwise. They write modules that fit into MS (or third-party vendor) supplied applications. These modules of course are not cross-platform unless the application incorporating them is, and the enclosing applications of course will never be ported. The POSIX layer in NT is an unused appendix. Partially this is the result of Windows having a working component-software model; partially it is the result of everything about the Windows architecture quite intentionally discouraging cross-platform development.
If the proper forum were available where appreciative listeners could pool money to send DIRECTLY to the artists that they enjoy listening to, I think many people would line up give their fair share.
www.fairtunes.com exists for just this purpose. Go ahead and line up!
This misses the other big application of XML that is going to be successful: separating content information from formatting information. Presenting data using XSL to format data supplied in XML is a huge step over HTML and other data formats that commingle content and presentation.
...like Jabber Inc. for Jabber, it would be natural to send them the RFP.
Otherwise, identify the principal developers and perhaps some prominent users and ask them to recommend a software service organization that is familiar with the software (they might work for one!) Send them the RFP.
If you are putting together an RFP, you have to be planning on spending some money. You will probably spend less money for an open-source solution, but you can't expect everything to be free. Responding to an RFP is excruciating work that only a commercial firm is likely to do. A company that is familiar with the software and is committed to the open source development process can probably put together a good, cost-effective solution for you.
bochs is a portable, open-source PC emulator-- not only will it run on Linux and Windows, put on PPC and Sparc hardware too.
It is slow enough (on today's hardware, about a 386/12 to 386/33) that it is a good match for older DOS games and normally you do not need a slowdown utility (which can have unexpected effects).
C# is kind of a fun language in itself without the CLR. You might want to write C# code that interacts with the Java run-time; then you'd just worry about compiling it to java bytecodes without trying to do (admittedly pointless) library translation.
See, the Java runtime is just as multi-language as the CLR; they both support multiple languages, as long as the code is written specifically to work with them.
What we really need instead of J#
on
J#
·
· Score: 2, Insightful
Is a compiler that turns C# code into JVM bytecodes, so we can use the kind-of-neat C# language syntax with the mature Java tools. This shouldn't even be that hard to do (well, a little harder than a Java compiler).
By the way, the CLR runtime supporting multiple languages is kind of a myth. Each language that the CLR supports has been rewritten (with new syntax, etc.) so it can be used with CLR. No code in an existing language will work with CLR without going through a migration. If you are going to work with CLR, you might as well use it's native language (C#) directly.
Slashdot Mirror
You can write in "whatever language you want" as long as the language has been designed (or re-designed) to work with the CLR. You don't use VB with the CLR, you use VB.NET. You don't use C++, you use a bastard hybrid Managed-C++. You don't use Smalltalk or Scheme or Perl, you use something that's kind of like Smalltalk or Scheme or Perl. Not that big an advance, if you ask me.
They are developing a FreeBSD port of that incomplete and nearly useless portion that they are submitting as a standard. Real .NET apps will in fact be confined to the Windows platform, unless Mono is much more successful than I suspect it can be.
...and it has all the advantages of which you speak.
Which goes to show that "language-neutrality" is a myth. The CLR can't even support VB without changing it into a C#-work-alike.
There is another issue-- The CLR provides built-in support for some, but not other, models of higher-level language constructs (such as exception propagation and method dispatch). If the language implementation needs similar concepts but for one reason or another can not use the built-in support, it can still be implemented but it will run an order or magnitude slower (it will essentially be impractical). So the CLR is actually only useful as a target for a sub-set of languages and for other languages that have been designed specficially to use it.
The JVM is just as multi-language as the CLR. Both will run any language re-designed to run on top of them. CLR has a few more features than the JVM, but as other posts have pointed out, all languages running on the CLR end up looking like C#.
You betray a very limited understanding of the problem. The CLR (like the JVM) makes a number of assumptions about the nature of programs running upon it that a CPU can never make--things like the way stack frames are created, exceptions are propagated, methods are dispatched. If the language is not designed with the same assumptions, it can not run on the CLR (of course, if you are going to give up all efficiency, you could write another VM in C# and target the lanugage at that). All the languages that the CLR supports--even MS languages like VB--have been re-designed to work with the CLR.
The CLR does support some feature that the JVM does not (notably, pointers). However, it is not true to suggest that it supports multiple languages in a way that the JVM does not. Languages have to be re-designed to run within the CLR-- you can't run "real" C or Perl or Java on the CLR.
The point is, just like the JVM, the CLR can run any language as long as the language is re-designed to run with the CLR. The Common-Language part of CLR is basically marketing BS.
If you read the post you'd understand the difference between the Java standard and the Microsoft standard-- all the information required to do a useful implementation of the Java standard is publicly available. Sure Sun insists on maintaining control of the standard. At least they are being honest. Microsoft is submitting a carefully selected sub-set of .NET to a pliable standards body.
Which is fine until they decide they do want to route to the Internet...
Likely the assailant is using anti-biotics (quite common ones work) to protect himself, so he hasn't died. He may have run out of material, or he may be awaiting further orders. I don't believe the lone madman stuff, since I can't believe a lone nut would try to implicate someone else in his attacks (the Unabomber certainly didn't).
Federal law trumps state law unless there is a constitutional question.
Duly adopted treaties have precedence over Federal laws.
The Constitution has precedence over all of the above; if a provision of a treaty is in conflict with the Constitution, it is invalid.
Article VI does not say that treaties can override the U.S. Constitution; it says that treaties can override State laws and Constitutions.
They are suing Fastrak as well, but it is a more difficult problem since they are not in the U.S. Hilary Rosen seems to think that the RIAA will be able to come to a settlement/buy-out Fastrak, which will leave all the Morpheus/KaZaA/MusicCity users in the lurch, since those companies are totally dependent on Fastrak to supply the software and run the network.
Best to switch to an open-source solution now. Gnucleus now, Freenet someday.
The 10K was just for the proxy server and related filter, not for the whole shop. I didn't have much trouble figuring that out, and I'm not even a MCSE :)
EFF.org does accept donations online, and they send you a nifty bumper sticker when you join up! Everyone who reads YRO on Slashdot should be a member.
and then Kazaa, Morpheus and MusicCity instantly become irrelevant. FastTrack is a small company in it for the money. The record companies could make them happy probably for less money then they would spend in legal fees suing the other companies.
FastTrack will probably announce its new, "rights-protecting" software at about the same time that the record company-sponsored download sites become available, so its large customer base will be in the lurch and vulnerable to being picked up by the record companies.
EFF should save its resources for defending file-sharing based on Open Source software.
The problem with this approach is that nobody writes "applications" for Windows, command-line, GUI, or otherwise. They write modules that fit into MS (or third-party vendor) supplied applications. These modules of course are not cross-platform unless the application incorporating them is, and the enclosing applications of course will never be ported. The POSIX layer in NT is an unused appendix. Partially this is the result of Windows having a working component-software model; partially it is the result of everything about the Windows architecture quite intentionally discouraging cross-platform development.
www.fairtunes.com exists for just this purpose. Go ahead and line up!
This misses the other big application of XML that is going to be successful: separating content information from formatting information. Presenting data using XSL to format data supplied in XML is a huge step over HTML and other data formats that commingle content and presentation.
...like Jabber Inc. for Jabber, it would be natural to send them the RFP. Otherwise, identify the principal developers and perhaps some prominent users and ask them to recommend a software service organization that is familiar with the software (they might work for one!) Send them the RFP. If you are putting together an RFP, you have to be planning on spending some money. You will probably spend less money for an open-source solution, but you can't expect everything to be free. Responding to an RFP is excruciating work that only a commercial firm is likely to do. A company that is familiar with the software and is committed to the open source development process can probably put together a good, cost-effective solution for you.
http://bochs.sourceforge.net
Yes-- a previous thread mentioned that Secure Password Authentication is a Microsoft-specific POP3 extension.
C# is kind of a fun language in itself without the CLR. You might want to write C# code that interacts with the Java run-time; then you'd just worry about compiling it to java bytecodes without trying to do (admittedly pointless) library translation. See, the Java runtime is just as multi-language as the CLR; they both support multiple languages, as long as the code is written specifically to work with them.
Is a compiler that turns C# code into JVM bytecodes, so we can use the kind-of-neat C# language syntax with the mature Java tools. This shouldn't even be that hard to do (well, a little harder than a Java compiler). By the way, the CLR runtime supporting multiple languages is kind of a myth. Each language that the CLR supports has been rewritten (with new syntax, etc.) so it can be used with CLR. No code in an existing language will work with CLR without going through a migration. If you are going to work with CLR, you might as well use it's native language (C#) directly.