However, as long as you want.net languages to share the.net class library (i.e. use C# written classes fully in another.net language, and use classes written in the other.net language in C#), the languages MUST be fundamentally equal.
Rubbish. The languages must understand the same object model to map libraries in a meaningful way, but this does not make the languages "fundamentally equal" unless your definition of "fundamentally" is "understand the same object model on some level". Many of the.NET languages have vastly different programming models and type systems, and yes, many have had to have interop features hacked on in order to leverage the.NET runtimes, but they are not "fundamentally equal" in any sane sense.
Why do you think that most native languages can only share the lowest common denominator, C, to glue things together? Java can call C, Fortran can call C, Python can call C, etc. etc. But they cannot call each other directly. It is impossible, unless the language are all the same in disguise, which is the case currently with all.net languages.
This is a really flimsy argument at best. You equate the "ability to interoperate" with "fundamentally equal", which is just so wrong I'm not sure where to start. A language is defined by far more than being able to call some foreign code.
If you would make a really different language running on.net, then what would be the point? You would not be able to use the.net libraries, so the language would be "stand alone". In that case you might as well compile the language natively instead.
Define "really different". Like Eiffel, with multiple inheritance and design by contract? I'd call that "really different". How about Standard ML - I'd call a functional language "really different" to C#. But your argument does display a certain ignorance. If you could build a compiler for a language that is "really different" that targetted managed.NET IL, you're language could get garbage collection for free, as well as verifiably type-safe code. Sure you mightn't be able to verify your own type system, but any executable built with your compiler would be guaranteed to be free of buffer overflows and any wacko pointer arithmetic. Then you get.NET's security model, which means you can build apps people can download and trust because they can sandbox them. And THEN, if you hack it in somehow, you might even be able to leverage framework libraries if you can handle the messiness involved. The "point" is only too obvious to anyone who has any experience in this field.
But languages in.Net are not equal to the real languages.
Some are more different than others, but there are some which are almost identical. The reason they are different is that, in order to be verifiable and managed, they have to map to managed IL. So you're not going to be able to compile some code directly, but when you do, you'll have managed, and verifiably type safe code..Net multi-language support is a hoax. It is just multiple syntax support for C#. Why do you think VB.Net is os different from the original VB (which was crap anyway).
Pure FUD. There are plenty of languages implemented for.NET that have significantly different type systems and programming models to C#. While VB.NET and J# are very similar to C# they are not syntactically equivalent, regardless of how many Slashdotters assert it. Very many of the third party languages developed for.NET are significantly different to C#.
You can also compile many language in JVM, but SUN has never used that as a selling point since it is pretty silly.
Pure revisionism. Sun has never used that a selling point because they don't want to support languages that they don't control. "Pretty silly" doesn't come into it, unless you consider "being able to leverage the skills of people who don't know Java" to be "pretty silly".
All.net languages are fundamentally equal, just the syntax is different.
Bullshit. All.NET languages target IL. All managed.NET languages have to target managed IL. And, yes, there are some languages that you can't implement efficiently and some that you can't implement correctly if you want them to be managed. But to say that.NET languages are fundamentally equal is wrong. Or perhaps you'd like to show me the syntactic sugar to go from C# to Eiffel.NET? Or how to syntactic sugar Component Pascal's covariant return types or IN parameters? I'm also interested in how SML.NET is fundamentally equivalent to VB.NET.
Do you really think they could cleanroom stolen code without repercussions? If they got found out, Microsoft would have a freaking field day with it. And not just in the courts either - you can bet it would be splashed around the media as well. Even IF they had a legal leg to stand on, it would be utter stupidity to try it.
There's already a serious deficit blow-out, government spending is increasing at an unsustainable rate, the US is still officially at war with someone - we're not quite sure who, but there's quite a few suspicious looking goatherds in north-western Pakistan - and to top it all off, no one is really sure if the economy is picking up or relocating to a happier country.
From what I've seen, most really arent using.Net compilers. The colleges are teaching Java, C , and C++ using either GCC or MS Visual C.
There's plenty of schools that teach.NET languages, and plenty of programmers and companies using the software. Many of Microsoft's new applications are based on.NET, and Longhorn is already being used internally at Microsoft..NET is most definitely being stress-tested.
What I really worry about is that creeping errors that force the users to juggle between versions of.net to run certain un-updated programs. I'm thinking of the similar problems that haunt Linux/unix programs that are made for 1 version of a lib. Of course, there's 3 different programs that need diferent versions because of inconsitincies (think SDL)
Microsoft already supports side-by-side installation of different versions of the runtime..NET has a pretty amazing versioning scheme - the best software versioning mechanism around, IMO. That's not to say they haven't had versioning problems. Microsoft has had issues with versioning between versions 1.0 and 1.1, in that they couldn't update individual dlls from the framework without updating all the dlls. There attempting to address as well, using a kind of layered type system for specifying application vs framework types. Seems interesting but I'm not totally convinced.
It's meant both ways.. In making of programs, there's always internal libaraies that are meant to make dev easier. Sometimes they're left in accidently. Sometimes they're also a way to speed up a program (Like MS Office does). Either way can lead to buffer overflows and holes outside of the managed environment.
The beauty of managed, verifiable code is that you can actually stop people from calling internal APIs, and running unsafe code. It's not as simple as linking to any old dll anymore - you actually have to write type-safe code, which means you can't link to arbitrary code. The biggest issues will come with backwards interop of course but I don't think they are planning to make Longhorn backwards compatible....stuff about security snipped...
I'm not sure what security model they're planning for Longhorn, but the security model for.NET is capability based, and quite fine-grained at that. You can set different levels of trust for different kinds of applications. Whatever the case, you'd hope that Microsoft has learnt from its many mistakes in this field by the time Longhorn comes around. I can understand if people aren't holding their breath...
Course, I'm an old jaded Sysad who perfers the basics like Bash, Expect, C, X86/68k/z80 asm. I guess I've seen way too many whiz-bang features on OS'es and programs that the 'next cool thing' just doesnt faze me.
I like all the new whiz-bang stuff - but I still install cygwin on all my Windows boxes for bash, gcc and the rest.;)
And just as something that I just thought of.... Preety much everything you said was said back in '96(?) when SUN was talking up Java.
Gives you an indication of the level of hype around Java at the time, eh?;)
Seriously though - when Longhorn comes out it will be 2006. That's more than ten years after Java was conceived. Why shouldn't all the stuff that Java promised finally be delivered after 10 years? Java is really cool, but somewhere Sun lost its way and Java has become focussed almost solely on enterprise business. Never mind that Sun barely turns a profit despite inventing one of the key technologies of the 90s. Maybe if things go well for Sun their Java Desktop Environment will actually have something to do with Java. But right now, Microsoft is the one pushing the envelope. Regardless of whether it succeeds or not, it will be an interesting experiment and it will be interesting to see how the rest of the OS world responds.
Call me a cynic, but to really participate in democracy you need to be part of some powerful lobby group or business that the government wants to please for votes or campaign donations.
In my country anyway, there's a serious disconnect between big government and the general populace that is only barely bridged by the sensationalist media.
It's nice to hear that governments are building processes for getting feedback from the general public I still don't see this helping the little guy affect big picture legislation as much as the 2 million dollar donation from corporate sponsor X...
Score 0 again. I think a post should get a point for being replied to by one or more non-ACs. That would both reward attractive posts and deter people from pointlessly flaming (as the response would +1 the message).
Well I've registered again now. I'll see how long I can keep this account out of negative karma territory.
The easiest way out for an installer is "Yes to all". But that is not the best way, for society as a whole whether or not you argue in favour of the results for the individual user (I don't).
Hmm, well, IMHO the laws you mention aren't primarily there to prevent the easy way out, but more to protect the general populace from hurting themselves and other people. I can see your reasoning though.
Exactly parallel to the smoker. Or emission controls, for that matter.
Assuming I agree that we need to legislate to remove the "easy choice", yes. I still think an alternate delivery system would be far more productive. Imagine that, rather than forcing Microsoft to unbundle their product, Microsoft were forced to devise a customization system, that allowed third party software to be easily delivered with a new install. The technology might be a few years off, and Microsoft would still benefit on the Operating System front, but it would be far more productive than forcing customers to do extra stuff.
..stuff about Opera...
That all sounds nice, but it seems a bit of a pipe-dream. Even if the EU or the DOJ did decide to force Microsoft to carry a competitor's product, I don't think it would achieve the goals of increasing competition. In the end all it does is lets those apps tap into the Microsoft monopoly for a time.
Think of it as a fat click-through.
Very fat. You can bet Microsoft would have a few nice "Install [unbundled app]" icons for every new install.
Odd. I'm a loud-mouthed and offensive bugger at the best of times, and that's never happened to me. What did you do to earn your slagging-down?
I'm a loud-mouthed and offensive bugger who sees a fair bit of technical merit in Microsoft's recent work, which is an occaisional recipe for disaster here.;) I usually have to hold my tongue to keep the bad karma at bay although I'm not sure I should have to...
I think you missed his point. He's not talking about hardware platform dependencies - he's talking about software dependencies on the fix. In this case, Microsoft had to patch almost their entire NT line of operating systems, and each OS would have a number of applications dependant on that code. The Apache/IIS comparison isn't the correct analogy for this.
Having said that, six months is still too long. I can see why Microsoft would take longer to fix this as compared to Apache, or some other OSS app, but six months is pushing it.
All you have found is that your box has OpenSSL for windows installed. AFAIK, ssleay32.dll not distributed by Microsoft, it's built from the OpenSLL source.
Slashdot Mirror
However, as long as you want .net languages to share the .net class library (i.e. use C# written classes fully in another .net language, and use classes written in the other .net language in C#), the languages MUST be fundamentally equal.
.NET languages have vastly different programming models and type systems, and yes, many have had to have interop features hacked on in order to leverage the .NET runtimes, but they are not "fundamentally equal" in any sane sense.
.net languages.
.net, then what would be the point? You would not be able to use the .net libraries, so the language would be "stand alone". In that case you might as well compile the language natively instead.
.NET IL, you're language could get garbage collection for free, as well as verifiably type-safe code. Sure you mightn't be able to verify your own type system, but any executable built with your compiler would be guaranteed to be free of buffer overflows and any wacko pointer arithmetic. Then you get .NET's security model, which means you can build apps people can download and trust because they can sandbox them. And THEN, if you hack it in somehow, you might even be able to leverage framework libraries if you can handle the messiness involved. The "point" is only too obvious to anyone who has any experience in this field.
Rubbish. The languages must understand the same object model to map libraries in a meaningful way, but this does not make the languages "fundamentally equal" unless your definition of "fundamentally" is "understand the same object model on some level". Many of the
Why do you think that most native languages can only share the lowest common denominator, C, to glue things together? Java can call C, Fortran can call C, Python can call C, etc. etc. But they cannot call each other directly. It is impossible, unless the language are all the same in disguise, which is the case currently with all
This is a really flimsy argument at best. You equate the "ability to interoperate" with "fundamentally equal", which is just so wrong I'm not sure where to start. A language is defined by far more than being able to call some foreign code.
If you would make a really different language running on
Define "really different". Like Eiffel, with multiple inheritance and design by contract? I'd call that "really different". How about Standard ML - I'd call a functional language "really different" to C#. But your argument does display a certain ignorance. If you could build a compiler for a language that is "really different" that targetted managed
But languages in .Net are not equal to the real languages.
.Net multi-language support is a hoax. It is just multiple syntax support for C#. Why do you think VB.Net is os different from the original VB (which was crap anyway).
.NET that have significantly different type systems and programming models to C#. While VB.NET and J# are very similar to C# they are not syntactically equivalent, regardless of how many Slashdotters assert it. Very many of the third party languages developed for .NET are significantly different to C#.
Some are more different than others, but there are some which are almost identical. The reason they are different is that, in order to be verifiable and managed, they have to map to managed IL. So you're not going to be able to compile some code directly, but when you do, you'll have managed, and verifiably type safe code.
Pure FUD. There are plenty of languages implemented for
You can also compile many language in JVM, but SUN has never used that as a selling point since it is pretty silly.
.net languages are fundamentally equal, just the syntax is different.
.NET languages target IL. All managed .NET languages have to target managed IL. And, yes, there are some languages that you can't implement efficiently and some that you can't implement correctly if you want them to be managed. But to say that .NET languages are fundamentally equal is wrong. Or perhaps you'd like to show me the syntactic sugar to go from C# to Eiffel.NET? Or how to syntactic sugar Component Pascal's covariant return types or IN parameters? I'm also interested in how SML.NET is fundamentally equivalent to VB.NET.
Pure revisionism. Sun has never used that a selling point because they don't want to support languages that they don't control. "Pretty silly" doesn't come into it, unless you consider "being able to leverage the skills of people who don't know Java" to be "pretty silly".
All
Bullshit. All
Do you really think they could cleanroom stolen code without repercussions? If they got found out, Microsoft would have a freaking field day with it. And not just in the courts either - you can bet it would be splashed around the media as well. Even IF they had a legal leg to stand on, it would be utter stupidity to try it.
There's already a serious deficit blow-out, government spending is increasing at an unsustainable rate, the US is still officially at war with someone - we're not quite sure who, but there's quite a few suspicious looking goatherds in north-western Pakistan - and to top it all off, no one is really sure if the economy is picking up or relocating to a happier country.
Who's gonna foot the bill?
From what I've seen, most really arent using .Net compilers. The colleges are teaching Java, C , and C++ using either GCC or MS Visual C.
.NET languages, and plenty of programmers and companies using the software. Many of Microsoft's new applications are based on .NET, and Longhorn is already being used internally at Microsoft. .NET is most definitely being stress-tested.
.net to run certain un-updated programs. I'm thinking of the similar problems that haunt Linux/unix programs that are made for 1 version of a lib. Of course, there's 3 different programs that need diferent versions because of inconsitincies (think SDL)
.NET has a pretty amazing versioning scheme - the best software versioning mechanism around, IMO. That's not to say they haven't had versioning problems. Microsoft has had issues with versioning between versions 1.0 and 1.1, in that they couldn't update individual dlls from the framework without updating all the dlls. There attempting to address as well, using a kind of layered type system for specifying application vs framework types. Seems interesting but I'm not totally convinced.
...stuff about security snipped...
.NET is capability based, and quite fine-grained at that. You can set different levels of trust for different kinds of applications. Whatever the case, you'd hope that Microsoft has learnt from its many mistakes in this field by the time Longhorn comes around. I can understand if people aren't holding their breath...
;)
;)
There's plenty of schools that teach
What I really worry about is that creeping errors that force the users to juggle between versions of
Microsoft already supports side-by-side installation of different versions of the runtime.
It's meant both ways.. In making of programs, there's always internal libaraies that are meant to make dev easier. Sometimes they're left in accidently. Sometimes they're also a way to speed up a program (Like MS Office does). Either way can lead to buffer overflows and holes outside of the managed environment.
The beauty of managed, verifiable code is that you can actually stop people from calling internal APIs, and running unsafe code. It's not as simple as linking to any old dll anymore - you actually have to write type-safe code, which means you can't link to arbitrary code. The biggest issues will come with backwards interop of course but I don't think they are planning to make Longhorn backwards compatible.
I'm not sure what security model they're planning for Longhorn, but the security model for
Course, I'm an old jaded Sysad who perfers the basics like Bash, Expect, C, X86/68k/z80 asm. I guess I've seen way too many whiz-bang features on OS'es and programs that the 'next cool thing' just doesnt faze me.
I like all the new whiz-bang stuff - but I still install cygwin on all my Windows boxes for bash, gcc and the rest.
And just as something that I just thought of.... Preety much everything you said was said back in '96(?) when SUN was talking up Java.
Gives you an indication of the level of hype around Java at the time, eh?
Seriously though - when Longhorn comes out it will be 2006. That's more than ten years after Java was conceived. Why shouldn't all the stuff that Java promised finally be delivered after 10 years? Java is really cool, but somewhere Sun lost its way and Java has become focussed almost solely on enterprise business. Never mind that Sun barely turns a profit despite inventing one of the key technologies of the 90s. Maybe if things go well for Sun their Java Desktop Environment will actually have something to do with Java. But right now, Microsoft is the one pushing the envelope. Regardless of whether it succeeds or not, it will be an interesting experiment and it will be interesting to see how the rest of the OS world responds.
Call me a cynic, but to really participate in democracy you need to be part of some powerful lobby group or business that the government wants to please for votes or campaign donations. In my country anyway, there's a serious disconnect between big government and the general populace that is only barely bridged by the sensationalist media.
It's nice to hear that governments are building processes for getting feedback from the general public I still don't see this helping the little guy affect big picture legislation as much as the 2 million dollar donation from corporate sponsor X...
Score 0 again. I think a post should get a point for being replied to by one or more non-ACs. That would both reward attractive posts and deter people from pointlessly flaming (as the response would +1 the message).
..stuff about Opera...
;) I usually have to hold my tongue to keep the bad karma at bay although I'm not sure I should have to...
Well I've registered again now. I'll see how long I can keep this account out of negative karma territory.
The easiest way out for an installer is "Yes to all". But that is not the best way, for society as a whole whether or not you argue in favour of the results for the individual user (I don't).
Hmm, well, IMHO the laws you mention aren't primarily there to prevent the easy way out, but more to protect the general populace from hurting themselves and other people. I can see your reasoning though.
Exactly parallel to the smoker. Or emission controls, for that matter.
Assuming I agree that we need to legislate to remove the "easy choice", yes. I still think an alternate delivery system would be far more productive. Imagine that, rather than forcing Microsoft to unbundle their product, Microsoft were forced to devise a customization system, that allowed third party software to be easily delivered with a new install. The technology might be a few years off, and Microsoft would still benefit on the Operating System front, but it would be far more productive than forcing customers to do extra stuff.
That all sounds nice, but it seems a bit of a pipe-dream. Even if the EU or the DOJ did decide to force Microsoft to carry a competitor's product, I don't think it would achieve the goals of increasing competition. In the end all it does is lets those apps tap into the Microsoft monopoly for a time.
Think of it as a fat click-through.
Very fat. You can bet Microsoft would have a few nice "Install [unbundled app]" icons for every new install.
Odd. I'm a loud-mouthed and offensive bugger at the best of times, and that's never happened to me. What did you do to earn your slagging-down?
I'm a loud-mouthed and offensive bugger who sees a fair bit of technical merit in Microsoft's recent work, which is an occaisional recipe for disaster here.
I think you missed his point. He's not talking about hardware platform dependencies - he's talking about software dependencies on the fix. In this case, Microsoft had to patch almost their entire NT line of operating systems, and each OS would have a number of applications dependant on that code. The Apache/IIS comparison isn't the correct analogy for this.
Having said that, six months is still too long. I can see why Microsoft would take longer to fix this as compared to Apache, or some other OSS app, but six months is pushing it.
All you have found is that your box has OpenSSL for windows installed. AFAIK, ssleay32.dll not distributed by Microsoft, it's built from the OpenSLL source.