It only spreads by previewing if you haven't patched your Outlook Express in over two years. I suspect that most people's systems are already patched. In most cases, this probably spreads when somebody opens the attachment.
If so, neither is any other OS that allows you to open email attachments, since that is the main method this virus spreads. (The secondary method exploits a hole in Outlook to automatically execute the attachment, but I suspect that without user stupidity, this method wouldn't be very effective since most systems are patched.)
If everybody did that, people would start writing exploits for the new one instead. Why not just stick with Outlook Express so that we can continue to blame all of the viruses on Microsoft?
If a user is running unpatched Outlook Express, they can get the virus by previewing the email. If they are running an updated (non-vulnerable) Outlook Express or another email reader, they can STILL get the virus by running the attachment.
Exercise for the reader: Explain how this is due to Windows SUCKING. Explain how this would not happen under Linux (assuming the attachment were a Linux executable and not a Windows executable).
This particular virus exploits a hole that was fixed years ago. Until people stop running non-updated systems, this problem won't go away. You can't blame that part on Microsoft. Sure, they shouldn't have released the bug in the first place, but bugs happen. You tell me you've never missed a bug in code you thought was ok, and then I'll laugh in disbelief (unless you don't write code).
However, I'm going to guess that the majority of the infections don't even occur because of the hole. They occur because the user opens the email attachment. In that case, do we complain because Microsoft made an email program that was easy to use? Perhaps Microsoft should make their email program so that nobody is allowed to open attachments until they are MCP certified email users? You can't blame Microsoft for user stupidity. They try to warn users (Warning: this could be a virus. Do you want to open, save, or cancel?), but if they went beyond that, we would bash them for not allowing us to do what we wanted to do!
Well, there are some ways that a malformed header in an email can make the email reader do something stupid automatically, without requiring any action on the part of the user (i.e. execute the attachment). If the user has patched that problem, then they have to actively do something stupid (double click on the attachment and select "Run").
The problem with SlashDot is a lack of objectivity. A large number of people here seem to want to see Microsoft fall, and interpret any news about Microsoft as evidence of MS's impending doom or as proof of their evil ways. Umm, gee, guys -- take a reality pill, will ya? Some things MS does might be stupid and unethical, but for the most part, it acts just like any other big business. And just like any other business, it wins some and loses some.
In this case, Steve's message is simple: we just shipped Windows Server 2003, and our next big Windows release isn't for several more years. Until then, we still have to make money, and we have to improve our image. Lets do it in every way possible: fix our bugs, fix application inconsistencies, fix marketing and licensing problems, and work hard to advertise our advantages over our competition.
So a question to all those doomsayers: what is wrong with that statement? All companies have up and down times. Microsoft has just come off of two years of lotsa releases (a lot of projects got finished and released at about the same time), and now they're going to hit a few years with no major releases. Steve is charting the strategy for that span of time to make sure that during this time the company is productive.
Two additional points that I wanted to mention after reading a lot of other posts: Microsoft's "innovation" and Microsoft's "doom".
First, there is a continual accusation that Microsoft doesn't innovate, that everything done by Microsoft was done by somebody else first. To the extent that this is true, it is also true of everybody else in the industry: few software companies can actually claim to have invented the program genre that they produce. On the other hand, coming up with a good idea isn't everything -- creating a good implementation of the idea and getting it on the market is a lot of work, too, and Microsoft has done plenty of that. In addition, whatever anybody else says, Linux and related technologies are doing a heck of a lot of catch-up with Microsoft, simply implementing stuff that Windows has had from the beginning. Kernel-mode threading? Windows NT 3.1 had it, as did Windows 95. Fully re-entrant kernel? Windows NT 3.1 had it. Standard printing system? Windows 3.0 (perhaps before, I don't know). Kernel modules, loadable drivers, etc. -- NT has it. It also has COM (messy, but it works) which offers great support for component sharing and interoperability (Gnome is starting to pick up some similar stuff, and CORBA has some similar functionality, but none are heavily integrated into and supported by the OS). A developer can write an application that uses a GUI, threads, fonts, COM, etc. without having to worry about widget sets and without the user having to run "configure" to adapt the program at the source level to whatever stuff is available on the system. Sure, the sharing goes both ways, but don't knock Windows as an OS -- it has a lot of useful stuff under the hood that is still lacking in Linux and even BSD.
Now granted, not all of that stuff is necessary for every user. There is no reason to have all of that running for, say, a static web server or a database. I run my home firewall on FreeBSD, not Windows. This is forcing Microsoft to focus on more advanced features and to provide additional features and functionality for the more complicated scenarios where the extra capabilities of Windows give it an advantage -- ASP.Net, SQL Server 64-bit edition, Remote Desktop for managing the servers, etc. For application servers, complex database apps, desktops, etc., Windows still has functionality that people want that is missing from Linux. Linux will continue to create pressure for Windows to innovate as it picks up on these features, and I think that is a very good thing -- it forces Microsoft to focus on core areas that it might otherwise have ignored (reliability, security, etc.). But at this point, Windows is still way ahead on many features that are very important to me.
This is something that people don't realize: people buy Microsoft OS and Office BECAUSE of the money-losing divisions. The availability of that money-losing software makes the Windows OS a much more attractive operating system.
Quick example: if Windows Media Services didn't exist (both server-side streaming and client side player), fewer people would have reason to buy Windows.
Obviously, the code must be signed by whoever is certifying their trust in it, and other applications will trust the code if they trust the signer. Exactly how this will be implemented, I can't say. The question is whether:
* only Microsoft can sign the code * only Microsoft licensees can sign the code * anybody can sign the code
Obviously, I'm hoping for the third.
It would make sense: before handing off data to another component, you ask the system for a list of signatures that the code has been signed with. You scan the list for a signature that you recognize and trust. If the list meets your criteria, you give the requested data to the component. Everybody's happy.
For DRM: Internet site will only download music data to a trusted program. Data is encrypted in transit (transmitting encryption keys might be tricky without making them visible via debuggers &etc., but I'll leave that to the experts). The trusted program tells the file system driver that the data must be stored securely and only released to programs signed with X key. The hard disk drive might have a table of locked sectors and the key required to access them.
Obviously, this has to be thought out carefully, and a lot of thorny issues have to be addressed. But it could be a reasonably useful system, assuming it is implemented well. Of course, it will always be subject to hacking, and the DRM will always be abused by the content providers, but hopefully the market will lead to a fair system (well, I can dream, can't I?).
A friend of mine got a new phone number. For the longest time, I wondered why her new phone number struck me as strange. Finally, I decided to stop and figure it out.
XXX-1337
It took a while since the situation had nothing to do with computers, but I finally realized that some part of my mind was trying to read it as "LEET".
But the iterator is not standardized. Part of the spec is to introduce an Iterable interface, which standardizes the iterator.
Re:Sounds like what C# has that makes it better...
on
Preview of Java 1.5
·
· Score: 1
Whoops -- forgot to mention structs. Yeah, again, they provide additional stuff that isn't strictly needed. And it can confuse people who don't know when to use a class and when to use a struct. But there really is a clear line between appropriate uses of class (stored on heap) and struct (stored on stack unless boxed). For those who understand the difference, it is really nice to have both.
Re:Sounds like what C# has that makes it better...
on
Preview of Java 1.5
·
· Score: 2, Interesting
foreach isn't really redundant. It just gets used a lot when it shouldn't be used. If a type can easily be iterated-over with a standard for loop (for(i=0; i < obj.count; i++) { }) then you shouldn't use foreach. In.Net, at least, the iterator version is somewhat slower.
foreach is designed for cases where you can't simply use an index (i.e. obj[i]), such as a hash table or a linked list. In these cases, you need some kind of state for your iteration -- hence, an iterator.
While you can implement some kind of iterator without language support, language support in this case helps simplify the code. Instead of implementing the iterator yourself in your way (how many ways can this problem be solved?), you use the language-supported way. Much cleaner.
Syntactic sugar is bad when it leads to many ways to do something, but good when it simplifies the common case. I think iterators do this as long as they aren't used inappropriately.
Iterators should not be used to replace the counting case:
for(i = 0; i < count; i++) {... }
You can use iterators for this, but (depending on the implementation) it is likely to be slower, since the object in question must create an iterator instance.
Iterators should be used (in fact, are pretty much a necessity) on types that are not easily indexed, such as hash tables or linked lists. As long as the Java language doesn't have support for iterators, developers creating non-indexable container classes have to design and implement some kind of iterator themselves. With language support, the language enforces a particular design (making programs more consistent) and provides help with the implementation.
Yes, it is sugar, but it is useful sugar.
Varargs are also sugar. You could always just make the user create an array of objects as the variable parameters. But that takes a few extra lines of code for each call, and confuses the purpose of the code. You have to deal with the distraction of constructing an array instead of dealing directly with your problem.
Varargs makes a few tasks just a little bit simpler. It doesn't add any functionality, but it adds convenience.
Isn't that nice and simple? Syntactic sugar, when used appropriately, should simplify life for the programmer. In my opinion, "sugar" is appropriate if it provides a clean way to do something that would have been messy before. It should be avoided if it provides two equally good ways to do something. In the case of varargs, I think both criteria are met. In the case of iterators, the first is met, and the second is met as well as long as developers understand when iterators are appropriate and when they are not.
Skimming through the website, they appear to have a process to create an instant-on OS image that is custom-fitted to your application. As far as I can tell, it does something like this:
Analyze your application to determine which system components it needs to run properly (which DLLs, device drivers, COM components, etc.).
Create a Win98 install set up to only load the minimum necessary components.
Snap a memory image of the Win98 machine with your program loaded.
Compress this memory image onto a flash card.
At runtime, expand the memory image back into RAM and pass control back to Win98 as if nothing had happened.
There would probably have to be a few device drivers involved, but it sounds like a pretty cool idea to me. This way, you don't have to rewrite existing apps or retrain the dev team to make them work in an "embedded" environment.
Cuz they are wrong. But wrong != bad. Saying mass===weight is good enough for most people, since in their lifetime they'll probably never have any experience where it doesn't hold true, or where a more correct definition is needed. This is how we (human beings) function and make sense out of the infinitely complex world -- we try to ignore the stuff that doesn't matter. (Or to be more precise, we... waitasecond, wasn't that my whole point, that we don't always need to be more precise?)
Ditto. I can't run SETI/DNet/GoogleBar background computations during the summer -- my machine starts crashing all the time. Decent heat sink, decent fan, decent air flow as far as I can tell, but once the processor gets over 165C, all bets are off.
Slashdot Mirror
How is it bad software design to allow attachments?
If Linux were as popular as Windows, people would write more Linux worms, and the stupid users would get infected by them. So what's your point?
It only spreads by previewing if you haven't patched your Outlook Express in over two years. I suspect that most people's systems are already patched. In most cases, this probably spreads when somebody opens the attachment.
If so, neither is any other OS that allows you to open email attachments, since that is the main method this virus spreads. (The secondary method exploits a hole in Outlook to automatically execute the attachment, but I suspect that without user stupidity, this method wouldn't be very effective since most systems are patched.)
If everybody did that, people would start writing exploits for the new one instead. Why not just stick with Outlook Express so that we can continue to blame all of the viruses on Microsoft?
If a user is running unpatched Outlook Express, they can get the virus by previewing the email. If they are running an updated (non-vulnerable) Outlook Express or another email reader, they can STILL get the virus by running the attachment.
Exercise for the reader: Explain how this is due to Windows SUCKING. Explain how this would not happen under Linux (assuming the attachment were a Linux executable and not a Windows executable).
This particular virus exploits a hole that was fixed years ago. Until people stop running non-updated systems, this problem won't go away. You can't blame that part on Microsoft. Sure, they shouldn't have released the bug in the first place, but bugs happen. You tell me you've never missed a bug in code you thought was ok, and then I'll laugh in disbelief (unless you don't write code).
However, I'm going to guess that the majority of the infections don't even occur because of the hole. They occur because the user opens the email attachment. In that case, do we complain because Microsoft made an email program that was easy to use? Perhaps Microsoft should make their email program so that nobody is allowed to open attachments until they are MCP certified email users? You can't blame Microsoft for user stupidity. They try to warn users (Warning: this could be a virus. Do you want to open, save, or cancel?), but if they went beyond that, we would bash them for not allowing us to do what we wanted to do!
Well, there are some ways that a malformed header in an email can make the email reader do something stupid automatically, without requiring any action on the part of the user (i.e. execute the attachment). If the user has patched that problem, then they have to actively do something stupid (double click on the attachment and select "Run").
The problem with SlashDot is a lack of objectivity. A large number of people here seem to want to see Microsoft fall, and interpret any news about Microsoft as evidence of MS's impending doom or as proof of their evil ways. Umm, gee, guys -- take a reality pill, will ya? Some things MS does might be stupid and unethical, but for the most part, it acts just like any other big business. And just like any other business, it wins some and loses some.
In this case, Steve's message is simple: we just shipped Windows Server 2003, and our next big Windows release isn't for several more years. Until then, we still have to make money, and we have to improve our image. Lets do it in every way possible: fix our bugs, fix application inconsistencies, fix marketing and licensing problems, and work hard to advertise our advantages over our competition.
So a question to all those doomsayers: what is wrong with that statement? All companies have up and down times. Microsoft has just come off of two years of lotsa releases (a lot of projects got finished and released at about the same time), and now they're going to hit a few years with no major releases. Steve is charting the strategy for that span of time to make sure that during this time the company is productive.
Two additional points that I wanted to mention after reading a lot of other posts: Microsoft's "innovation" and Microsoft's "doom".
First, there is a continual accusation that Microsoft doesn't innovate, that everything done by Microsoft was done by somebody else first. To the extent that this is true, it is also true of everybody else in the industry: few software companies can actually claim to have invented the program genre that they produce. On the other hand, coming up with a good idea isn't everything -- creating a good implementation of the idea and getting it on the market is a lot of work, too, and Microsoft has done plenty of that. In addition, whatever anybody else says, Linux and related technologies are doing a heck of a lot of catch-up with Microsoft, simply implementing stuff that Windows has had from the beginning. Kernel-mode threading? Windows NT 3.1 had it, as did Windows 95. Fully re-entrant kernel? Windows NT 3.1 had it. Standard printing system? Windows 3.0 (perhaps before, I don't know). Kernel modules, loadable drivers, etc. -- NT has it. It also has COM (messy, but it works) which offers great support for component sharing and interoperability (Gnome is starting to pick up some similar stuff, and CORBA has some similar functionality, but none are heavily integrated into and supported by the OS). A developer can write an application that uses a GUI, threads, fonts, COM, etc. without having to worry about widget sets and without the user having to run "configure" to adapt the program at the source level to whatever stuff is available on the system. Sure, the sharing goes both ways, but don't knock Windows as an OS -- it has a lot of useful stuff under the hood that is still lacking in Linux and even BSD.
Now granted, not all of that stuff is necessary for every user. There is no reason to have all of that running for, say, a static web server or a database. I run my home firewall on FreeBSD, not Windows. This is forcing Microsoft to focus on more advanced features and to provide additional features and functionality for the more complicated scenarios where the extra capabilities of Windows give it an advantage -- ASP.Net, SQL Server 64-bit edition, Remote Desktop for managing the servers, etc. For application servers, complex database apps, desktops, etc., Windows still has functionality that people want that is missing from Linux. Linux will continue to create pressure for Windows to innovate as it picks up on these features, and I think that is a very good thing -- it forces Microsoft to focus on core areas that it might otherwise have ignored (reliability, security, etc.). But at this point, Windows is still way ahead on many features that are very important to me.
So Micro
Responding to your first suggestion:
This is something that people don't realize: people buy Microsoft OS and Office BECAUSE of the money-losing divisions. The availability of that money-losing software makes the Windows OS a much more attractive operating system.
Quick example: if Windows Media Services didn't exist (both server-side streaming and client side player), fewer people would have reason to buy Windows.
Obviously, the code must be signed by whoever is certifying their trust in it, and other applications will trust the code if they trust the signer. Exactly how this will be implemented, I can't say. The question is whether:
* only Microsoft can sign the code
* only Microsoft licensees can sign the code
* anybody can sign the code
Obviously, I'm hoping for the third.
It would make sense: before handing off data to another component, you ask the system for a list of signatures that the code has been signed with. You scan the list for a signature that you recognize and trust. If the list meets your criteria, you give the requested data to the component. Everybody's happy.
For DRM: Internet site will only download music data to a trusted program. Data is encrypted in transit (transmitting encryption keys might be tricky without making them visible via debuggers &etc., but I'll leave that to the experts). The trusted program tells the file system driver that the data must be stored securely and only released to programs signed with X key. The hard disk drive might have a table of locked sectors and the key required to access them.
Obviously, this has to be thought out carefully, and a lot of thorny issues have to be addressed. But it could be a reasonably useful system, assuming it is implemented well. Of course, it will always be subject to hacking, and the DRM will always be abused by the content providers, but hopefully the market will lead to a fair system (well, I can dream, can't I?).
Pity the areas that get assigned the lousy addresses. "My address is ISUCK ROCKS." This could lead to instant craziness in real estate.
"LINUX SUCKS" -- Small plot of land in western Oklahoma purchased by an unknown company in Redmond.
"LINUX RULEZ" -- Nearby plot of land purchased by a short guy in a tuxedo.
Because boats move, ground troops move, airplanes move, etc.
A friend of mine got a new phone number. For the longest time, I wondered why her new phone number struck me as strange. Finally, I decided to stop and figure it out.
XXX-1337
It took a while since the situation had nothing to do with computers, but I finally realized that some part of my mind was trying to read it as "LEET".
I guess it depends on the implementation and the final precise spec of the standard. If you do:
... }
void ItFunc(Iterable itAble)
{
for(Iterator it : itAble)
{
}
the compiler has no way of knowing that itAble might be an array and doesn't actually require an iterator.
But the iterator is not standardized. Part of the spec is to introduce an Iterable interface, which standardizes the iterator.
Whoops -- forgot to mention structs. Yeah, again, they provide additional stuff that isn't strictly needed. And it can confuse people who don't know when to use a class and when to use a struct. But there really is a clear line between appropriate uses of class (stored on heap) and struct (stored on stack unless boxed). For those who understand the difference, it is really nice to have both.
foreach isn't really redundant. It just gets used a lot when it shouldn't be used. If a type can easily be iterated-over with a standard for loop (for(i=0; i < obj.count; i++) { }) then you shouldn't use foreach. In .Net, at least, the iterator version is somewhat slower.
foreach is designed for cases where you can't simply use an index (i.e. obj[i]), such as a hash table or a linked list. In these cases, you need some kind of state for your iteration -- hence, an iterator.
While you can implement some kind of iterator without language support, language support in this case helps simplify the code. Instead of implementing the iterator yourself in your way (how many ways can this problem be solved?), you use the language-supported way. Much cleaner.
Syntactic sugar is bad when it leads to many ways to do something, but good when it simplifies the common case. I think iterators do this as long as they aren't used inappropriately.
Iterators should not be used to replace the counting case:
... }
for(i = 0; i < count; i++) {
You can use iterators for this, but (depending on the implementation) it is likely to be slower, since the object in question must create an iterator instance.
Iterators should be used (in fact, are pretty much a necessity) on types that are not easily indexed, such as hash tables or linked lists. As long as the Java language doesn't have support for iterators, developers creating non-indexable container classes have to design and implement some kind of iterator themselves. With language support, the language enforces a particular design (making programs more consistent) and provides help with the implementation.
Yes, it is sugar, but it is useful sugar.
Varargs are also sugar. You could always just make the user create an array of objects as the variable parameters. But that takes a few extra lines of code for each call, and confuses the purpose of the code. You have to deal with the distraction of constructing an array instead of dealing directly with your problem.
Varargs makes a few tasks just a little bit simpler. It doesn't add any functionality, but it adds convenience.
CallStoredProcedure(db, "MyStoredProcedure", param1, param2);
Isn't that nice and simple? Syntactic sugar, when used appropriately, should simplify life for the programmer. In my opinion, "sugar" is appropriate if it provides a clean way to do something that would have been messy before. It should be avoided if it provides two equally good ways to do something. In the case of varargs, I think both criteria are met. In the case of iterators, the first is met, and the second is met as well as long as developers understand when iterators are appropriate and when they are not.
There would probably have to be a few device drivers involved, but it sounds like a pretty cool idea to me. This way, you don't have to rewrite existing apps or retrain the dev team to make them work in an "embedded" environment.
Cuz they are wrong. But wrong != bad. Saying mass===weight is good enough for most people, since in their lifetime they'll probably never have any experience where it doesn't hold true, or where a more correct definition is needed. This is how we (human beings) function and make sense out of the infinitely complex world -- we try to ignore the stuff that doesn't matter. (Or to be more precise, we... waitasecond, wasn't that my whole point, that we don't always need to be more precise?)
(OT)
cmp ax, 02Eh ; ???
C'mon. If testing for equality, you should just use TEST instead!
Probably doesn't make any difference on a P4, but on earlier processors, TEST was a good bit faster than CMP...
Wouldn't that mean you could define pi as 10?
Right. Make that 65C.
Ditto. I can't run SETI/DNet/GoogleBar background computations during the summer -- my machine starts crashing all the time. Decent heat sink, decent fan, decent air flow as far as I can tell, but once the processor gets over 165C, all bets are off.
1200 MHz Athlon...