> And I've had personal experience of the special cop-only-not-for-sale-to-mere-civilians stuff. It hurt but it didn't stop me.
Of course not. Why do you think we're zapped with it several times a year (depending on the department) and still expected to turn, draw, and fire (and most importantly hit the bad guy)?
I suspect most/many companies are very low-tech -- the resumes are probably printed out and reviewed that way, hence the one college having an entirely too large filing system. I couldn't imagine that, this day and age, most people snail mail their resumes.
>How does one use a gun for defense without the possibility of killing someone with it?
Lots of outcomes are possible in a self-defense encounter with a criminal (you being the 'good guy' in this situation, the criminal being the 'bad guy'), but as you well know crimes can be stopped without the use of deadly force.. Sort of how law enforcement, just by their presence in an area, helps decrease the likelihood of crime occurring.
The theory is that having the weapon handy, brandishing it, perhaps even firing it at the criminal, would otherwise prevent the criminal from killing YOU. In many states the criminal forfeits his/her life when they choose to invade your home, for example. In Ohio, you are legally allowed to shoot and kill an intruder regardless of his 'intent' - it is impossible to judge his 'intent' nor should it matter. Many a murder has occurred when a criminal 'only meant to take his wallet'.
Of course, if the criminal turns and flees you are not allowed to shoot him in the back, can you pursue him (it wouldn't be a good idea anyway). But the outcome was the 'best case': You are not dead, you didn't have to shoot the guy, and you have a good description of the suspect to tell police.
We can talk about the sematics of 'use' all day, but the outcome of the situation is all that matters. If you picked up a baseball bat, knife, gun, etc. and stopped the crime, then you effectively 'used' those tools.
As a part-time (my real gig is a geek like most of you) Law Enforcement Officer (I don't see to many Law Enforcement Officials wandering the streets of Vice City; I didn't find the Chief or other brass in the station) I'd really rather people take out their violence on the virtual me than the actual me.
But, like you I'd find a game that was explicitly a "Cop Killer" type to be horribly offensive. There are few professions like law enforcement that garner quite as much undeserved negativity. Talking with friends about a cruiser parked on the street they say "What a waste of money, what are they doing etc. etc." and I inform them that we have a take-home policy and that particular officer works third shift so unless you happen to drive by that late at night you'll probably never see it move; and because of this our cruisers generally last 6 or 7 years so it is in the best interests of everyone (taxpayers, officers, people living in the neigborhood) that this occurs.
The officer you see speeding down the road over the limit without his (not sexist or anything, if you like replace he with she) lights on may be responding to another officer's stop but can't turn on his lights. He wants to get there ASAP but can't go 'Code 3' - he's not speeding "just because he can". He may save his buddy's life by providing extra presence at a high-risk stop.
I'm not really complaining, of course; I knew that when I took the job and was granted the ability to take away people's freedom it sort of sours the public's perception of what we do. We generally only interact with the public when they've done something wrong, and so we're always the mean daddy who takes us out back with his belt in his hand. I'd just appreciate it if when people started to formulate something negative in their mind they first consider all the options, not just the most negative one.
On a lighter note, I bought GTA3: Vice City for the PC the day it was released and have wasted many an hour running people over and generally wreaking havoc. Currently the police spend over $60K a day due to my wacky antics - to someone who said that the police in the game don't follow up on crimes they are obviously spending money on something which is, in all likelihood, due to the theft of their cruisers from their lot (even LEOs need a break from reality, and we'd all love to drive with lights flashing at 100MPH and slide through turns etc. etc. - fortunately my days are mundane enough that I don't need to do that too often in real life;) ).
I do have to complain about the realism, though. If you walk into our station brandishing a weapon you'll face way more firepower than a few officers with Berettas:D
You really don't know what you're talking about do you?
It is fairly clear you are the one who is a bit confused here. Because, typically, disk is the primary data storage mechanism and main memory capacity is less than the total size of a database the enterprise DBMS vendors (this does NOT include MySQL) have what is commonly referred to as a 'data cache' (vendors may call it something else) which stores data pages in main memory (there are other caches for other data structures, but we're only concerned with the data cache at this point). I'll explain common techniques and then why the data cache is typically superior to MySQL's 'query cache'.
Note: I am going to generalize throughout, so there may be differences between your favorite enterprise DBMS and what I say here so please don't post 'My DBMS does all but this one tiny thing the same': the theory is more or less the same.
Data caches are managed by the DBMS and are strictly controlled by the DBA. Typically most caches are managed by a MRU/LRU (most/least recently used) algorithm to keep stale pages out of the cache (although the DBA can configure the algorithm to suit the particular needs of the system). Also it is possible to split the data cache up into smaller chunks (called cachelets, pools, etc.) and bind those to different physical database objects (tables, indexes, etc.). You can thus ensure that an important table is always going to have room in the cache by binding a dedicated cache to it. You can also prioritize objects so that if more than one object is sharing a cache you ensure it has priority over another one.
MySQL relies upon the OS filesystem cache to do this work for them. This is an obvious advantage from a MySQL code developer's standpoint since they do not have to write any additional code to handle this. However there are some fairly significant drawbacks and limitations with this simplistic approach. Simply put: the DBMS (via knowledge from the DBA and query statistics) has a much better 'big picture' than the OS. As such, the DBMS can set an optimal strategy for maintaining the cache. I am not intimately familiar with OS data caches so I will not comment on them except I guess that they 'assume' that most data accesses will be of the 'sequential file access type' (e.g. apps will request blocks of a particular file in a sequential fashion). Individual physical row retrieval issues aside, this is very rarely the case in OLTP systems. Even if not, they still are dealing with limited knowledge and could never be as efficient as a DBMS-run cache.
OS caches are also not nearly as configurable, which comes as no surprise since they are not really designed for this type of use (or mis-use as the case may be). MySQL zealots often quote "best tool for the job" which I wholeheartedly agree. The OS cache is obviously NOT the best tool for the job for DBMS use. Not having a configurable data cache is a huge limitation - and considering past MySQL AB views of things like referential integrity (everyone remembers the infamous 'what for?' quote from the TODO list) it is probably due to ignorance of DBMS products and/or laziness (as an aside, isn't it a little scary that misguided people attempt to deploy MySQL in mission-critical use when it was developed by people who really have no clue about DBMS in general?).
Enough rambling aside, we now know both what a DBMS-managed data cache is and why they are superior to OS-level caches. What about the vaunted MySQL 'query cache'?
Pure junk.
Ok, I typed that firmly tounge-in-cheek, in the context of a feature for MySQL, it is not pure junk. However, this is not a superior feature that MySQL has over enterprise DBMS products. To put it bluntly: the query cache is a cheap imitation to a data cache and is primarily needed because of the lack of a data cache. Before we can discuss it, go
The Zend Performance Suite is far better, albeit commerical, though since it includes page (partial or whole page) and database query caching (in fact it can cache just about anything) to decrease the load in DB driven sites.
I've been using SP1 (since it was released) on several machines, both at home and at work, and have noticed nothing unusual. The machines have all been relatively speedy (1GHz and up) so perhaps a 1 second load time vs. a 10 second load time is not noticeable, but even on my home system in which I play games I have not noticed anything wonky. I would expect games and the like (for home-use systems) would be most affected since they tend to malloc lots of memory -- I'll just have to benchmark my load times on my apps now and then after I apply SP2 to see if I was hit or not.
If I ran any large DBMS software etc. maybe I'd notice it but for home/business use I'd wager the majority of Windows users weren't hit hard by it.
I prefer PHP/Linux/Apache/Sybase ASE. In our semi-formal testing ASE beat out MySQL and PostgreSQL for our application (web). The ability to use clustered indexes, fine-grained caching, stored procedures, etc. made up for the difference in locking (MyISAM vs. ASE's locking). InnoDB was slower than MyISAM, so we did not bother the entire test suite on InnoDB.
However, if we had zero cash I'd chose PostgreSQL in a heartbeat.
Oracle is not the only DBMS product out there capable of avoiding data loss. If you want to stay free, you can use PostgreSQL/SAPDB/etc.. If you want to go pay you can use DB2/Sybase ASE/MS SQL Server/etc..
Next/Prev Links - possible high-traffic workaround
on
BBC on Website Slow Downs
·
· Score: 3, Insightful
It is pretty easy -- make them non-dynamic, something along the lines of: <- prev | next ->
Which points to something like "current_article_url&goto=prev" and "current_article_url&goto=next". That would avoid a database call until you actually click the link (it would translate that into the actual previous and next articles and then show the correct one).
Of course, you lose a little bit of the dynamic site aspect but if you *really* can't remember what the next article was you can always keep the main page open in a new browser window/tab and refer back to it.
A 'real' or more accurately a 'truely' relational database management system does not exist (yet? ever?). Every DBMS out there (Oracle, MS SQL Server, Sybase ASE, MySQL, PostgreSQL, etc.) are *flawed*, SQL-based DBMS.
Actually I'd think mom-n-pop shops would be *harder* hit by the loss of a transaction than a larger company. A lost sale for them would make up a substantially larger percentage of their revenue than a multi-billion-dollar bank.
Of course, the mom-n-pop shops have (usually) much smaller transactions than banks, so a bank loss may hit more. Still, if I was a mom-n-pop I'd want NO loss -- it's money out of my pocket!
It seems I spoke a little too soon: " Recovery from fatal failures during encryption/decryption operations--EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. NOTE: Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file. For this reason, it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc."
So, if you take a file and attempt to en/de-crypt it in a non-encrypted folder and are in the MIDDLE of the process your system is hosed then yes, the bits of the file could be accessed. Also, we all know magnetic media is recoverable, so as long as someone wants to apply electron analysis they could obtain the decrypted file.
Of course, the fact that the file was, at least originally, *not* encrypted also makes it vulnerable to that sort of recovery technique -- the only 'best' method would be to create all sensitive files in an encrypted folder so non-encrypted versions are never created.
I have an UPS attached to my system -- it should not be out of the question for someone needing high security (and needing to use Windows 2000/XP;) ) to also own an UPS to avoid many such issues.
In any rate, creating an encrypted folder seems like an acceptable workaround to a remote chance this will happen.
It looks like even disk access would make recovery difficult: " Physically access to the media--An individual with physical access to the machine could potentially attempt sophisticated attacks by going to the disk directly. Attempts to read the data this way will fail because it is encrypted and a successful process would require implementing EFS itself. Another possible attack with physical access can be to invalidate or delete the recovery portion on the encrypted file. This will not still not work because EFS will automatically recreate the recovery information when the file is successfully opened next time."
What do you define an "environment without a properly configured domain"?
If I'm on a corporate network then certainly the domain admin should be able to access my files. The way I understand the Group Policy settings in 2000/XP the domain certificate is keyed upon the actual domain controller/account -- so it would be very difficult to impossible to impersonate a domain controller on the compromised box. Of course, I could have read the whitepaper wrong -- I'm trying to figure out the security settings myself.
In a home setting: "EFS can also be used in small office or home office environments. EFS will automatically generate a recovery key, issue a self-signed certificate to the local administrator account on first logon and save it in the administrator's certificate store just as is the case for default policy in the domain. This makes the local administrator the default recovery agent on stand-alone workstation/servers allowing the local administrator to recover any encrypted file on the system. Note that this is only the default policy. Users may change this to suit their requirements."
So, unless a home user does something really, really weird then there's no big deal (unless they leave their administrator password blank or easy to guess...)
A couple clarifications I found while reading the Word Document gleaned from this URL.
A) Application A always running. While the application is running, the data file in unencrypted on disk so anyone with the appropriate permissions can read it. Exchange is a good example of this - how often do you shut it off?
From reading the doc, the file(s) are not un-encrypted and stored temporarily on disk whilst an authorized user is accessing them. That would not make much sense -- it simply un-encrypts the byte stream being read from the file. I assume this is similar to how NTFS file compression works.
To quote:
"A file need not be decrypted before use -- encryption and decryption is done transparently when bytes travel to and from the disk."
Not only that, but even if the file was on a shared directory any old user could still not access it -- they have to be added as a valid decrypt account (so it really does not matter that they can access it, you explicitly gave them the right!).
B) What happens when you have a powercut. If the file was unencrypted guess what state it'll stay in until you manually poke it?
As the file is never decrypted (on disk) until you request it to be, this is false. Obviously if you request a file to be un-encrypted and forget to encrypt it when you turn off your machine then it will, obviously, be accessible.
C) If it's data like word documents then this is the chain of events: open encrypted file, (it decrypts in the background), you change the file, you save it, windows creates a NEW file and writes the changes to it, office deletes the old file, office renames the NEW file to the name of the old file, windows encrypts the changed file, and office etc rename the encrypted version back to the original filename. But the blocks for the decrypted one are on disk for anyone with the appropriate undelete tools to use.
Again, incorrect, provided your temporary files are created on an NTFS volume. To wit:
"EFS is tightly integrated with NTFS. When temporary files are created, the attributes from the original file may be copied to temporary files as long as all files are on NTFS volume. If the original file is encrypted, EFS encrypts its temporary copies when attributes are transferred during file creation. EFS resides in the Windows 2000 kernel and uses the non-paged pool to store file encryption keys, ensuring that they never make it to the paging file."
Also, if you encrypt an entire directory any new files created in it are also encrypted (e.g. user encrypts "My Documents" then Word temp files would be automagically encrypted even if the flags were not preserved.)
This was all readily available with a simple "Windows NTFS Encryption File System" search on Google (it is the second result).
It seems you either cleverly trolled or did not take the time to research your assumptions. The opening remarks of the document say the exact opposite of what you were trying to say:
"Manual encryption and decryption on each use.
Leaks from temporary and paging files.
EFS addresses all the problems mentioned above and more. The following four sections go into detail on the encryption technology, where encryption takes place in the system, user interaction, and data recovery."
I have a relative that used to work at one of those big chain stores. When I asked him, he said the tactic is not used to see if the customer stole something (the sensor gates will most certainly go off if you are carrying illicit merchandise) but to see if the person at the register made a 'mistake' in ringing up the order (e.g. scanning only one box of CD-Rs when there are 5 in the bag, charging you $4.00 for a LCD monitor, etc).
Of course, if I was in cahoots with a register person I would simply ignore them or say "No thanks" and walk out of the store.
Still, maybe it scares the register people enough to knock it off.
I routinely receive notices from the BSA around once or twice a year. I throw them away without opening - we've not a Microsoft product in the house - all Linux (which, last time I checked, was free) and Sybase ASE (which we pay a lot for;)).
My non-expert opinion is these are spam letters targeted at anyone and everyone who is listed as a technical contact SOMEWHERE.
That is a close approximation but fails in a couple, somewhat important, ways: 1) It assumes your database lives in a discrete file (or series of files). For instance MySQL puts each DB in its' own directory, but postgreSQL stores every user DB in a series of large files (and I don't think you can separate the DBs out). 2) You have to pause, quiesce, or somehow write lock the database to ensure you have no partial writes. 3) Generally, unless you copy the *entire* installation directory (namely the system database tables), you cannot load the database into a new server (say if I wanted to do a poor-man's replication by copying and moving the DB over every day or so). If you have only that database, configured identically, then copying the installation may work. However if you have more than one DB you can't.
Slashdot Mirror
Just like lay-enforcement grade tasers (which are far more powerful than this), this type of electric shock will NOT affect pacemakers or the heart.
> And I've had personal experience of the special cop-only-not-for-sale-to-mere-civilians stuff. It hurt but it didn't stop me.
Of course not. Why do you think we're zapped with it several times a year (depending on the department) and still expected to turn, draw, and fire (and most importantly hit the bad guy)?
It's a form of pain compliance, nothing more.
I suspect most/many companies are very low-tech -- the resumes are probably printed out and reviewed that way, hence the one college having an entirely too large filing system. I couldn't imagine that, this day and age, most people snail mail their resumes.
But unless my ISP sets some sort of a filter I *still* receive the email. I don't want to get it. Ever.
>How does one use a gun for defense without the possibility of killing someone with it?
Lots of outcomes are possible in a self-defense encounter with a criminal (you being the 'good guy' in this situation, the criminal being the 'bad guy'), but as you well know crimes can be stopped without the use of deadly force.. Sort of how law enforcement, just by their presence in an area, helps decrease the likelihood of crime occurring.
The theory is that having the weapon handy, brandishing it, perhaps even firing it at the criminal, would otherwise prevent the criminal from killing YOU. In many states the criminal forfeits his/her life when they choose to invade your home, for example. In Ohio, you are legally allowed to shoot and kill an intruder regardless of his 'intent' - it is impossible to judge his 'intent' nor should it matter. Many a murder has occurred when a criminal 'only meant to take his wallet'.
Of course, if the criminal turns and flees you are not allowed to shoot him in the back, can you pursue him (it wouldn't be a good idea anyway). But the outcome was the 'best case': You are not dead, you didn't have to shoot the guy, and you have a good description of the suspect to tell police.
We can talk about the sematics of 'use' all day, but the outcome of the situation is all that matters. If you picked up a baseball bat, knife, gun, etc. and stopped the crime, then you effectively 'used' those tools.
As a part-time (my real gig is a geek like most of you) Law Enforcement Officer (I don't see to many Law Enforcement Officials wandering the streets of Vice City; I didn't find the Chief or other brass in the station) I'd really rather people take out their violence on the virtual me than the actual me.
;) ).
:D
But, like you I'd find a game that was explicitly a "Cop Killer" type to be horribly offensive. There are few professions like law enforcement that garner quite as much undeserved negativity. Talking with friends about a cruiser parked on the street they say "What a waste of money, what are they doing etc. etc." and I inform them that we have a take-home policy and that particular officer works third shift so unless you happen to drive by that late at night you'll probably never see it move; and because of this our cruisers generally last 6 or 7 years so it is in the best interests of everyone (taxpayers, officers, people living in the neigborhood) that this occurs.
The officer you see speeding down the road over the limit without his (not sexist or anything, if you like replace he with she) lights on may be responding to another officer's stop but can't turn on his lights. He wants to get there ASAP but can't go 'Code 3' - he's not speeding "just because he can". He may save his buddy's life by providing extra presence at a high-risk stop.
I'm not really complaining, of course; I knew that when I took the job and was granted the ability to take away people's freedom it sort of sours the public's perception of what we do. We generally only interact with the public when they've done something wrong, and so we're always the mean daddy who takes us out back with his belt in his hand. I'd just appreciate it if when people started to formulate something negative in their mind they first consider all the options, not just the most negative one.
On a lighter note, I bought GTA3: Vice City for the PC the day it was released and have wasted many an hour running people over and generally wreaking havoc. Currently the police spend over $60K a day due to my wacky antics - to someone who said that the police in the game don't follow up on crimes they are obviously spending money on something which is, in all likelihood, due to the theft of their cruisers from their lot (even LEOs need a break from reality, and we'd all love to drive with lights flashing at 100MPH and slide through turns etc. etc. - fortunately my days are mundane enough that I don't need to do that too often in real life
I do have to complain about the realism, though. If you walk into our station brandishing a weapon you'll face way more firepower than a few officers with Berettas
Maybe they should've picked a DBMS with replication (no, not MySQL).
It is fairly clear you are the one who is a bit confused here. Because, typically, disk is the primary data storage mechanism and main memory capacity is less than the total size of a database the enterprise DBMS vendors (this does NOT include MySQL) have what is commonly referred to as a 'data cache' (vendors may call it something else) which stores data pages in main memory (there are other caches for other data structures, but we're only concerned with the data cache at this point). I'll explain common techniques and then why the data cache is typically superior to MySQL's 'query cache'.
Note: I am going to generalize throughout, so there may be differences between your favorite enterprise DBMS and what I say here so please don't post 'My DBMS does all but this one tiny thing the same': the theory is more or less the same.
Data caches are managed by the DBMS and are strictly controlled by the DBA. Typically most caches are managed by a MRU/LRU (most/least recently used) algorithm to keep stale pages out of the cache (although the DBA can configure the algorithm to suit the particular needs of the system). Also it is possible to split the data cache up into smaller chunks (called cachelets, pools, etc.) and bind those to different physical database objects (tables, indexes, etc.). You can thus ensure that an important table is always going to have room in the cache by binding a dedicated cache to it. You can also prioritize objects so that if more than one object is sharing a cache you ensure it has priority over another one.
MySQL relies upon the OS filesystem cache to do this work for them. This is an obvious advantage from a MySQL code developer's standpoint since they do not have to write any additional code to handle this. However there are some fairly significant drawbacks and limitations with this simplistic approach. Simply put: the DBMS (via knowledge from the DBA and query statistics) has a much better 'big picture' than the OS. As such, the DBMS can set an optimal strategy for maintaining the cache. I am not intimately familiar with OS data caches so I will not comment on them except I guess that they 'assume' that most data accesses will be of the 'sequential file access type' (e.g. apps will request blocks of a particular file in a sequential fashion). Individual physical row retrieval issues aside, this is very rarely the case in OLTP systems. Even if not, they still are dealing with limited knowledge and could never be as efficient as a DBMS-run cache.
OS caches are also not nearly as configurable, which comes as no surprise since they are not really designed for this type of use (or mis-use as the case may be). MySQL zealots often quote "best tool for the job" which I wholeheartedly agree. The OS cache is obviously NOT the best tool for the job for DBMS use. Not having a configurable data cache is a huge limitation - and considering past MySQL AB views of things like referential integrity (everyone remembers the infamous 'what for?' quote from the TODO list) it is probably due to ignorance of DBMS products and/or laziness (as an aside, isn't it a little scary that misguided people attempt to deploy MySQL in mission-critical use when it was developed by people who really have no clue about DBMS in general?).
Enough rambling aside, we now know both what a DBMS-managed data cache is and why they are superior to OS-level caches. What about the vaunted MySQL 'query cache'?
Pure junk.
Ok, I typed that firmly tounge-in-cheek, in the context of a feature for MySQL, it is not pure junk. However, this is not a superior feature that MySQL has over enterprise DBMS products. To put it bluntly: the query cache is a cheap imitation to a data cache and is primarily needed because of the lack of a data cache. Before we can discuss it, go
The APC Cache is no longer being developed (check the last build date: August 25, 2001) and is not the best free compilation system.
The best free solution is the ionCube PHP Accelerator.
The Zend Performance Suite is far better, albeit commerical, though since it includes page (partial or whole page) and database query caching (in fact it can cache just about anything) to decrease the load in DB driven sites.
I've been using SP1 (since it was released) on several machines, both at home and at work, and have noticed nothing unusual. The machines have all been relatively speedy (1GHz and up) so perhaps a 1 second load time vs. a 10 second load time is not noticeable, but even on my home system in which I play games I have not noticed anything wonky. I would expect games and the like (for home-use systems) would be most affected since they tend to malloc lots of memory -- I'll just have to benchmark my load times on my apps now and then after I apply SP2 to see if I was hit or not.
If I ran any large DBMS software etc. maybe I'd notice it but for home/business use I'd wager the majority of Windows users weren't hit hard by it.
I prefer PHP/Linux/Apache/Sybase ASE. In our semi-formal testing ASE beat out MySQL and PostgreSQL for our application (web). The ability to use clustered indexes, fine-grained caching, stored procedures, etc. made up for the difference in locking (MyISAM vs. ASE's locking). InnoDB was slower than MyISAM, so we did not bother the entire test suite on InnoDB.
However, if we had zero cash I'd chose PostgreSQL in a heartbeat.
Hey look - it's COLD FUSION! *spits on ground*
"Not merely bad, but unpleasant in a hostile way."
- Roger Ebert (reviewing Battlefield Earth)
Oracle is not the only DBMS product out there capable of avoiding data loss. If you want to stay free, you can use PostgreSQL/SAPDB/etc.. If you want to go pay you can use DB2/Sybase ASE/MS SQL Server/etc..
It is pretty easy -- make them non-dynamic, something along the lines of:
<- prev | next ->
Which points to something like "current_article_url&goto=prev" and "current_article_url&goto=next". That would avoid a database call until you actually click the link (it would translate that into the actual previous and next articles and then show the correct one).
Of course, you lose a little bit of the dynamic site aspect but if you *really* can't remember what the next article was you can always keep the main page open in a new browser window/tab and refer back to it.
EXCELLENT post. Sums up the armchair-DBA crowd here at /. quite nicely.
:)
If I had a gold star you'd get one
A 'real' or more accurately a 'truely' relational database management system does not exist (yet? ever?). Every DBMS out there (Oracle, MS SQL Server, Sybase ASE, MySQL, PostgreSQL, etc.) are *flawed*, SQL-based DBMS.
Check out www.dbdebunk.com to be enlightened.
Actually I'd think mom-n-pop shops would be *harder* hit by the loss of a transaction than a larger company. A lost sale for them would make up a substantially larger percentage of their revenue than a multi-billion-dollar bank.
Of course, the mom-n-pop shops have (usually) much smaller transactions than banks, so a bank loss may hit more. Still, if I was a mom-n-pop I'd want NO loss -- it's money out of my pocket!
It seems I spoke a little too soon:
;) ) to also own an UPS to avoid many such issues.
" Recovery from fatal failures during encryption/decryption operations--EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. NOTE: Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file. For this reason, it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc."
So, if you take a file and attempt to en/de-crypt it in a non-encrypted folder and are in the MIDDLE of the process your system is hosed then yes, the bits of the file could be accessed. Also, we all know magnetic media is recoverable, so as long as someone wants to apply electron analysis they could obtain the decrypted file.
Of course, the fact that the file was, at least originally, *not* encrypted also makes it vulnerable to that sort of recovery technique -- the only 'best' method would be to create all sensitive files in an encrypted folder so non-encrypted versions are never created.
I have an UPS attached to my system -- it should not be out of the question for someone needing high security (and needing to use Windows 2000/XP
In any rate, creating an encrypted folder seems like an acceptable workaround to a remote chance this will happen.
It looks like even disk access would make recovery difficult:
" Physically access to the media--An individual with physical access to the machine could potentially attempt sophisticated attacks by going to the disk directly. Attempts to read the data this way will fail because it is encrypted and a successful process would require implementing EFS itself. Another possible attack with physical access can be to invalidate or delete the recovery portion on the encrypted file. This will not still not work because EFS will automatically recreate the recovery information when the file is successfully opened next time."
What do you define an "environment without a properly configured domain"?
If I'm on a corporate network then certainly the domain admin should be able to access my files. The way I understand the Group Policy settings in 2000/XP the domain certificate is keyed upon the actual domain controller/account -- so it would be very difficult to impossible to impersonate a domain controller on the compromised box. Of course, I could have read the whitepaper wrong -- I'm trying to figure out the security settings myself.
In a home setting:
"EFS can also be used in small office or home office environments. EFS will automatically generate a recovery key, issue a self-signed certificate to the local administrator account on first logon and save it in the administrator's certificate store just as is the case for default policy in the domain. This makes the local administrator the default recovery agent on stand-alone workstation/servers allowing the local administrator to recover any encrypted file on the system. Note that this is only the default policy. Users may change this to suit their requirements."
So, unless a home user does something really, really weird then there's no big deal (unless they leave their administrator password blank or easy to guess...)
A couple clarifications I found while reading the Word Document gleaned from this URL.
From reading the doc, the file(s) are not un-encrypted and stored temporarily on disk whilst an authorized user is accessing them. That would not make much sense -- it simply un-encrypts the byte stream being read from the file. I assume this is similar to how NTFS file compression works.
To quote: "A file need not be decrypted before use -- encryption and decryption is done transparently when bytes travel to and from the disk."
Not only that, but even if the file was on a shared directory any old user could still not access it -- they have to be added as a valid decrypt account (so it really does not matter that they can access it, you explicitly gave them the right!).
As the file is never decrypted (on disk) until you request it to be, this is false. Obviously if you request a file to be un-encrypted and forget to encrypt it when you turn off your machine then it will, obviously, be accessible.
Again, incorrect, provided your temporary files are created on an NTFS volume. To wit: "EFS is tightly integrated with NTFS. When temporary files are created, the attributes from the original file may be copied to temporary files as long as all files are on NTFS volume. If the original file is encrypted, EFS encrypts its temporary copies when attributes are transferred during file creation. EFS resides in the Windows 2000 kernel and uses the non-paged pool to store file encryption keys, ensuring that they never make it to the paging file."
Also, if you encrypt an entire directory any new files created in it are also encrypted (e.g. user encrypts "My Documents" then Word temp files would be automagically encrypted even if the flags were not preserved.)
This was all readily available with a simple "Windows NTFS Encryption File System" search on Google (it is the second result).
It seems you either cleverly trolled or did not take the time to research your assumptions. The opening remarks of the document say the exact opposite of what you were trying to say:
I have a relative that used to work at one of those big chain stores. When I asked him, he said the tactic is not used to see if the customer stole something (the sensor gates will most certainly go off if you are carrying illicit merchandise) but to see if the person at the register made a 'mistake' in ringing up the order (e.g. scanning only one box of CD-Rs when there are 5 in the bag, charging you $4.00 for a LCD monitor, etc).
Of course, if I was in cahoots with a register person I would simply ignore them or say "No thanks" and walk out of the store.
Still, maybe it scares the register people enough to knock it off.
I routinely receive notices from the BSA around once or twice a year. I throw them away without opening - we've not a Microsoft product in the house - all Linux (which, last time I checked, was free) and Sybase ASE (which we pay a lot for ;)).
My non-expert opinion is these are spam letters targeted at anyone and everyone who is listed as a technical contact SOMEWHERE.
That is a close approximation but fails in a couple, somewhat important, ways:
1) It assumes your database lives in a discrete file (or series of files). For instance MySQL puts each DB in its' own directory, but postgreSQL stores every user DB in a series of large files (and I don't think you can separate the DBs out).
2) You have to pause, quiesce, or somehow write lock the database to ensure you have no partial writes.
3) Generally, unless you copy the *entire* installation directory (namely the system database tables), you cannot load the database into a new server (say if I wanted to do a poor-man's replication by copying and moving the DB over every day or so). If you have only that database, configured identically, then copying the installation may work. However if you have more than one DB you can't.