Well, I don't know if it actually works or not, since I'm not sure how to test it... but Mozilla has a "Log Out" option, under "Tasks, Privacy and Security, Password Manager".
I guess it's biting and insightful then, because Netscape6/Mozilla have better support for the basic W3C standards (HTML, CSS, DOM) than WinIE. Check out www.richinstyle.com or some other independent site if you don't believe it.
Having Linux be the most popular free OS kernel and under the GPL is good for everyone, including the BSDs. It's insurance that control of the free OS world won't be captured by some corporation(s). It strongly encourages hardware vendors to make driver source code available. (You may not want to use GPL'ed driver code in *BSD directly, but it's still better to have that to look at than nothing at all...) And the popularity of Linux has driven the development of lots of userland software that, naturally, also runs on *BSD.
Don't wish Linux dead. It's the best thing that ever happened to *BSD.
> I've yet to see any specific standard for HTML
> email.
Then reread the MIME RFCs.
> do you send it as an attachment? as the message?
> with the plain text version of message?
MIME allows all three. Sending your intended message body as an attachment would be confusing and I don't know why you'd want to do that. That leaves you with the choice of whether you want to send HTML only, or whether you want to send in both formats and let the recipient choose. For the former, you use "Content-Type: text/html" for the message body, and for the latter you use "Content-Type: multipart/alternative" with "text/html" and "text/plain" subparts.
> even two html-award email clients may view HTML
> differently
This is a feature. The HTML should be rendered according to the recipient's preferences. This is actually a great feature of HTML --- I'm sick of reading email wrapped to the sender's screen width instead of my screen width.
> If you have to send something else besides text,
> MIME attachments are the right and RFC'd way to
> go.
You seem to be unaware that MIME lets you choose types for the body of the message too, including options such as "multipart/alternative" that let you provide the same content in different formats. Better reread the RFCs.
The DOM APIs are not "totally nonstandardized". In fact they have been standardized by the W3C. The APIs supported by Mozilla/Netscape6 are basicallly just a little less and a little more than W3C DOM2. Konqueror is catching up fast. Opera is lagging behind a bit but is basically on the same path.
Only Microsoft, and WinIE in particular, are deliberately avoiding proper support for the standard DOM. But the subset of the W3C DOM that works in IE 5.5 is actually quite large and very useful.
That's a rather tough assessment of Javascript. It certainly has its flaws, but on the other hand, it has made a lot of interactive Web-based applications possible that wouldn't have been doable otherwise.
Javascript has been standardised by ECMA for some time. There have been many security issues, but it's not clear that alternative technologies for doing the same things would have been safer.
> What is being done to repeal the DMCA? Are there
> technology-savvy lawyers out fighting battles
> for us, and if not, are any reading this
> message?
Yes. The Eric Corley/2600/DeCSS case has the potential to overturn a lot of the most objectionable parts of the DMCA. There were stories about it on Slashdot over the last week.
I think you're right. The mail client should be configurable not just to ignore Javascript in HTML email, but actually strip it out completely before forwarding/replying/etc.
The RFCs do NOT say to "stick to plain text for all messages". There are a number of MIME RFCs that are explicitly designed to make it possible to send anything you want in email.
HTML email may or may not be a good idea, but don't try invoking the RFCs to stamp it out, because they're not on your side.
There is XHTML Basic, which is a little subset of XHTML suitable for text messaging. I haven't checked to see if it includes inline images or scripting.
Watermarks can be removed by point-and-click tools.
There's also the likelihood that someone will design another point-and-click tool that disables the D"R"M in your average user's system, even if just to restore the fair use rights that have been stolen from us.
> Of course, clever intelligent people will be
> able to hack it. But the question is whether
> your average Joe Punter is going to.
All it takes is one clever, intelligent person writing a little tool that does the hack and making it available for Joe Punters everywhere to download (somewhere out of the reach of the DMCA).
The "economic argument" just doesn't hold up in a world where everything can be automated.
Others have pointed out that most of the things on this list are already covered by Java. The ideas of compiling to native code, of having a decent code security model, and of providing cross-platform execution, are not new and your impression that they somehow give.NET an advantage over Java is laughable.
> Cross-platform. Let's just say that more than
> Win32, MacOS, and WinCE are on the roadmap for
> the Common Language Runtime. More will be
> revealed with this in time.
A cross-platform implementation of the CLR is irrelevant. What matters is ports of the.NET Framework. CLR ports are good for PR but nothing more.
> IIS/ASP.NET will monitor all the processes and
> components... if there is a memory or resource
> leak detected (or a timer expires), it will
> spawn a new process and start funneling all new
> sessions to that process... when the last
> session to the old process closes, it will be
> terminated and the resources reclaimed.
Hey, sounds just like Apache! Nice catch-up play there, guys.
> With desktop apps, an x-copy will actually
> suffice as the install routine.
This is exactly the same language I heard a Microsoft manager use in his presentation. Either you are one or you've thoroughly imbibed their view of the world.
> While the Java VM is not firmly tied to the Java
> language, it's a much stronger coupling than any
> other language, whereas the CLR is designed to be
> language-neutral
Yeah, the CLR is language-neutral as long as your language looks like C#. That's why they had to take multiple inheritance out of Eiffel to make Eiffel#.
> The security systems in.NET are a lot more than
> just a sandbox....
So is Java's.
> you really should read up on how it all works.
So should you about Java.
> there is no sense in just having all or
> nothing, ala Java's method.
Java's security model includes a rich vocabulary of principals, permissions and access controls. Perhaps you're confusing Java with ActiveX?
> because of the way the security system works,
> the runtime will prevent the trusted library
> from doing anything disallowed on behalf of the
> untrusted program....
In other words, it does stack crawling to detect untrusted principals responsible for initiating a request. Guess what, the JVM provides this too.
> That is why Microsoft will win: IT managers want
> to cut a single check and get everything they
> need to make the whole system work in one box.
IT managers are getting sick of watching the size of that check increase every year, and getting a solution that is designed to ensure they will never be able to switch to another vendor.
I asked the ASP.NET product manager whether there will be non-Microsoft implementations of.NET. He carefully answered that they expect other implementations of *CLR*.
The difference here is crucial. The CLR of the late 20th century was x86 machine code, which Microsoft never owned. Microsoft's lock has always been in the APIs, which used to be Windows and will be the.NET Framework. It's much harder to clone the API implementation than the VM, because it takes much more code to implement a big set of APIs (and the API implementation is harder to port).
So what's the point of "opening" the CLR definition without "opening" the.NET API? That depends on what you mean by "opening". Certainly the.NET API will be *documented* and therefore cloneable. (Although so is Windows, and that doesn't make it an easy task.)
The issue is really who will control the evolution of the CLR and the.NET API. It's not yet clear whether Microsoft's submission of CLR specs to standards bodies actually implies that they'll hand over control of future directions to those standards bodies (or that they'll follow those directions even if they do hand over "control"... look at the W3C). But I'll be very surprised if they even pretend to hand over control of the.NET API.
Assuming they do not, then we'll continue to see the "API of the month club"/"Keep the competition on a treadmill" strategy in action. Microsoft will frequently release new library interfaces, declare them part of.NET, and use a variety of means to make.NET-related products depend on them. Other would-be implementors of.NET won't even hear about these interfaces until the Microsoft implementations are already shipping and third party developers are already depending on those implementations' bugs.
> Anyone care to enlighten me as to what is really
> involved here ?
Sure. What you're talking about is impossible.
You assume that software is inherently fully paralellizable, and that's very far from the truth. A huge amount of work has been done on automatic parallelisation, and the results are not very promising. Automatic parallelisation is difficult to implement, takes a lot of computation, and in the end it only works for certain kinds of programs (programs which are dominated by loops with predictable structure).
Many programs are inherently serial and cannot be parallelised. Automatic parallelisation also tends to rely on static analysis, which is basically impossible to do at the level of binary machine code.
The Stanford Hydra processor does a form of automatic parallelisation of binary code using thread-level data speculation, but there's plenty of evidence that the speedups are not that great without support from the compiler.
If your hardware supported thread-level data speculation (none does at present), then I could believe that code morphing might be able to produce significant speedups using parallelisation, but the code morphing process would be much slower and the speedups would be much less than proportional to the number of processors.
I don't have a reference, I just remember people talking about it while I was at DEC. Maybe it turned out not to be significant.
However, it does seem logical to me that it could be a problem. Imagine you have two SMT threads, one which wants lots of physical registers and one which wants only a few. You'd have to tie up a bunch of physical registers to back up all the logical registers for the second thread, even though they're not really needed. How much more elegant to have the compiler insert instructions to say "I'm not going to need the value in this register".
Slashdot Mirror
Well, I don't know if it actually works or not, since I'm not sure how to test it ... but Mozilla has a "Log Out" option, under "Tasks, Privacy and Security, Password Manager".
I guess it's biting and insightful then, because Netscape6/Mozilla have better support for the basic W3C standards (HTML, CSS, DOM) than WinIE. Check out www.richinstyle.com or some other independent site if you don't believe it.
Having Linux be the most popular free OS kernel and under the GPL is good for everyone, including the BSDs. It's insurance that control of the free OS world won't be captured by some corporation(s). It strongly encourages hardware vendors to make driver source code available. (You may not want to use GPL'ed driver code in *BSD directly, but it's still better to have that to look at than nothing at all...) And the popularity of Linux has driven the development of lots of userland software that, naturally, also runs on *BSD.
Don't wish Linux dead. It's the best thing that ever happened to *BSD.
MIME is not just about attachments.
> I've yet to see any specific standard for HTML
> email.
Then reread the MIME RFCs.
> do you send it as an attachment? as the message?
> with the plain text version of message?
MIME allows all three. Sending your intended message body as an attachment would be confusing and I don't know why you'd want to do that. That leaves you with the choice of whether you want to send HTML only, or whether you want to send in both formats and let the recipient choose. For the former, you use "Content-Type: text/html" for the message body, and for the latter you use "Content-Type: multipart/alternative" with "text/html" and "text/plain" subparts.
> even two html-award email clients may view HTML
> differently
This is a feature. The HTML should be rendered according to the recipient's preferences. This is actually a great feature of HTML --- I'm sick of reading email wrapped to the sender's screen width instead of my screen width.
> If you have to send something else besides text,
> MIME attachments are the right and RFC'd way to
> go.
You seem to be unaware that MIME lets you choose types for the body of the message too, including options such as "multipart/alternative" that let you provide the same content in different formats. Better reread the RFCs.
It was the marketers. The engineers originally called it Livescript but the marketers wanted to capitalize on the Java hype.
The DOM APIs are not "totally nonstandardized". In fact they have been standardized by the W3C. The APIs supported by Mozilla/Netscape6 are basicallly just a little less and a little more than W3C DOM2. Konqueror is catching up fast. Opera is lagging behind a bit but is basically on the same path.
Only Microsoft, and WinIE in particular, are deliberately avoiding proper support for the standard DOM. But the subset of the W3C DOM that works in IE 5.5 is actually quite large and very useful.
That's a rather tough assessment of Javascript. It certainly has its flaws, but on the other hand, it has made a lot of interactive Web-based applications possible that wouldn't have been doable otherwise.
Javascript has been standardised by ECMA for some time. There have been many security issues, but it's not clear that alternative technologies for doing the same things would have been safer.
> What is being done to repeal the DMCA? Are there
> technology-savvy lawyers out fighting battles
> for us, and if not, are any reading this
> message?
Yes. The Eric Corley/2600/DeCSS case has the potential to overturn a lot of the most objectionable parts of the DMCA. There were stories about it on Slashdot over the last week.
I think you're right. The mail client should be configurable not just to ignore Javascript in HTML email, but actually strip it out completely before forwarding/replying/etc.
Someone should hack this into Mozilla right away.
The RFCs do NOT say to "stick to plain text for all messages". There are a number of MIME RFCs that are explicitly designed to make it possible to send anything you want in email.
HTML email may or may not be a good idea, but don't try invoking the RFCs to stamp it out, because they're not on your side.
There is XHTML Basic, which is a little subset of XHTML suitable for text messaging. I haven't checked to see if it includes inline images or scripting.
Watermarks can be removed by point-and-click tools.
There's also the likelihood that someone will design another point-and-click tool that disables the D"R"M in your average user's system, even if just to restore the fair use rights that have been stolen from us.
> Of course, clever intelligent people will be
> able to hack it. But the question is whether
> your average Joe Punter is going to.
All it takes is one clever, intelligent person writing a little tool that does the hack and making it available for Joe Punters everywhere to download (somewhere out of the reach of the DMCA).
The "economic argument" just doesn't hold up in a world where everything can be automated.
Every Web browser has multiple protocol handlers (ftp, http) and multiple content handlers (HTML, plain text). This patent doesn't sound narrow.
Check out Mozilla XUL. Based on XML/CSS, but provides everything you need to build a real application UI.
Others have pointed out that most of the things on this list are already covered by Java. The ideas of compiling to native code, of having a decent code security model, and of providing cross-platform execution, are not new and your impression that they somehow give .NET an advantage over Java is laughable.
.NET Framework. CLR ports are good for PR but nothing more.
> Cross-platform. Let's just say that more than
> Win32, MacOS, and WinCE are on the roadmap for
> the Common Language Runtime. More will be
> revealed with this in time.
A cross-platform implementation of the CLR is irrelevant. What matters is ports of the
> IIS/ASP.NET will monitor all the processes and
> components... if there is a memory or resource
> leak detected (or a timer expires), it will
> spawn a new process and start funneling all new
> sessions to that process... when the last
> session to the old process closes, it will be
> terminated and the resources reclaimed.
Hey, sounds just like Apache! Nice catch-up play there, guys.
> With desktop apps, an x-copy will actually
> suffice as the install routine.
This is exactly the same language I heard a Microsoft manager use in his presentation. Either you are one or you've thoroughly imbibed their view of the world.
> While the Java VM is not firmly tied to the Java
> language, it's a much stronger coupling than any
> other language, whereas the CLR is designed to be
> language-neutral
Yeah, the CLR is language-neutral as long as your language looks like C#. That's why they had to take multiple inheritance out of Eiffel to make Eiffel#.
> The security systems in .NET are a lot more than
> just a sandbox....
So is Java's.
> you really should read up on how it all works.
So should you about Java.
> there is no sense in just having all or
> nothing, ala Java's method.
Java's security model includes a rich vocabulary of principals, permissions and access controls. Perhaps you're confusing Java with ActiveX?
> because of the way the security system works,
> the runtime will prevent the trusted library
> from doing anything disallowed on behalf of the
> untrusted program....
In other words, it does stack crawling to detect untrusted principals responsible for initiating a request. Guess what, the JVM provides this too.
> That is why Microsoft will win: IT managers want
> to cut a single check and get everything they
> need to make the whole system work in one box.
IT managers are getting sick of watching the size of that check increase every year, and getting a solution that is designed to ensure they will never be able to switch to another vendor.
I asked the ASP.NET product manager whether there will be non-Microsoft implementations of .NET. He carefully answered that they expect other implementations of *CLR*.
.NET Framework. It's much harder to clone the API implementation than the VM, because it takes much more code to implement a big set of APIs (and the API implementation is harder to port).
.NET API? That depends on what you mean by "opening". Certainly the .NET API will be *documented* and therefore cloneable. (Although so is Windows, and that doesn't make it an easy task.)
.NET API. It's not yet clear whether Microsoft's submission of CLR specs to standards bodies actually implies that they'll hand over control of future directions to those standards bodies (or that they'll follow those directions even if they do hand over "control" ... look at the W3C). But I'll be very surprised if they even pretend to hand over control of the .NET API.
.NET, and use a variety of means to make .NET-related products depend on them. Other would-be implementors of .NET won't even hear about these interfaces until the Microsoft implementations are already shipping and third party developers are already depending on those implementations' bugs.
The difference here is crucial. The CLR of the late 20th century was x86 machine code, which Microsoft never owned. Microsoft's lock has always been in the APIs, which used to be Windows and will be the
So what's the point of "opening" the CLR definition without "opening" the
The issue is really who will control the evolution of the CLR and the
Assuming they do not, then we'll continue to see the "API of the month club"/"Keep the competition on a treadmill" strategy in action. Microsoft will frequently release new library interfaces, declare them part of
> Anyone care to enlighten me as to what is really
> involved here ?
Sure. What you're talking about is impossible.
You assume that software is inherently fully paralellizable, and that's very far from the truth. A huge amount of work has been done on automatic parallelisation, and the results are not very promising. Automatic parallelisation is difficult to implement, takes a lot of computation, and in the end it only works for certain kinds of programs (programs which are dominated by loops with predictable structure).
Many programs are inherently serial and cannot be parallelised. Automatic parallelisation also tends to rely on static analysis, which is basically impossible to do at the level of binary machine code.
The Stanford Hydra processor does a form of automatic parallelisation of binary code using thread-level data speculation, but there's plenty of evidence that the speedups are not that great without support from the compiler.
If your hardware supported thread-level data speculation (none does at present), then I could believe that code morphing might be able to produce significant speedups using parallelisation, but the code morphing process would be much slower and the speedups would be much less than proportional to the number of processors.
Ah, there's a reference below.
Maybe it suffices to just build a gigantic register file, but I got the impression that was harder than you seem to think it is.
I don't have a reference, I just remember people talking about it while I was at DEC. Maybe it turned out not to be significant.
However, it does seem logical to me that it could be a problem. Imagine you have two SMT threads, one which wants lots of physical registers and one which wants only a few. You'd have to tie up a bunch of physical registers to back up all the logical registers for the second thread, even though they're not really needed. How much more elegant to have the compiler insert instructions to say "I'm not going to need the value in this register".
colohan@cs.cmu.edu :-)
He interned at IBM and is working on speculative multithreading with Todd Mowry.
The point is that making OS-level context switches faster is not the goal of SMT.
PS, I was an intern at DEC SRC while Eggers was there on sabbatical helping design the EV8.