You can change the location of the cache dir by setting the browser.cache.disk.parent_directory preference in about:config.
I've used a modification of the createprofile.vbs script from FFDeploy to set this up as new profiles are created from a login script.
I actually ended up creating my own msi files using a combination of regmon and filemon from Sysinternals to map it out, and Advanced Installer (the free version) to build the package. I ended up with a package that I can push out that includes flash and shockwave as well as a default profile with adblock included. I then use my version of the createprofile.vbs script in the users' login script to create an initial profile using the default one.
It takes a bit of effort to get right, but it's well worth it if you have a number of machines to push this out to. The bummer is that I only just got around to putting 1.0.7 out, and now 1.5 is out. Oh well.
Actually, if you have a look at the documentation for mysql_escape_string, you'll see that it is depreciated, and you should now be using mysql_real_escape_string instead.
If you do get a colour laser, make sure you check out the cost of consumables before you pick one. I recently had to get a new set of toner cartriges for our Epson c900, and they were £100 +vat (rrp) for each colour. I managed to get them for about £80 +vat each by searching online, but that still hurt. The black cartridges are only about £30 by comparison.
Add to that the fact that they ship the printer with only quarter full cartridges...
Agreed.... at least I thought so, but recently while trying to deploy FF with group policies I came across Advanced Installer which is a free(beer) MSI authoring tool that makes it really simple to create MSI's. I've made my own custom MSI's for firefox using a combination of this and FFDeploy (well actually just the createProfile.vbs and manual method from it).
This can be fixed by setting the preference browser.cache.memory.capacity to something like 16000 in about:config. This will limit the memory cache to 16M.
see this article (about 1/3 of the way down) for more details on this and other tweaks such as changing the disk cache location... My roaming profile is now a sensible size again.
Hmmmmmm... One of the major differences between SCSI and IDE is that when accessing an IDE drive, your system processor does a fair amount of the work. With SCSI, this work is offloaded to the SCSI controller and the drive, leavinf the system processor free to do other stuff. This is why SCSI is a much better option for servers (and also why it's more expensive).
I think part of the reason that SCSI has been such a pain is that there have been so many SCSI 'standards'. IIRC, SCSI3 defined 5 properties that the system should have, but mandated that a SCSI3 device had to implement any 2 of these. This is insane IMHO.
Things seem to have returned to some sort of sanity with the current Ultra160 and Ultra320 standards.
This article is a good description of all the SCSI standards.
Would it be possible with something like this? I've not played with either, so I don't know if this is a stupid question or not, just thought it was worth asking.
Yes, but the session key still needs to be encrypted with the recipients public key. This means that for each recipient the message will be different. Therefore they have to send one message per recipient, as opposed to sending one message with lost of recipients.
I was hilighting the impact it would have on the bandwith required rather than the CPU time involved. Spammers currently offload the bandwidth required onto downstream mailservers (open relays etc...), but if they're encrypting the messages they need to send out one message for every recipient, which will vastly increase the bandwith they use, and therefore their costs.
It also means that they would have to send a different message to each recipient, as opposed to just listing lots of addresses in the RCPT To: field. This would vastly increase the bandwidth required to send the messages out.
You're implying that it is possible to infer something about the size of the source from the hash itself, but if you were given just the hash in your example, you'd have no idea whether that was created from a short string, or a 2G file.
Unless you know the source is small by some other means, the fact that it is small makes no difference to how easy it is to reverse the hash.
It simply takes a hash of the file, and encrypts that with your private key, so that anyone with your public key can decrypt it and verify that the file is what was signed.
I can't remember which hash algorithm gpg uses by default, but I believe earlier versions of pgp used MD5.
Well, The algorithm for the OSCommerce cc check is as follows:
1. Remove any non digits from string. 2. Reverse the string. 3. double every second digit counting from zero (i.e first one gets doubled) 4. If a doubled digit is >= 10, add the 2 digits together (i.e. 12 becomes 3) 5. Add all the digits together. 6. If the result is exactly divisible by 10, then the card is valid... ... ... 8. Profit
Slashdot Mirror
Or, which of us can say they wished they hadn't disassembled a computer before powering it up?
What, like a Intel ICH7-M SATA Controller or an Intel NH82801GBM Southbridge? In fact it seems to use entirely Intel chips inside see here on page 16.
You can change the location of the cache dir by setting the browser.cache.disk.parent_directory preference in about:config.
I've used a modification of the createprofile.vbs script from FFDeploy to set this up as new profiles are created from a login script.
I actually ended up creating my own msi files using a combination of regmon and filemon from Sysinternals to map it out, and Advanced Installer (the free version) to build the package. I ended up with a package that I can push out that includes flash and shockwave as well as a default profile with adblock included. I then use my version of the createprofile.vbs script in the users' login script to create an initial profile using the default one.
It takes a bit of effort to get right, but it's well worth it if you have a number of machines to push this out to. The bummer is that I only just got around to putting 1.0.7 out, and now 1.5 is out. Oh well.
Actually, if you have a look at the documentation for mysql_escape_string, you'll see that it is depreciated, and you should now be using mysql_real_escape_string instead.
Gotta love PHP...
</pedant>
If you do get a colour laser, make sure you check out the cost of consumables before you pick one. I recently had to get a new set of toner cartriges for our Epson c900, and they were £100 +vat (rrp) for each colour. I managed to get them for about £80 +vat each by searching online, but that still hurt. The black cartridges are only about £30 by comparison.
Add to that the fact that they ship the printer with only quarter full cartridges...
Like he said, MySQL....
*ducks*
About the "memory leak" and other things, have a look at this article. (Start reading about a third of the way down).
the particular options you'll be interested in are browser.cache.memory.capacity and config.trim_on_minimize
Agreed.... at least I thought so, but recently while trying to deploy FF with group policies I came across Advanced Installer which is a free(beer) MSI authoring tool that makes it really simple to create MSI's. I've made my own custom MSI's for firefox using a combination of this and FFDeploy (well actually just the createProfile.vbs and manual method from it).
works like a charm.
Google is not distributing the resultant product (modified OS) to any external entities.
Are you sure about that? I'm not saying they are, just raising the question...
There are some tweaks that you can make to control Firefox's memory usage.
Goto about:config, and create a new integer setting called browser.cache.memory.capacity. Set it to something like 16000.
What this does is limit firefox's memory cache to 16M. you can see how much it's currently using by going to about:cache.
Note: you'll have to restart firefox for the change to take effect.
My source, which includes several tweaks, like moving the disk cache etc.. The interesting stuff starts about a third of the way down.
This can be fixed by setting the preference browser.cache.memory.capacity to something like 16000 in about:config. This will limit the memory cache to 16M.
see this article (about 1/3 of the way down) for more details on this and other tweaks such as changing the disk cache location... My roaming profile is now a sensible size again.
Hmmmmmm... One of the major differences between SCSI and IDE is that when accessing an IDE drive, your system processor does a fair amount of the work. With SCSI, this work is offloaded to the SCSI controller and the drive, leavinf the system processor free to do other stuff. This is why SCSI is a much better option for servers (and also why it's more expensive).
I think part of the reason that SCSI has been such a pain is that there have been so many SCSI 'standards'. IIRC, SCSI3 defined 5 properties that the system should have, but mandated that a SCSI3 device had to implement any 2 of these. This is insane IMHO.
Things seem to have returned to some sort of sanity with the current Ultra160 and Ultra320 standards.
This article is a good description of all the SCSI standards.
How's that different than any other software?
Erm... It would be legal in this case.... that's all
see section 1. of the GPL
Actually it should be:
My president may be an idiot, but anyone who believes that that makes me one is one moreso than either of us.
</grammar pedant>
Why yes, it's the KDE porno browser of course...
I think The Register summed it up best...
It's like selling people a toaster that could catch fire at any time, but then offering a free fire extinguisher to put out those fires as required.
Would it be possible with something like this? I've not played with either, so I don't know if this is a stupid question or not, just thought it was worth asking.
Yes, but the session key still needs to be encrypted with the recipients public key. This means that for each recipient the message will be different. Therefore they have to send one message per recipient, as opposed to sending one message with lost of recipients.
I was hilighting the impact it would have on the bandwith required rather than the CPU time involved. Spammers currently offload the bandwidth required onto downstream mailservers (open relays etc...), but if they're encrypting the messages they need to send out one message for every recipient, which will vastly increase the bandwith they use, and therefore their costs.
It also means that they would have to send a different message to each recipient, as opposed to just listing lots of addresses in the RCPT To: field. This would vastly increase the bandwidth required to send the messages out.
Hmmmmmm....... Is it me or does this plot sound alarmingly similar to the steaming pile that was A Call to Arms?
It was all going soo well until the last 2 commas...
You're implying that it is possible to infer something about the size of the source from the hash itself, but if you were given just the hash in your example, you'd have no idea whether that was created from a short string, or a 2G file.
Unless you know the source is small by some other means, the fact that it is small makes no difference to how easy it is to reverse the hash.
How do you think a gpg signature works?
It simply takes a hash of the file, and encrypts that with your private key, so that anyone with your public key can decrypt it and verify that the file is what was signed.
I can't remember which hash algorithm gpg uses by default, but I believe earlier versions of pgp used MD5.
I think you may be thinking of the Sun Opteron workstation discussed here.
Well, The algorithm for the OSCommerce cc check is as follows:
1. Remove any non digits from string.
2. Reverse the string.
3. double every second digit counting from zero (i.e first one gets doubled)
4. If a doubled digit is >= 10, add the 2 digits together (i.e. 12 becomes 3)
5. Add all the digits together.
6. If the result is exactly divisible by 10, then the card is valid...
...
...
8. Profit