Keep in mind that drivers often have to deal with physical, as opposed to virtual, memory addresses. Buggy drivers using only the 32bit low part of the PHYSICALADDRESS union = nice potential for crashes.
The non-SP1 version of XP supported full 4GB of physical memory, with SP1 they limited it to 4GB of address space... the 4GB hinting at milking the market, whereas the SP1 additional limitation says something about driver quality.
As for the memory split, remember that there's the/3GB boot option if you feel like it and know what you're doing:)
Depends on what kind of data you're interested in and the raid stripe size. Even with a large stripe size like 512kb, you probably couldn't get much useful information for something like big technical CAD drawings. But even with a pretty small stripe size like 64kb, you could get a lot of useful information from a database.
With normal FS format options, that would only take care of a very small portion of the drive (FS metadata doesn't consume that much space) - it would be pretty easy extracting useful data using plain old software. A single-pass disk wipe would be a lot more useful:)
That Gutmann paper is 10 years old - are those attacks still viable? Data density has increased quite a bit, and perpendicular recording has been introduced... does this have any effect other than making recovery a more time-consuming process?
Personally I feel safe doing a single-pass wipe, but don't work for any TLA organizations:)
The thing you're missing, though, is the additional power SMM gives... the ability to trap to SMM code on port I/O, for instance. So if you manage to flash your malware into the BIOS, you can then use your SMM exploit to protect against BIOS re-flashing.
I can understand that some stuff runs a lot faster with it (http://technet.microsoft.com/en-us/magazine/2007.04.windowsconfidential.aspx), but it sounds weird that it speeds up compiling... guess I should take a look at procmon and see what operations MSVS does. I know that it creates temporary files, but iirc those are done using FILE_ATTRIBUTE_TEMPORARY (ie, "try to keep the file in memory and avoid disk") and don't call FlushFileBuffers:)
I - as many others - disagree. The filesystem does keep things synced, when it decides to. It's documented pretty well, and you have manual override if you need more precise control. If you need everything synced, you can specify that as a filesystem mount option.
If the filesystem always synced after every operation, THAT would be a limitation, since it would be a major performance with no way to avoid.
The current commit policy of EXT4 might be dangerously long, but if that helps getting rid of *bugs* in other software, then all is good.
Well, the long story: _write doesn't use an interim buffer like fwrite() does, so it hits WriteFile instantaneously (for files in binary mode - code for text/utf files != nice). Doesn't call FlushFileBuffers().
However, the OS still does caching for WriteFile(), unless FILE_FLAG_NO_BUFFERING was specified on CreateFile() - which isn't a standard thing to do (big performance hit, write buffers have to be sector-aligned (in memory too!), et cetera).
fflush() does call FlushFileBuffers():) - ms libc version of fsync() is called _commit().
As for "advanced performance" helping, imho it just isn't worth it. Disabling NTFS last-access timestamp + %TEMP% on ramdrive == win.
"Advanced performance" doesn't mean enabling disk write cache, it means making FlushFileBuffers do nothing (stu-pi-di-ty). Disk write caching is called... *drumroll*... "Enabled write caching on the disk".
Iirc, the "Optimice for performance" vs. "Optimize for quick removal" settings mean whether to use filesystem cache or not.
Afaik, _write() is simply synchroneous to write() on *u*x - which means you have to do FlushFileBuffers() on the handle in order to do the sync.
Btw, "enable advanced performance" is a really really really bad idea - it turns FlushFileBuffers() into a null call. You *do* get filesystem writeback cache and disk write-back cache without this option...
It's actually a pretty damn good thing this has happened, since it will allow the KDE developers to go over their code and *FIX THEIR BUGS*, in turn making it more stable even on EXT3.
> The need to do a sync before data is guaranteed > to be written is a limitation of the filesystem. > It might be a reasonable limitation, and it may > be a limitation that is common to several > filesystems, but it is still a limitation.
It's not a limitation, it's a feature - seriously. This way, an application developers gets *some* control over performance aspects of their code.
sync should be seen as an expensive operation, and only used when necessary. At the same time, you shouldn't *depend* on a low-level call like write() to do buffering - doing lots of 1-byte writes is a bad idea, buffer your stuff.
Export HKEY_CURRENT_USER registry hive from old machine, import on new. Copy %APPDATA%. That will get you partially there... but of course a lot of applications insist on doing stuff in wacky non-spec ways, write config to HKEY_LOCAL_MACHINE (equivalent to wanting per-user settings in/etc on *u*x), et cetera.
The registry is a really neat thing, both performance and security wise (it's even separately journalled), but a lot of developers unfortunately misuse it.
As others have mentioned, try mounting your filesystems in synchronous mode and check performance.
There's another thing though, which people seem to miss: this isn't just about caching, it's also necessary in order to reduce file fragmentation... which is a thing that kills performance even on 10k-rpm drives.
I had planned on buying spore, but I definitely won't due to the *excessive* DRM. It's bad enough to have SecuROM slowing down gamecode and requiring the DVD to be in your drive, even though it's not being used for anything but copy protection.
But limiting the number of reinstalls? No way. Normally I would probably just have shrugged, and applied a crack to my legitimately purchased game. A part of spore is the online stuff (exchanging creatures, vehicles etc. with other people), and that would be blocked by using a pirate version.
EA can sod off, they're not getting my money. They're one of those companies that destroy everything they touch. I miss westwood.
If the envelopes were pre-paid, they contain watermarks that has information about the post-office they were sold from etc. No reason to do fancy glue chemical analysis:)
It's not like TPB is hosted in sweden anyway, after the raids against www.prq.se (where TPB was originally hosted)... and obviously wiretapping won't help against terrorists using encryption.
So, we welcome you, or alien overlord big brothers.
In "off" mode, most cellphones can last a *long* time before draining the battery - and most have the possibility to wake-up at a specified time. Good enough for you?:)
I'm running my Q6600 at 3.0GHz, stock voltage. The (stock) heatsink does get warm under full load, but not finger-burning hot. I do have a couple of 120mm case fans to help airflow, and I live in.dk where ambient temperatures aren't insane:)
Ho humm, is qmail really that great?
A lot of what DJB writes makes sense, but he seems to have a whole bunch of zealot followers who will flame you to death if you rise any questions about qmail stability/security.
While some of the points in http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html are near the point of irrelevance, it certainly still doesn't give me a lot of confidence in qmail.
I'm afraid you're forgetting that the record companies have the distribution rights, not Trent... he can't just give his former works away even if he wanted to.
Slashdot Mirror
The non-SP1 version of XP supported full 4GB of physical memory, with SP1 they limited it to 4GB of address space... the 4GB hinting at milking the market, whereas the SP1 additional limitation says something about driver quality.
As for the memory split, remember that there's the /3GB boot option if you feel like it and know what you're doing :)
Depends on what kind of data you're interested in and the raid stripe size. Even with a large stripe size like 512kb, you probably couldn't get much useful information for something like big technical CAD drawings. But even with a pretty small stripe size like 64kb, you could get a lot of useful information from a database.
With normal FS format options, that would only take care of a very small portion of the drive (FS metadata doesn't consume that much space) - it would be pretty easy extracting useful data using plain old software. A single-pass disk wipe would be a lot more useful :)
That Gutmann paper is 10 years old - are those attacks still viable? Data density has increased quite a bit, and perpendicular recording has been introduced... does this have any effect other than making recovery a more time-consuming process?
Personally I feel safe doing a single-pass wipe, but don't work for any TLA organizations :)
...or perhaps chrome reverts to a non-JIT javascript vm on 64bit arch?
Might want to grab a picture of him before his sex-change operation, then you probably wouldn't be fapping right now :)
The thing you're missing, though, is the additional power SMM gives... the ability to trap to SMM code on port I/O, for instance. So if you manage to flash your malware into the BIOS, you can then use your SMM exploit to protect against BIOS re-flashing.
*grin*
I can understand that some stuff runs a lot faster with it (http://technet.microsoft.com/en-us/magazine/2007.04.windowsconfidential.aspx), but it sounds weird that it speeds up compiling... guess I should take a look at procmon and see what operations MSVS does. I know that it creates temporary files, but iirc those are done using FILE_ATTRIBUTE_TEMPORARY (ie, "try to keep the file in memory and avoid disk") and don't call FlushFileBuffers :)
Thanks for clearing that out, I missed the "if(str->_flag & _IOCOMMIT)" part last night - I blame late hour and lack of coffee... Sorry! :)
You're probably better off doing explicit _commit(_fileno(fstream)) when necessary, rather than opening with the 'c' flag, for performance reasons.
I - as many others - disagree. The filesystem does keep things synced, when it decides to. It's documented pretty well, and you have manual override if you need more precise control. If you need everything synced, you can specify that as a filesystem mount option.
If the filesystem always synced after every operation, THAT would be a limitation, since it would be a major performance with no way to avoid.
The current commit policy of EXT4 might be dangerously long, but if that helps getting rid of *bugs* in other software, then all is good.
Well, the long story: _write doesn't use an interim buffer like fwrite() does, so it hits WriteFile instantaneously (for files in binary mode - code for text/utf files != nice). Doesn't call FlushFileBuffers().
However, the OS still does caching for WriteFile(), unless FILE_FLAG_NO_BUFFERING was specified on CreateFile() - which isn't a standard thing to do (big performance hit, write buffers have to be sector-aligned (in memory too!), et cetera).
fflush() does call FlushFileBuffers() :) - ms libc version of fsync() is called _commit().
As for "advanced performance" helping, imho it just isn't worth it. Disabling NTFS last-access timestamp + %TEMP% on ramdrive == win.
"Advanced performance" doesn't mean enabling disk write cache, it means making FlushFileBuffers do nothing (stu-pi-di-ty). Disk write caching is called... *drumroll*... "Enabled write caching on the disk".
Iirc, the "Optimice for performance" vs. "Optimize for quick removal" settings mean whether to use filesystem cache or not.
Afaik, _write() is simply synchroneous to write() on *u*x - which means you have to do FlushFileBuffers() on the handle in order to do the sync.
Btw, "enable advanced performance" is a really really really bad idea - it turns FlushFileBuffers() into a null call. You *do* get filesystem writeback cache and disk write-back cache without this option...
It's actually a pretty damn good thing this has happened, since it will allow the KDE developers to go over their code and *FIX THEIR BUGS*, in turn making it more stable even on EXT3.
> The need to do a sync before data is guaranteed
> to be written is a limitation of the filesystem.
> It might be a reasonable limitation, and it may
> be a limitation that is common to several
> filesystems, but it is still a limitation.
It's not a limitation, it's a feature - seriously. This way, an application developers gets *some* control over performance aspects of their code.
sync should be seen as an expensive operation, and only used when necessary. At the same time, you shouldn't *depend* on a low-level call like write() to do buffering - doing lots of 1-byte writes is a bad idea, buffer your stuff.
"dotfiles - because every application having it's own configuration syntax is such a joy" :-)
Export HKEY_CURRENT_USER registry hive from old machine, import on new. Copy %APPDATA%. That will get you partially there... but of course a lot of applications insist on doing stuff in wacky non-spec ways, write config to HKEY_LOCAL_MACHINE (equivalent to wanting per-user settings in /etc on *u*x), et cetera.
The registry is a really neat thing, both performance and security wise (it's even separately journalled), but a lot of developers unfortunately misuse it.
As others have mentioned, try mounting your filesystems in synchronous mode and check performance.
There's another thing though, which people seem to miss: this isn't just about caching, it's also necessary in order to reduce file fragmentation... which is a thing that kills performance even on 10k-rpm drives.
Indeed.
I had planned on buying spore, but I definitely won't due to the *excessive* DRM. It's bad enough to have SecuROM slowing down gamecode and requiring the DVD to be in your drive, even though it's not being used for anything but copy protection.
But limiting the number of reinstalls? No way. Normally I would probably just have shrugged, and applied a crack to my legitimately purchased game. A part of spore is the online stuff (exchanging creatures, vehicles etc. with other people), and that would be blocked by using a pirate version.
EA can sod off, they're not getting my money. They're one of those companies that destroy everything they touch. I miss westwood.
If the envelopes were pre-paid, they contain watermarks that has information about the post-office they were sold from etc. No reason to do fancy glue chemical analysis :)
It's not like TPB is hosted in sweden anyway, after the raids against www.prq.se (where TPB was originally hosted)... and obviously wiretapping won't help against terrorists using encryption. So, we welcome you, or alien overlord big brothers.
In "off" mode, most cellphones can last a *long* time before draining the battery - and most have the possibility to wake-up at a specified time. Good enough for you? :)
I'm running my Q6600 at 3.0GHz, stock voltage. The (stock) heatsink does get warm under full load, but not finger-burning hot. I do have a couple of 120mm case fans to help airflow, and I live in .dk where ambient temperatures aren't insane :)
Ho humm, is qmail really that great? A lot of what DJB writes makes sense, but he seems to have a whole bunch of zealot followers who will flame you to death if you rise any questions about qmail stability/security. While some of the points in http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html are near the point of irrelevance, it certainly still doesn't give me a lot of confidence in qmail.
I'm afraid you're forgetting that the record companies have the distribution rights, not Trent... he can't just give his former works away even if he wanted to.