What parts were affected in the P4 box? I have so far cosidered the chance of atual hardware failure as an important difference. Maybe reliability from the chipset (Via 686B for both Intel and AMD, anyone?), but not actual failure.
So, have you any reason to really attribute this to the CPU? Rather sounds like cheap stuff overall in your work box.
And, yes, my next desktop machine will probably be a dual-core AMD, just like I might stick to Pentium M-based stuff in laptops for a while. Those are nice, while the mobile AMD offerings are continually getting nicer...
Now, just take it easy. There is no international standard on DST, so there is nothing to break. The US + Canada hasn't been synchronous with (most of) Europe before, and they won't be now. Not to mention the countries with half hour zones and whatever.
There may be quite valid reasons to dislike U.S. (foreign) policy, but this is really an internal issue. If the majority of the U.S. population suddenly decided to scrap any celebration of Christmas or any other somewhat coinciding or similar holiday, that would sure as hell affect export industries with some U.S. interest more. Just like Firefox gaining marketshare among U.S. users affect everyone, no matter where you're situated, who has been an "IE only" dumbass. You're not forced into anything. Not this time, at least.
Ditto, Atlanta first. IP address search was fine in Sweden. Just trying to search for Sweden, without caring about where I entered it, didn't produce the country at all, though... Guess I'll have to read the labels of the boxes, but a really good UI wouldn't require me to figure it out:-)
Problem is, if you fake the hardware ID, you just need a single USB device driver (not USB controller driver) with a flaw. It doesn't have to be in all of them. The flaw is to allow devices that only have been plugged in to work at all.
On the other hand, I would quite mad if I had to confirm that my new keyboard and mouse should, in fact, be used. (Catch 22, hey?) Only allow plug-and-pray of anything but a very limited set of devices (user configurable?) from anything but Administrator. That would solve most of it.
I wonder when people will start poking more at Nvidia's and ATI's OpenGL drivers on all platforms. That should prove interesting, especially since the binary drivers may actually contain the same flaws on several platforms.
And, of course, any interface that allows unrestricted DMA (PCI/Cardbus, possibly Firewire) will be impossible to guard against, no matter what OS is in use.
In addition to this, I don't see the problem in disabling the whole USB controller from an administrator account. What I wonder is if the Windows group policies for hardware setup could be used to stop this.
More like two years (December 1999 versus something like August 2001 for actual RTM). In addition, we "should" remember that the XP SP2 work was done far later, and it's actually SP2 that will be the requirement for IE7, free or not. SP2, in turn, contained some backporting from Windows Server 2003.
> How many massive Net worm infections occurred during 98's reign compared to 2000 and XP?
So, let's see, which OS had a bundled Outlook Express that could auto-execute attachments? Which one had Windows Media Player 6.4? (Which one had, *shudder* IE4?) Which one was still exposed to the upnp bug, although turning the service off was far harder as there is no uniform service management interface?
And, hell, NT4 had a huge lot of the problems later discovered in 2000 and XP services. Still, the worm problems were less severe. Isn't that enough to tell you that the far huger amount of connected computers, and script kiddies, account for the change, rather than worse security?
I wouldn't think that it would be too hard, per se. But, hey, they're MS, when a new API in the OS itself is introduced, they want to use it.
Also, as IE 7 was originally slated to be Vista/Longhorn only, and they know backport it to XP, I wonder if the backporting of Avalon (or Indigo, but Avalon should be the mest relevant here) is related. That, too, will only be available under XP SP2/2003 SP1, and if they have made the UI or rendering engine to make use of Avalon, we wouldn't talk about only a few APIs to backport, but a whole package of functionality.
Backporting Avalon, completely, to W2K, would probably be hard. There were enough changes made regarding window rendering in XP to better allow for theming and more transparency (and GDI+ and DirectX integration).
I guess we'll see in beta 1 if Avalon is required.
It's a quite common property of a patent to reference to the prior art/known technology. Then, they set out to explain what's flawed with that technology and finally how this solves it all. It's the way patents work. They may even reference other patents, from other manufacturers, just to set out how completely superior this new thing is compared to everything else.
So, the problem here is if this "invention" is really worth a patent, not that it describes status quo.
The same thing goes for any executable on any system.
True. But, why does it have to be this way? I know it would be some more work when we develop stuff, but why should every executable running under my account, by default, have full access to everything I have access to? It's hard to figure out how to make it easy enough to write code without being tempted to ask for full permissions every time, and it's hard to make it reasonably easy for the user to grasp what's shown, but I think that code-dependent security, in addition to user-dependent security, is the way. It doesn't have to be "trusted computing" shit, the difference is that you, as the (root) user, should always have the final key to decide what's run and what's not. Signing as a way to accomplish it is not too stupid. Of course, locally compiled code would possibly get different signing depending on who compiled it.
There are lots of things to iron out, but we shouldn't take the idea that every executable should be able to ask the OS to do anything. Otherwise, everyone will have to protect every system call and every file I/O path from unappropriate access, instead of granting different executables different trust from the beginning. It's not a panacea, but it's something.
Or even Tools > Manage Add-ons within IE, in XP SP2 and Windows 2003 SP1 (and up), if you want to disable something. After finding the culprit and disabling it, you can go on to acutally remove it manually if you have no tool for the job. Removing software that's been allowed to write to anything on your harddrive (probably installed through another program's setup) is not really the job of the browser, IMHO. On the other hand, IE does so many things that's not the job of the browser, so they surely could include it.
Have you looked at the size of your RAM chips any time recently? Cramming that amount of DRAM on a current CPU die area would require a whole lot of these levels.
And, no, I don't think it's obvious that the bandwidth would do that much. After all, for some applications, a 2 MB L2 brings you most of the cache goodness you can get. You'll also still need to do I/O to get some interesting stuff done.
It might help applications with really bad memory locality.
Not entirely true. With plenty of RAM and virtual memory space available, it makes more sense to do things like keeping a large memory cache, or, better up, use memory mapped files for caching. Minimizing disk I/O and CPU load may very well include higher memory usage.
Now, much is bloat, but some things that can heavily affect some ways to measure memory usage are perfectly valid practices, at least on systems that can take the load.
Slashdot Mirror
We never even launched a Voyager 6, you insensitive clod. (Anything but a Trek reference is irrelevant.)
(I would imagine that 16 bps is the raw data rate from the probe?)
So, have you any reason to really attribute this to the CPU? Rather sounds like cheap stuff overall in your work box.
And, yes, my next desktop machine will probably be a dual-core AMD, just like I might stick to Pentium M-based stuff in laptops for a while. Those are nice, while the mobile AMD offerings are continually getting nicer...
Give us your identity, and your bug, we give you the money. Sounds fair.
Insightful?! Oh, my...
There may be quite valid reasons to dislike U.S. (foreign) policy, but this is really an internal issue. If the majority of the U.S. population suddenly decided to scrap any celebration of Christmas or any other somewhat coinciding or similar holiday, that would sure as hell affect export industries with some U.S. interest more. Just like Firefox gaining marketshare among U.S. users affect everyone, no matter where you're situated, who has been an "IE only" dumbass. You're not forced into anything. Not this time, at least.
Ditto, Atlanta first. IP address search was fine in Sweden. Just trying to search for Sweden, without caring about where I entered it, didn't produce the country at all, though... Guess I'll have to read the labels of the boxes, but a really good UI wouldn't require me to figure it out :-)
On the other hand, I would quite mad if I had to confirm that my new keyboard and mouse should, in fact, be used. (Catch 22, hey?) Only allow plug-and-pray of anything but a very limited set of devices (user configurable?) from anything but Administrator. That would solve most of it.
I wonder when people will start poking more at Nvidia's and ATI's OpenGL drivers on all platforms. That should prove interesting, especially since the binary drivers may actually contain the same flaws on several platforms.
And, of course, any interface that allows unrestricted DMA (PCI/Cardbus, possibly Firewire) will be impossible to guard against, no matter what OS is in use.
In addition to this, I don't see the problem in disabling the whole USB controller from an administrator account. What I wonder is if the Windows group policies for hardware setup could be used to stop this.
XP is 5.1 and Vista is 6.0. Still, a stupid name is a stupid name, even if it's just a moniker under which you hide a more sensible version number.
Hey, what about Lynx?
Your parent said "Windows NT 3.x". Windows NT 3.1 was a very 32-bit OS. Also, "normal" Windows 3.1 could run (certain) Win32 apps under Win32s.
I only think technical beta (and warezers) could download 2195 before January 1st 2000. MSDN and the like didn't get it until early January.
More like two years (December 1999 versus something like August 2001 for actual RTM). In addition, we "should" remember that the XP SP2 work was done far later, and it's actually SP2 that will be the requirement for IE7, free or not. SP2, in turn, contained some backporting from Windows Server 2003.
So, let's see, which OS had a bundled Outlook Express that could auto-execute attachments? Which one had Windows Media Player 6.4? (Which one had, *shudder* IE4?) Which one was still exposed to the upnp bug, although turning the service off was far harder as there is no uniform service management interface?
And, hell, NT4 had a huge lot of the problems later discovered in 2000 and XP services. Still, the worm problems were less severe. Isn't that enough to tell you that the far huger amount of connected computers, and script kiddies, account for the change, rather than worse security?
Also, as IE 7 was originally slated to be Vista/Longhorn only, and they know backport it to XP, I wonder if the backporting of Avalon (or Indigo, but Avalon should be the mest relevant here) is related. That, too, will only be available under XP SP2/2003 SP1, and if they have made the UI or rendering engine to make use of Avalon, we wouldn't talk about only a few APIs to backport, but a whole package of functionality.
Backporting Avalon, completely, to W2K, would probably be hard. There were enough changes made regarding window rendering in XP to better allow for theming and more transparency (and GDI+ and DirectX integration).
I guess we'll see in beta 1 if Avalon is required.
So, the problem here is if this "invention" is really worth a patent, not that it describes status quo.
Disclaimer: I'm no American...
Unless you've got a really nice screen, less sunlight is an advantage for the /. outdoor activities...
There are lots of things to iron out, but we shouldn't take the idea that every executable should be able to ask the OS to do anything. Otherwise, everyone will have to protect every system call and every file I/O path from unappropriate access, instead of granting different executables different trust from the beginning. It's not a panacea, but it's something.
Or even Tools > Manage Add-ons within IE, in XP SP2 and Windows 2003 SP1 (and up), if you want to disable something. After finding the culprit and disabling it, you can go on to acutally remove it manually if you have no tool for the job. Removing software that's been allowed to write to anything on your harddrive (probably installed through another program's setup) is not really the job of the browser, IMHO. On the other hand, IE does so many things that's not the job of the browser, so they surely could include it.
And, no, I don't think it's obvious that the bandwidth would do that much. After all, for some applications, a 2 MB L2 brings you most of the cache goodness you can get. You'll also still need to do I/O to get some interesting stuff done.
It might help applications with really bad memory locality.
Now, much is bloat, but some things that can heavily affect some ways to measure memory usage are perfectly valid practices, at least on systems that can take the load.
It actuall RTMed in December 1999, more or less.