Oh no, not chemicals! The vast, vast majority of what is pumped is water.
Are you that fucking stupid??? Yes, there's only about 0.5% chemical additives, yes the "vast majority" is water (if you exclude the propants, which are pretty benign). But some of the chemicals are highly toxic, and there's millions of gallons used per fracturing, so you're talking about thousands of gallons of toxic chemicals being pumped into the ground every time.
Widespread contamination has not been demonstrated, but there is as-yet unquantified risk--and examples of contamination.
So to say "it's just water" is either gross ignorance, or lying. Maybe I should visit you and offer you a drink, with the assurance that you'll be fine because it's 99.5% water;-)
It is hypothetically possible to recover from a single overwrite, because it is a fact that "magnetic domain remnants" are left after an overwrite.
Incorrect, plain and simple--though it was true 20 years ago. Bits no longer occupy a wide swath of domains only partially set to the current orientation.
That has nothing to do with the theory of how the data could be recovered. The theory was that flipping a 1 to a 0 is really like applying a "0" magnetic field to a bit that is currently "0.961235", and you end up with "0.015132". Hypothetically, maybe, some could analyze that "0.015132" and determine that it was previously a "0.961235", and reconstruct the data that way.
On the contrary, it has everything to do with it. The theory you mention had to do with the fact that bits were much larger, occupying many domains, and the new write might not flip every domain, thus leaving behind the trace of the prior value. When a bit is a single domain, there is no trace of the prior value.
20 years has not changed the fact that magnetic domains are analog, not digital. "Once you flip it, you've flipped it" isnt a concept that really exists in the analog world until your drive's firmware converts the analog reading to a digital 0.
Magnetic domains do not partially flip. They do go "all or nothing", and there is no "history" of the prior orientation.
If you want to make data non-recoverable from a HD, remove the platters, put them on a drill press and turn them into Swiss cheese with the biggest bit the drill will hold.
Large chunks of data (between the holes) will still be recoverable.
Medical records software is not a medical device. Now, *maybe* the system in question interfaces directly to some medical device, but probably not--most medical records software, *especially* for small practices, does not.
Disclaimer: I'm a Mac guy working in OS X (which is different yet), so I'm only generally familiar with Windows & Linux VM details. Anyway:
On Windows you can tune the amount of your address space taken by the kernel down
Link? I'm interested to see how that's done.
It's a/3GB switch in boot.ini. Took me a while to find any decent info about it (because in the Windows world there seem to be a bunch of hosers with blogs who don't know the difference between kernel address space and the page file, and google doesn't that know their posts are tripe)--the normal is the even split of 2GB each to kernel and user space, this makes it 1GB to kernel and 3GB to user space.
On Linux, you can't even do that and are stuck with 2GB to start.
Huh? The default 32-bit Linux memory split is 3/1; 3 GiB for userspace, 1 GiB for kernel space. If you compile a custom kernel you can configure this differently.
Did you perhaps swap "Windows" and "Linux" in your comment?
No, I was simply mistaken about the default split on Linux. (And my comment about "can't do that" referred to user-accessible configuration, not building your own kernel...)
I am quite upset with everyone dropping the "alleged" word and referring to them as "the bombers" instead of "the suspects."
That's a legal distinction, binding on the government and prosecutors. There's nothing wrong at all with me, or anyone else, declaring them guilty in the face of their actions in Cambridge/Watertown. They're 100% guilty as hell, and we all know it. The fact that the surviving one will have an opportunity, if he so chooses, to attempt to prove otherwise at a trial is a vitally important part of our attempt to maintain a decent society with respect for individual rights--but it doesn't affect the obviousness of his guilt.
He's never written anything that's tested the limits of computing...
And he's making invalid assumptions about what ordinary users might need. It's not that 32-bit is enough because most users don't need anything that requires 64-bit, it's that most users have never been offered things that require 64-bit, because they didn't have it. You know what needs more heap than you'll get in 32-bit to work well? According to IBM researchers: voice recognition. Yep, their research finds that being able to keep around 2GB+ enables huge, qualitative improvements. In my own work, I've hit the limit trying to do something simpler: provide really good auto-complete suggestions based on the individual user's corpus of work. Then of course there's all sorts of other searching algorithms, there's a huge difference in usability when you can provide a user a "browsable" interface that responds literally at the speed of thought vs requiring the user to compose the entire query and then wait a few seconds.
Meanwhile, I need only load up my badly coded evolutionary program to see my machine scream at the ~12 GB hit to the RAM. I say badly coded because I have found a few tricks to help get some additional memory savings out of it...also on topic, the aggression level was kind of low, so I imagine future tests might break the 32 GB barrier easily. Currently thinking of giving it a SSD for virtual memory...
So is 64-bit with 64GB in your computer not an option for you?
If you do anything serious with Java, on Windows, because of the memory layout and the insistence of the HotSpot VM on being allocated contiguous stretches of address space, you're limited to about 1.2GB of heap space. When you have a domain that has object counts in the 3 - 5 million region, that fills up rapidly. This is for a big graph of objects and the queries for them involve lots of graph traversal. The code in question can do set queries in about 0.5s that an RDBMS takes over 5 mins to do, so there's a real value to caching all the objects on the heap.
Yes, I could use another language that doesn't have a stupid VM and have ample overhead in 4GB...
Actually, I think you're mistaken about how much more heap space you could get outside of Java. On Windows you can tune the amount of your address space taken by the kernel down and thus, possibly, start with as much as 3GB for user space available to your app. On Linux, you can't even do that and are stuck with 2GB to start. Load your libraries and runtime for *any* language and tool set, and you're not going to have all that much more than 1.2GB. Sure, maybe 1.5GB and on Windows maybe even a bit more. But until you go to 64-bit, you're stuck starting out with 1-2GB.
Misery for the doctors to get the funds, misery for the doctors to keep the funds and not have to give them back, all the funds taken from the taxpayers.
Oh, and to boot: regulations that stifle innovation and guarantee that medical records software will continue to be developed using long-outdated inefficient methods that produce usability disasters.
do you? for average PC applications (browsing the web, e-mail, office documents) 64 bit gives no advantage. for the above-average applications (multimedia creation/editing, CADD, running multiple VMs, ) it's very helpful.
If it's such a success, why does 64-bit software generally only run marginally faster than its 32-bit build? 64-bit binaries are larger and might run 103% at the speed of 32-bit if you're lucky.
Sure, it helps with the 4GB memory space limit, but so can smart memory management and other approaches.
I could see it being useful for super-computing things, but in general, there still just doesn't seem to be a point.
Wow, just wow. Do you actually work in the software field???
The issue is that medical devices require certified tested/verified drivers to ensure accurate results.
Medical records software is not a medical device. Now, *maybe* the system in question interfaces directly to some medical device, but probably not--most medical records software, *especially* for small practices, does not.
Slashdot Mirror
Oh no, not chemicals! The vast, vast majority of what is pumped is water.
Are you that fucking stupid??? Yes, there's only about 0.5% chemical additives, yes the "vast majority" is water (if you exclude the propants, which are pretty benign). But some of the chemicals are highly toxic, and there's millions of gallons used per fracturing, so you're talking about thousands of gallons of toxic chemicals being pumped into the ground every time.
Widespread contamination has not been demonstrated, but there is as-yet unquantified risk--and examples of contamination.
So to say "it's just water" is either gross ignorance, or lying. Maybe I should visit you and offer you a drink, with the assurance that you'll be fine because it's 99.5% water ;-)
The chemical that they use in fracking is well know. It is very dangerous...
Oh yeh, the chemical they pump into the ground that my friend delivers is commonly known as dihydrous-oxide..
Bull. Fucking. Shit. They add all sorts of chemicals into that water before they pump it into the ground.
Representatives are not Senators.
I'm perfectly well aware of that. What, exactly, is your point?
That's right, all us 14-year-old basement dwellers won, so take that Rep. Mike Rogers! (Take it, and shove it right up your ass, you ignorant fool!)
sources please?
1) freshman physics; 2) the definition of "magnetic domain"--that's what it means.
It is hypothetically possible to recover from a single overwrite, because it is a fact that "magnetic domain remnants" are left after an overwrite.
Incorrect, plain and simple--though it was true 20 years ago. Bits no longer occupy a wide swath of domains only partially set to the current orientation.
In reality however, overwriting magnetic storage with 0s doesn't actually remove the data*.
Yes, it does. 20 years ago it did not, but now it does.
That has nothing to do with the theory of how the data could be recovered. The theory was that flipping a 1 to a 0 is really like applying a "0" magnetic field to a bit that is currently "0.961235", and you end up with "0.015132". Hypothetically, maybe, some could analyze that "0.015132" and determine that it was previously a "0.961235", and reconstruct the data that way.
On the contrary, it has everything to do with it. The theory you mention had to do with the fact that bits were much larger, occupying many domains, and the new write might not flip every domain, thus leaving behind the trace of the prior value. When a bit is a single domain, there is no trace of the prior value.
20 years has not changed the fact that magnetic domains are analog, not digital. "Once you flip it, you've flipped it" isnt a concept that really exists in the analog world until your drive's firmware converts the analog reading to a digital 0.
Magnetic domains do not partially flip. They do go "all or nothing", and there is no "history" of the prior orientation.
If you want to make data non-recoverable from a HD, remove the platters, put them on a drill press and turn them into Swiss cheese with the biggest bit the drill will hold.
Large chunks of data (between the holes) will still be recoverable.
He seemed to me like a proponent of XML. I hope he catches the flu.
X7ML9?
...runs a labaratory device...
Did you actually read what I wrote???
Medical records software is not a medical device. Now, *maybe* the system in question interfaces directly to some medical device, but probably not--most medical records software, *especially* for small practices, does not.
Airport costs should be paid entirely out of ticket sales and associated fees for services, NOT tax money.
They're paid out of taxes on plane tickets.
Um, Canada has had the same prime minister for over five years.
Um, one assumes that on /. one can get away with South Park references ;-)
Disclaimer: I'm a Mac guy working in OS X (which is different yet), so I'm only generally familiar with Windows & Linux VM details. Anyway:
On Windows you can tune the amount of your address space taken by the kernel down
Link? I'm interested to see how that's done.
It's a /3GB switch in boot.ini. Took me a while to find any decent info about it (because in the Windows world there seem to be a bunch of hosers with blogs who don't know the difference between kernel address space and the page file, and google doesn't that know their posts are tripe)--the normal is the even split of 2GB each to kernel and user space, this makes it 1GB to kernel and 3GB to user space.
On Linux, you can't even do that and are stuck with 2GB to start.
Huh? The default 32-bit Linux memory split is 3/1; 3 GiB for userspace, 1 GiB for kernel space. If you compile a custom kernel you can configure this differently.
Did you perhaps swap "Windows" and "Linux" in your comment?
No, I was simply mistaken about the default split on Linux. (And my comment about "can't do that" referred to user-accessible configuration, not building your own kernel...)
I am quite upset with everyone dropping the "alleged" word and referring to them as "the bombers" instead of "the suspects."
That's a legal distinction, binding on the government and prosecutors. There's nothing wrong at all with me, or anyone else, declaring them guilty in the face of their actions in Cambridge/Watertown. They're 100% guilty as hell, and we all know it. The fact that the surviving one will have an opportunity, if he so chooses, to attempt to prove otherwise at a trial is a vitally important part of our attempt to maintain a decent society with respect for individual rights--but it doesn't affect the obviousness of his guilt.
I guess the new new prime minister let them have their horses back ;-)
He's never written anything that's tested the limits of computing...
And he's making invalid assumptions about what ordinary users might need. It's not that 32-bit is enough because most users don't need anything that requires 64-bit, it's that most users have never been offered things that require 64-bit, because they didn't have it. You know what needs more heap than you'll get in 32-bit to work well? According to IBM researchers: voice recognition. Yep, their research finds that being able to keep around 2GB+ enables huge, qualitative improvements. In my own work, I've hit the limit trying to do something simpler: provide really good auto-complete suggestions based on the individual user's corpus of work. Then of course there's all sorts of other searching algorithms, there's a huge difference in usability when you can provide a user a "browsable" interface that responds literally at the speed of thought vs requiring the user to compose the entire query and then wait a few seconds.
Meanwhile, I need only load up my badly coded evolutionary program to see my machine scream at the ~12 GB hit to the RAM. I say badly coded because I have found a few tricks to help get some additional memory savings out of it...also on topic, the aggression level was kind of low, so I imagine future tests might break the 32 GB barrier easily. Currently thinking of giving it a SSD for virtual memory...
So is 64-bit with 64GB in your computer not an option for you?
If you do anything serious with Java, on Windows, because of the memory layout and the insistence of the HotSpot VM on being allocated contiguous stretches of address space, you're limited to about 1.2GB of heap space. When you have a domain that has object counts in the 3 - 5 million region, that fills up rapidly. This is for a big graph of objects and the queries for them involve lots of graph traversal. The code in question can do set queries in about 0.5s that an RDBMS takes over 5 mins to do, so there's a real value to caching all the objects on the heap.
Yes, I could use another language that doesn't have a stupid VM and have ample overhead in 4GB...
Actually, I think you're mistaken about how much more heap space you could get outside of Java. On Windows you can tune the amount of your address space taken by the kernel down and thus, possibly, start with as much as 3GB for user space available to your app. On Linux, you can't even do that and are stuck with 2GB to start. Load your libraries and runtime for *any* language and tool set, and you're not going to have all that much more than 1.2GB. Sure, maybe 1.5GB and on Windows maybe even a bit more. But until you go to 64-bit, you're stuck starting out with 1-2GB.
And are also paid for by taxpayers.
Yep, that too ;-)
Misery for the doctors to get the funds, misery for the doctors to keep the funds and not have to give them back, all the funds taken from the taxpayers.
Oh, and to boot: regulations that stifle innovation and guarantee that medical records software will continue to be developed using long-outdated inefficient methods that produce usability disasters.
do you? for average PC applications (browsing the web, e-mail, office documents) 64 bit gives no advantage. for the above-average applications (multimedia creation/editing, CADD, running multiple VMs, ) it's very helpful.
1) Yes, I do.
2) You are so wrong that it's actually funny.
If it's such a success, why does 64-bit software generally only run marginally faster than its 32-bit build? 64-bit binaries are larger and might run 103% at the speed of 32-bit if you're lucky.
Sure, it helps with the 4GB memory space limit, but so can smart memory management and other approaches.
I could see it being useful for super-computing things, but in general, there still just doesn't seem to be a point.
Wow, just wow. Do you actually work in the software field???
There are several government programs to help practices upgrade software to deal with the new electronic record regulations.
Those programs are a fucking nightmare.
The issue is that medical devices require certified tested/verified drivers to ensure accurate results.
Medical records software is not a medical device. Now, *maybe* the system in question interfaces directly to some medical device, but probably not--most medical records software, *especially* for small practices, does not.
...if you weren't doing the mental equivalent of cowering in your basement even still.
You are truly one nasty sack of shit.