Addressable memory. Right now the limit is 4GB. With Windows XP, the OS sets 2GB aside for the OS, so apps only get 2GB, and that's shared across all the apps.
Then stop using an operating system with a serious design flaw.
The limit imposed by the Intel processor hardware is 16Gb - if XP is not allowing you to use that much memory, then a new version needs to be released that does.
2Gb per process limit indicates a design hack in the operating system that is ridiculous. It is easily possible for a competent OS to be designed that allows a per process address space of very nearly 4Gb. My linux system will allow a process to have 3.5Gb of address space.
HP OpenMail is able to support all of the features of Outlook, and is used by many large corporations who do not want to use the expensive resource hog which is Exchange.
I've heard recently of a product called 'OpenExchange'. Details are here, although I haven't read them thoroughly, it seems to do the job:
http://www.suse.com/us/business/products/suse_bu si ness/openexchange/index.html
Well, if we really want to pay attention to history, there is NOT a lot of room for RAM to grow. There is only a 4 - 16X growth capacity here. Just a few short years ago, 32M was a lot of memory, and was the typical amount sold on a new PC. I'd hate to see some funky expanded memory crap like we had back in the 640K barrier days. The days of 4G machines are NOT far off.
Note that most standard PC's can't handle the full 4G anyway due to video and other expansion cards snarfing larger and larger chunks of the address space.
The 4Gb address space was broken by the pentium. The current maximum addressable space is 16Gb. Beyond that, RAM can be used as an ultra-fast paging device that is accessed as if it was an external device (kind of like EMS memory from the old DOS days).
I think it'll easily be 2007 before mainstream PC users need to break the limitations that this imposes.
My expectation for average user memory ranges are:
2004: 256Mb-1Gb 2005/06: 512Mb-2Gb 2007: 1Gb-4Gb
So it'll be a while yet before people are even worrying about the 16Gb limit for desktop use.
Servers, on the other hand, are a different question. 16Gb on a server is already a reasonable amount of memory. That will probably be broken before the 2007 limit mentioned in the text above.
Possibility 1 is possible, but very difficult. The administration involved in setting up a scheme like this without creating thousands of open relays is tricky, and would probably drive up the cost of web hosting by about 50%, but it could be done.
Possibility 2 has already been addressed in another comment - I agree with the conclusion drawn there.
Let me see if I understand your concern: currently if I host a web site at mywebsite.com, I want a From: me@mywebsite.com to appear in my outgoing emails. If I'm using a dialup ISP for net connectivity, I am using their outgoing mailer (e.g. smtp.myISP.com). If forged source addresses were no longer permitted, I would have to send my email using From: me@smtp.myISP.com. Currently I can just put me@mywebsite.com into my "From:" field by filling in a configuration box on my email software and it works fine.
Yep, that's pretty much the capability I'd worry about losing if a 'from' forging prevention policy was put into place.
One method is especially interesting, the CPU-based scheme [microsoft.com] in which "the sender must solve a recipient-defined puzzle in which computation of the solution is moderately and provably hard." If that were the case you wouldn't even notice if you're sending one email, but a spammer certainly would if he tries to send out 1,000,000 at a time.
What about legitimate uses of sending out many e-mails at a time? How would a popular mailing list cope with this?
Stopping open relays doesn't prevent forged source addresses.
The fact is, that it is impossible to prevent forged source addresses without limiting a number of very useful features of our e-mail network as it stands at the moment. One of which is that I can send an e-mail that appears to be 'from' an address which isn't hosted by my ISP, but is in actual fact forwarded to my ISP account by my web host.
If it wasn't for this ability, everyone would have to use their dialup ISP to provide their web hosting for them (or vice versa). Or have two separate domains, one for their web site and one for their e-mail address. This just couldn't work.
No, it isn't. There was a new 32 bit implementation of the filesystem. It isn't clear that this is what was meant, but it isn't wrong either.
The question is, what makes a file system 32 bit? For instance, is Linux's implementation of the DOS file system 32 bit? How about ext2?
I think associating 'FAT32' with '32 bit filesystem' is an incorrect association. OK, FAT32's primary distinguishing feature from previous DOS FSs is that entries in the File Allocation Table can be 32 bits wide. But there are plenty of other fields in the file system that always have been 32 bits wide (eg the file size, the starting cluster number, etc). In this fashion, FAT16 is a 32 bit filesystem also. Clearly arguing from this perspective is therefore ridiculous...
I think whether the code implementing the filesystem is 16 or 32 bit code is a much more important distinction. It certainly has more to do with performance considerations, which is what is being talked about here, as a FAT16 file system will actually perform faster than a FAT32 one in many ways (because less FAT data has to be read in order to read any particular file).
Generally, I think the problem here is that the entire article is badly written. I suspect that the original author is not a native English speaker, or maybe did not think very much about the words he was actually writing.
Namely that versions of Windows before Win95 didn't fully support the 386
Win 3 supported every feature of the 386 processor. It could run 32 bit code (although most of the code was 16 bit for compatibility). It could run DOS programs in V86 mode. It supported 4Gb of RAM. That's pretty much every 386 feature accounted for.
despite what the article claims, still had worthless (and error-prone) cooperative multi-tasking
The article claims that DOS tasks where pre-emptively multitasked. This is correct. I thought it was true for 2.0/386 as well, though, but I'm not certain, having never actually used that (I only ever used 2.0 on a 186).
nor did they have anything resembling a 32-bit filesystem.
Win3.1 came with a 32 bit filesystem driver. That is, the driver executed as 32 bit code without thunking to DOS. The articles text is ambiguous, and may cause you to think of FAT32, but it does clearly state later that FAT32 was introduced with Win95 OSR2.
A quick check of the MySQL.com web site suggests that several members of the 3.23 series were 'stable' releases, in particular 3.23.32 was a stable release that supported transactions, and is over 2 years old now.
Erm... they've had transactions for quite a while now, actually. Not sure which version they were introduced in, but I've got 3.23.43 on my system here, and that definitely supports transactions.
And according to the file datestamps, that was installed in October 2001.
Damn. You just prompted me to look at the manual for this release and I'm disappointed now. Last I heard, subselects were going to be included in 4.0. It looks as though they've been put back to 4.1 (although it seems as though they're already available in the 4.1 betas). Although you can have UNIONs now by the looks of things. They also have a feature described as 'multi table deletes'. Not sure if this is cascaded deletes or something else, but it might be of use to you... Stored procedures are apparently scheduled for 5.0.
Well, first of all, you'd probably need to upgrade your memory to be faster as well, or you wouldn't notice a thing.
But, once you've done that, memory access times will drop substantially for those cache misses, which means about 5% of instructions will execute about 20% faster, so you'll see about a 4% improvement in speed, more or less, depending on how much memory access and IO your application performs.
This in spite of the fact that unless you're compiling software, searching for extra-terrestrial life, or playing crack-the-encryption, you don't need 1+ GHz.
What you need is what AMD is offering - more speed on the bus. Depending on what you run, more ram. And everyone could use a faster hard drive...Even those who compile software will usually see better results from increasing bus speed + hard disk speed.
Actually, compiling software will probably benefit more than most because with a modern processor it is I/O bound (I rarely get to above 50% processor usage when compiling these days, although admittedly I do tend to compile files off a network filesystem).
There are two things the masses do with processor power these days:
- play 3d games which are getting ever more processor hungry... - mess around with digital video, which is becoming a more & more common thing to do.
Both of these will probably benefit from higher CPU core speeds as much as they will from improved bus speeds. At least until memory speed catches up...
In what way does this open up data belonging to other clients to risk? All that it means is that if a hacker gained access to the server they would be able to log in to various web sites (i.e. those where the client has insisted on recoverable passwords) and masquerade as other legitimate users of the site. They wouldn't gain access to any data that they couldn't already get (because by implication they have access to the database on which the passwords are stored, which is the same database as all of the other personally sensitive information), and in no way would it grant further access to any of the other client information on the system. I fail to see where the costs are in this situation.
The client often demands for users to be able to 'recover' passwords without changing them, so there's not an awful lot we can do about it, in many cases. Of course, whenever this feature isn't requested passwords are encrypted.
Have you actually looked at the MS P2P app? Come on, that conquer anything? You gotta be joking. Its basically MSN messenger for groups with all the bells and whistles. It allows you to push files to people who you've invited to connect to you. I don't see it going very far...
Slashdot Mirror
Addressable memory. Right now the limit is 4GB. With Windows XP, the OS sets 2GB aside for the OS, so apps only get 2GB, and that's shared across all the apps.
Then stop using an operating system with a serious design flaw.
The limit imposed by the Intel processor hardware is 16Gb - if XP is not allowing you to use that much memory, then a new version needs to be released that does.
2Gb per process limit indicates a design hack in the operating system that is ridiculous. It is easily possible for a competent OS to be designed that allows a per process address space of very nearly 4Gb. My linux system will allow a process to have 3.5Gb of address space.
Because it isn't true.
u si ness/openexchange/index.html
HP OpenMail is able to support all of the features of Outlook, and is used by many large corporations who do not want to use the expensive resource hog which is Exchange.
I've heard recently of a product called 'OpenExchange'. Details are here, although I haven't read them thoroughly, it seems to do the job:
http://www.suse.com/us/business/products/suse_b
Well, if we really want to pay attention to history, there is NOT a lot of room for RAM to grow. There is only a 4 - 16X growth capacity here. Just a few short years ago, 32M was a lot of memory, and was the typical amount sold on a new PC. I'd hate to see some funky expanded memory crap like we had back in the 640K barrier days. The days of 4G machines are NOT far off.
Note that most standard PC's can't handle the full 4G anyway due to video and other expansion cards snarfing larger and larger chunks of the address space.
The 4Gb address space was broken by the pentium. The current maximum addressable space is 16Gb. Beyond that, RAM can be used as an ultra-fast paging device that is accessed as if it was an external device (kind of like EMS memory from the old DOS days).
I think it'll easily be 2007 before mainstream PC users need to break the limitations that this imposes.
My expectation for average user memory ranges are:
2004: 256Mb-1Gb
2005/06: 512Mb-2Gb
2007: 1Gb-4Gb
So it'll be a while yet before people are even worrying about the 16Gb limit for desktop use.
Servers, on the other hand, are a different question. 16Gb on a server is already a reasonable amount of memory. That will probably be broken before the 2007 limit mentioned in the text above.
Possibility 1 is possible, but very difficult. The administration involved in setting up a scheme like this without creating thousands of open relays is tricky, and would probably drive up the cost of web hosting by about 50%, but it could be done.
Possibility 2 has already been addressed in another comment - I agree with the conclusion drawn there.
Let me see if I understand your concern: currently if I host a web site at mywebsite.com, I want a From: me@mywebsite.com to appear in my outgoing emails. If I'm using a dialup ISP for net connectivity, I am using their outgoing mailer (e.g. smtp.myISP.com). If forged source addresses were no longer permitted, I would have to send my email using From: me@smtp.myISP.com. Currently I can just put me@mywebsite.com into my "From:" field by filling in a configuration box on my email software and it works fine.
Yep, that's pretty much the capability I'd worry about losing if a 'from' forging prevention policy was put into place.
One method is especially interesting, the CPU-based scheme [microsoft.com] in which "the sender must solve a recipient-defined puzzle in which computation of the solution is moderately and provably hard." If that were the case you wouldn't even notice if you're sending one email, but a spammer certainly would if he tries to send out 1,000,000 at a time.
What about legitimate uses of sending out many e-mails at a time? How would a popular mailing list cope with this?
Stopping open relays doesn't prevent forged source addresses.
The fact is, that it is impossible to prevent forged source addresses without limiting a number of very useful features of our e-mail network as it stands at the moment. One of which is that I can send an e-mail that appears to be 'from' an address which isn't hosted by my ISP, but is in actual fact forwarded to my ISP account by my web host.
If it wasn't for this ability, everyone would have to use their dialup ISP to provide their web hosting for them (or vice versa). Or have two separate domains, one for their web site and one for their e-mail address. This just couldn't work.
very often people who end up with poor credit do so because they are unable to properly manage their fiances.
Yeah. I had a friend who had that problem. She dumped him in the end...
No, it isn't. There was a new 32 bit implementation of the filesystem. It isn't clear that this is what was meant, but it isn't wrong either.
The question is, what makes a file system 32 bit? For instance, is Linux's implementation of the DOS file system 32 bit? How about ext2?
I think associating 'FAT32' with '32 bit filesystem' is an incorrect association. OK, FAT32's primary distinguishing feature from previous DOS FSs is that entries in the File Allocation Table can be 32 bits wide. But there are plenty of other fields in the file system that always have been 32 bits wide (eg the file size, the starting cluster number, etc). In this fashion, FAT16 is a 32 bit filesystem also. Clearly arguing from this perspective is therefore ridiculous...
I think whether the code implementing the filesystem is 16 or 32 bit code is a much more important distinction. It certainly has more to do with performance considerations, which is what is being talked about here, as a FAT16 file system will actually perform faster than a FAT32 one in many ways (because less FAT data has to be read in order to read any particular file).
Generally, I think the problem here is that the entire article is badly written. I suspect that the original author is not a native English speaker, or maybe did not think very much about the words he was actually writing.
Who modded this as informative?
Namely that versions of Windows before Win95 didn't fully support the 386
Win 3 supported every feature of the 386 processor. It could run 32 bit code (although most of the code was 16 bit for compatibility). It could run DOS programs in V86 mode. It supported 4Gb of RAM. That's pretty much every 386 feature accounted for.
despite what the article claims, still had worthless (and error-prone) cooperative multi-tasking
The article claims that DOS tasks where pre-emptively multitasked. This is correct. I thought it was true for 2.0/386 as well, though, but I'm not certain, having never actually used that (I only ever used 2.0 on a 186).
nor did they have anything resembling a 32-bit filesystem.
Win3.1 came with a 32 bit filesystem driver. That is, the driver executed as 32 bit code without thunking to DOS. The articles text is ambiguous, and may cause you to think of FAT32, but it does clearly state later that FAT32 was introduced with Win95 OSR2.
A quick check of the MySQL.com web site suggests that several members of the 3.23 series were 'stable' releases, in particular 3.23.32 was a stable release that supported transactions, and is over 2 years old now.
Erm... they've had transactions for quite a while now, actually. Not sure which version they were introduced in, but I've got 3.23.43 on my system here, and that definitely supports transactions.
And according to the file datestamps, that was installed in October 2001.
Damn. You just prompted me to look at the manual for this release and I'm disappointed now. Last I heard, subselects were going to be included in 4.0. It looks as though they've been put back to 4.1 (although it seems as though they're already available in the 4.1 betas). Although you can have UNIONs now by the looks of things. They also have a feature described as 'multi table deletes'. Not sure if this is cascaded deletes or something else, but it might be of use to you... Stored procedures are apparently scheduled for 5.0.
But for some reason people ignore it. Is it because it is created by a company and not a group ?
Errr... MySQL was written by a company as well. TCX DataKonsulter AB are the company of IT consultants who originally wrote MySQL.
...from the old BBC Model B with "*SAY Whatever you like", which got it right about 95% of the time?
Not all that for, considering its been nearly 20 years, to be honest.
Of course a lot of people are still using Mosaic, at least in some sense. Internet Explorer is derived from it (look at the text in the about box).
Doh!
Well, first of all, you'd probably need to upgrade your memory to be faster as well, or you wouldn't notice a thing.
But, once you've done that, memory access times will drop substantially for those cache misses, which means about 5% of instructions will execute about 20% faster, so you'll see about a 4% improvement in speed, more or less, depending on how much memory access and IO your application performs.
I think. Somebody flame me if I'm wrong here...
This in spite of the fact that unless you're compiling software, searching for extra-terrestrial life, or playing crack-the-encryption, you don't need 1+ GHz.
What you need is what AMD is offering - more speed on the bus. Depending on what you run, more ram. And everyone could use a faster hard drive.
Actually, compiling software will probably benefit more than most because with a modern processor it is I/O bound (I rarely get to above 50% processor usage when compiling these days, although admittedly I do tend to compile files off a network filesystem).
There are two things the masses do with processor power these days:
- play 3d games which are getting ever more processor hungry...
- mess around with digital video, which is becoming a more & more common thing to do.
Both of these will probably benefit from higher CPU core speeds as much as they will from improved bus speeds. At least until memory speed catches up...
In what way does this open up data belonging to other clients to risk? All that it means is that if a hacker gained access to the server they would be able to log in to various web sites (i.e. those where the client has insisted on recoverable passwords) and masquerade as other legitimate users of the site. They wouldn't gain access to any data that they couldn't already get (because by implication they have access to the database on which the passwords are stored, which is the same database as all of the other personally sensitive information), and in no way would it grant further access to any of the other client information on the system. I fail to see where the costs are in this situation.
"The client is always right" (management).
The client often demands for users to be able to 'recover' passwords without changing them, so there's not an awful lot we can do about it, in many cases. Of course, whenever this feature isn't requested passwords are encrypted.
Nothing to stop you burning a CD
This is Roxio. Of course there won't be. They want it as a way to sell more copies of Easy CD....
I just asked myself "is that the episode where..." and found out, yes it was.
e p3 4
So as not to post a spoiler here, here's a link to a synopsis of the story...
http://www.tvtome.com/OuterLimits/season2.html#
Have you actually looked at the MS P2P app? Come on, that conquer anything? You gotta be joking. Its basically MSN messenger for groups with all the bells and whistles. It allows you to push files to people who you've invited to connect to you. I don't see it going very far...