On the Calearth grounds there are many test structures for teaching; lots of families come with kids to learn about the process, and Nader demonstrates the structures' inherent strengths with lessons on smaller domes and arches. It's quite impressive - even with some understanding of engineering - to see a small loose brick arch (no mortar) put together by kids be strong and stable enough to stand on with as many people as can fit.
I spent a day out at Calearth and the structures are fantastic - while the style may not be to everyone's taste (I happen to think they are beautiful), they are extremely sturdy, far exceeding earthquake standards. These buildings are like bomb shelters. The only real problem anyone has mentioned is erosion from the elements, but even then you're not seeing structural weakening - the bags of earth set like cement, and are not going anywhere. In fact, the same technique has been used by Calearth to shore up a weakening reservoir nearby, in a joint project with the Army Corp of Engineers. If they can sit submerged in water 24/7, the only damage a rain is going to do is to the finishing layer that can be replaced, much as you repaint your home from time to time.
I have a ton of pictures but don't want to link for fear of a Slashdotting:)
It was extreme, and I'd never recommend doing that nowadays (nor did I ever do it after my stint at that shop)... but keep in mind, these were huge, beastly, 80MB drives at most and about the size and weight of a small VW (give or take)
Re:Hard Drive in the Freezer
on
Creative Data Loss
·
· Score: 2, Interesting
My first day on my very first tech job - back in the late 80s at a small local shop typical of the day - left me with one indelible impression. My hardware experience was limited at the time, so when they took me back to the repairs room, I made sure to ask what every single thing was, and what it was used for; I got a crash course that day. Anyhow, at some point we get to a place on the wall where there's a nice mini-sized novelty Dodgers baseball bat - solid wood - hanging there, looking well used. I thought it was a joke, and said "what, is that for the really hard cases?" and they proceeded with my training.
My boss took me over to a customer's recently brought in PC, with a big old ugly harddisk just pulled out; said the disk wouldn't spin up, but it wasn't a power or mobo issue, and you could hear the servo in the drive trying a few times before giving up. He told me it was called stiction and was generally very easily solved. He asked me to grab the bat, and give the edge of the drive a few quick raps. At this point I was sure I was being put on, and that my new job was hanging on whether I would do this; I was sure a Candid Camera crew was lurking. Anyhow, after a few reassurances, I gave it a shot; smack, smack, smack! Reinstalled the drive, plugged her in, and nearly as fast as the BIOS could beep we could hear the drive whining up, and sure enough booted and tested out fine!
There were similarly crude techniques for other problems and devices at the time, but that one always stayed with me. It was the day that devices like harddrives were completely de-mystified for me - I had always understood how they worked, but had always held them in some regard as almost mystical, non-mechanical devices. Ever since then they've just been machines to me, with failures that have real, traceable, and even fixable (if you dare) causes.
Treasures exhibits like this are a different story - it's much easier to resell jewels and raw precious materials as they have intrinsic value, and i'm sure the security is a big part of their insurance policy. It's not that most museums can't afford armed guards, but there are big differences between art and jewel shows in this respect.
Re:And the article skips over the human factor...
on
Securing Pricelessness
·
· Score: 1
I would agree in general, from what I've seen. In the museum where I work, however, the guards are treated quite well, they have incessant training and drilling, and though we have a lot of technology to support them, in the end they are the primary defense.
Now, in a major catastrophe, the entire site can be locked down, but that's reactive, won't usually help to prevent an unexpected theft, but is great to secure the collections in case of an earthquake (Los Angeles) or other emergency. I've been through three lock-downs in 4 years there.
I'm not sure how to measure importance of an object versus a human life. However, I can assure you guards in museums - at least in the west - are trained not to get themselves killed. Talk about insurance? Museums are insured against loss, but they are very afraid of any form of lawsuit. I personally know of a case where an act of vandalism was committed and the guards didn't even tackle the guy (admittedly, I was shocked by that, but they've had the fear of liability beat into their working class heads by the staff lawyers).
The problem with moving art is that's when it's most vulnerable. Working in a similarly top-notch museum, I can pretty much assure you that in such a major emergency, nothing is going anywhere.
The biggest risk seems to be takeover robberies these days, as the article aludes to. Museum guards are not typically armed, at least not in public, and they certainly are not trained to resist armed intruders in daylight with visitors around.
Nighttime security is relatively easy - but balancing daylight security with the public's interests (casual, non-militarized galleries) is a toughy. Even in a place like where I work - a heavily fortified site on a easily defended hill overlooking Los Angeles - I can imagine with the right balls and some big guns, you aren't going to be stopped by museum security. You may have the SWAT team responding by the time you hit the gates, but I can imagine a quick exit route or three.
Not that I've ever thought of such things.
But again, other than a few national treasures - the Constitution in DC, several copies of Magna Cart - the risk of moving them in an emergency is not worth it.
Agreed - I wouldn't want to diminish the importance of dcraw either, by the same token, but I have heard this notion going around that Adobe effectively lifted dcraw and does little work themselves on this problem - I know this not to be true. Perhaps I made a snap response to your post based on that.
I'm sick of responding to this one so I'll just say that you clearly have no idea what dcraw does in comparison to Camera RAW. Go try the two out, come back, and tell me how you fared. Show me even an as-shot image processed from dcraw and then from Camera RAW and tell me if the results are the same.
Go read the specs and whitepaper again... DNG will ensure that camera data stored in DNG can be processed by third-party processors with no prior knowledge of the camera model. Of course custom profiling (even per unit) can improve results.
I'm shocked so many people here are arguing for the status quo when that means a continued proliferation of ugly, proprietary data formats.
DNG allows for all current and conceivable mosaic patterns - everything supported in Photoshop CS Camera RAW is easily supported in DNG, and much more.
If a particular camera maker somehow designs a camera that exceeds the DNG spec, and the spec isn't rev'ed to support this for whatever reason, then the camera maker will make a new proprietary RAW format - how is this *worse* than now? At very worst it's no worse.
Yes, DNG supports a huge bitdepth per pixel/channel. Read the spec available on the site - your questions are mostly answered there.
Why the jump to assume these things won't be supported? And what's the logic that having DNG makes these issues more dire? If anything, at least a broad standard reduces the number of exceptions made that lead to new proprietary formats.
Adobe does an enormous amount of work on Camera RAW, far beyond dcraw - if this wasn't the case then dcraw would be as powerful (at least in terms of development) as Camera RAW - it's not even close.
dcraw has provided some code I imagine for deconstructing the file formats - not for creating the "camera profiles" needed to develop linear image data into beautiful non-linear color images that meet users expectations. The output of dcraw has to be manipulated with additional transformations to come close - this is the bulk of the work Adobe has to do and requires more than just a few sample files to decode the file format. Ask Thomas Knoll - this seems to be what he does with much of his time.
There are really two factors affecting RAW formats:
1) The camera-specific mosaicing and bit-depth of their "raw" linear image data; this would not be easily done in any format without major modifications 2) The critical metadata needed in order to develop that image data into a useful digital photograph
DNG addresses both of these issues by standardizing the storage and description of RAW data, and by requiring a base level of metadata necessary for working with them without additional camera-specific knowledge on the software's part.
Adobe can save money with the adoption of DNG - but more money will be saved by smaller developers who cannot do the ongoing reverse engineering that Adobe does to support new RAW formats.
Adobe is leveraging their reverse engineering work in providing the free DNG Converter - this will actually benefit smaller developers more than Adobe, as they will only have to tell their users to download DNG Converter to move their RAW into DNG - the third-parties can focus on supporting DNG and providing excellent processing tools, while Adobe will continue to do the hard work of camera support (until the cameras produce DNG directly - which is of course the long-term goal).
It's an extension to TIFF to support, in a standardized way, the many unique variables that go into a RAW file. No existing specification could capture this range of unique data encoding and metadata without extension - DNG as TIFF was the logical choice for many reasons.
This is not processing RAW into a TIFF - you can do that now with many tools. This is repackaging a RAW file into a new, universal RAW - this should open the RAW processor world to a new level of competition (as the greatest amount of R&D time was always wasted on reverse engineering RAW formats - something Adobe is now doing for you with DNG Converter).
First, PNG is not always indexed. However, it would have required massive extensions to PNG to turn it into something capable of being DNG, and TIFF is already well placed for extension (TIFF is a container format - most people think of it as a simple image format, but it is very flexible and capable of adaptation).
TIFF supports a huge variety of compression modes, including uncompressed, JPEG, LZW, and ZIP, and a variety of color modes.
DNG is an extension to TIFF, to allow the additional properties of a RAW to be expressed without losing the efficiencies of RAW (linear data, typically one color channel per pixel until processing). Just as a for instance - you can take your DNG into most any TIFF reader today and it will at the very least be able to read the preview embedded in the DNG without any mods to your TIFF library.
Many well known photographers, manufacturers, and developers were consulted. However, in a case like this, in the end it takes someone like Adobe taking the bull by the horns - the proliferation of RAW formats was not (and is not) going to be solved by slow-moving standards bodies - this will take a market force demanding adoption by the many stakeholders, who have not even shown interest in the problems let alone investing in a solution.
Preservation of digital photography in RAW formats is an ugly challenge and kudos to Adobe for taking the lead in a very serious issue. This is not a marketing ploy - in fact, if you understand the effort you'll see it's a very open attempt, and in some ways will be subsidized by Adobe - for instance, their DNG Converter will continue to provide the capability to convert any RAW format they support into DNG, leaving other DNG developers to focus on the act of processing DNG images and not on reverse engineering every new model camera's RAW format.
This format is not about replacing PNG, and no PNG does not provide the capabilities to do what DNG is about.
DNG is about unifying the mess of "RAW" formats - camera-specific proprietary file formats containing raw dumps of unprocessed sensor information and shot metadata.
Furthermore, DNG is not immediately about getting camera manufacturers to use it themselves - though that would be the ideal. DNG is a bridge format - something you can convert all of your RAW files to for the purposes of long-term preservation/storage. It is open and documented, and based on TIFF so there are existing reader libraries that can handle the basic format (they will need extensions to do anything with it of course).
Adobe has provided DNG Converter which will enable anyone - even non-Adobe users - to benefit from the ongoing R&D Adobe does to support the variety of RAW formats out there. This will simplify the task of building quality RAW converters by allowing small developers to focus on excellent RAW processing and not have to exert to support the many camera RAW formats out there.
Sorry, I just woke up so I'm not going to touch on everything - but this is a major announcement whose importance will become more clear in time.
I completely disagree - the only thing unique about Konfabulator was the sexy look, and much of that is inspired by OSX itself.
ControlStrip on the classic Mac OS, DesktopX, and many other projects have provided lightweight "applets" in various ways for years. In fact, these are also quite similar to the menu bar applets on OSX, though now liberated from the cramped menu bar.
What are the "rights of small developers"? Which aspect of Konfab is unique in the scope of computing? This reeks of the Watson/Sherlock "controversy", but only in that a developer creates a relatively sexy but not novel UI, and Apple eventually adopts a similar approach to solve the same problems for its users.
It's hard to define where Apple should stop and third-party tools should begin. I see people confusing superficial similarities for innovation being crushed - at what point does Apple stop improving OSX and require its users to buy third-party products?
There will no doubt be others crying about the RSS aggregator, but again these are similar solutions because they are solving the same problems for users. Should Apple just stick to the desktop and the Dock and leave all future goodness to shareware authors?
I love shareware on OSX, I support it religiously, but at some point there has to be an acknowledgement that OS vendors will encroach as user needs are identified. I would love to see Apple develop a grant program or something similar, to honor those developers who lead the way, but I don't think it's an option to just hold back the OS.
Right, I've never actually succeeded by following those directions explicitly. I'd recommend trying to satisfy the dependencies via Fink, at which point you should have an environment ready for Evolution to build.
Originally I found hints at http://primates.ximian.com/~aaron/doing/evo-osx.ht ml... if you've got the dependencies handled through Fink (fink install bundle-gnome should do it), any recent Evolution tarball should build easily, IIRC.
Slashdot Mirror
On the Calearth grounds there are many test structures for teaching; lots of families come with kids to learn about the process, and Nader demonstrates the structures' inherent strengths with lessons on smaller domes and arches. It's quite impressive - even with some understanding of engineering - to see a small loose brick arch (no mortar) put together by kids be strong and stable enough to stand on with as many people as can fit.
Of course they haven't, this is Slashdot.
:)
I spent a day out at Calearth and the structures are fantastic - while the style may not be to everyone's taste (I happen to think they are beautiful), they are extremely sturdy, far exceeding earthquake standards. These buildings are like bomb shelters. The only real problem anyone has mentioned is erosion from the elements, but even then you're not seeing structural weakening - the bags of earth set like cement, and are not going anywhere. In fact, the same technique has been used by Calearth to shore up a weakening reservoir nearby, in a joint project with the Army Corp of Engineers. If they can sit submerged in water 24/7, the only damage a rain is going to do is to the finishing layer that can be replaced, much as you repaint your home from time to time.
I have a ton of pictures but don't want to link for fear of a Slashdotting
Yeah, let's link to radio or television.
Which part of "mod" don't you understand? What you describe would simply not be a mod.
It was extreme, and I'd never recommend doing that nowadays (nor did I ever do it after my stint at that shop)... but keep in mind, these were huge, beastly, 80MB drives at most and about the size and weight of a small VW (give or take)
My first day on my very first tech job - back in the late 80s at a small local shop typical of the day - left me with one indelible impression. My hardware experience was limited at the time, so when they took me back to the repairs room, I made sure to ask what every single thing was, and what it was used for; I got a crash course that day. Anyhow, at some point we get to a place on the wall where there's a nice mini-sized novelty Dodgers baseball bat - solid wood - hanging there, looking well used. I thought it was a joke, and said "what, is that for the really hard cases?" and they proceeded with my training.
My boss took me over to a customer's recently brought in PC, with a big old ugly harddisk just pulled out; said the disk wouldn't spin up, but it wasn't a power or mobo issue, and you could hear the servo in the drive trying a few times before giving up. He told me it was called stiction and was generally very easily solved. He asked me to grab the bat, and give the edge of the drive a few quick raps. At this point I was sure I was being put on, and that my new job was hanging on whether I would do this; I was sure a Candid Camera crew was lurking. Anyhow, after a few reassurances, I gave it a shot; smack, smack, smack! Reinstalled the drive, plugged her in, and nearly as fast as the BIOS could beep we could hear the drive whining up, and sure enough booted and tested out fine!
There were similarly crude techniques for other problems and devices at the time, but that one always stayed with me. It was the day that devices like harddrives were completely de-mystified for me - I had always understood how they worked, but had always held them in some regard as almost mystical, non-mechanical devices. Ever since then they've just been machines to me, with failures that have real, traceable, and even fixable (if you dare) causes.
Treasures exhibits like this are a different story - it's much easier to resell jewels and raw precious materials as they have intrinsic value, and i'm sure the security is a big part of their insurance policy. It's not that most museums can't afford armed guards, but there are big differences between art and jewel shows in this respect.
I would agree in general, from what I've seen. In the museum where I work, however, the guards are treated quite well, they have incessant training and drilling, and though we have a lot of technology to support them, in the end they are the primary defense.
Now, in a major catastrophe, the entire site can be locked down, but that's reactive, won't usually help to prevent an unexpected theft, but is great to secure the collections in case of an earthquake (Los Angeles) or other emergency. I've been through three lock-downs in 4 years there.
I'm not sure how to measure importance of an object versus a human life. However, I can assure you guards in museums - at least in the west - are trained not to get themselves killed. Talk about insurance? Museums are insured against loss, but they are very afraid of any form of lawsuit. I personally know of a case where an act of vandalism was committed and the guards didn't even tackle the guy (admittedly, I was shocked by that, but they've had the fear of liability beat into their working class heads by the staff lawyers).
The problem with moving art is that's when it's most vulnerable. Working in a similarly top-notch museum, I can pretty much assure you that in such a major emergency, nothing is going anywhere.
The biggest risk seems to be takeover robberies these days, as the article aludes to. Museum guards are not typically armed, at least not in public, and they certainly are not trained to resist armed intruders in daylight with visitors around.
Nighttime security is relatively easy - but balancing daylight security with the public's interests (casual, non-militarized galleries) is a toughy. Even in a place like where I work - a heavily fortified site on a easily defended hill overlooking Los Angeles - I can imagine with the right balls and some big guns, you aren't going to be stopped by museum security. You may have the SWAT team responding by the time you hit the gates, but I can imagine a quick exit route or three.
Not that I've ever thought of such things.
But again, other than a few national treasures - the Constitution in DC, several copies of Magna Cart - the risk of moving them in an emergency is not worth it.
Agreed - I wouldn't want to diminish the importance of dcraw either, by the same token, but I have heard this notion going around that Adobe effectively lifted dcraw and does little work themselves on this problem - I know this not to be true. Perhaps I made a snap response to your post based on that.
Best,
BB
Ahh, I love how these things get started.
I'm sick of responding to this one so I'll just say that you clearly have no idea what dcraw does in comparison to Camera RAW. Go try the two out, come back, and tell me how you fared. Show me even an as-shot image processed from dcraw and then from Camera RAW and tell me if the results are the same.
Go read the specs and whitepaper again... DNG will ensure that camera data stored in DNG can be processed by third-party processors with no prior knowledge of the camera model. Of course custom profiling (even per unit) can improve results.
I'm shocked so many people here are arguing for the status quo when that means a continued proliferation of ugly, proprietary data formats.
DNG allows for all current and conceivable mosaic patterns - everything supported in Photoshop CS Camera RAW is easily supported in DNG, and much more.
If a particular camera maker somehow designs a camera that exceeds the DNG spec, and the spec isn't rev'ed to support this for whatever reason, then the camera maker will make a new proprietary RAW format - how is this *worse* than now? At very worst it's no worse.
Yes, DNG supports a huge bitdepth per pixel/channel. Read the spec available on the site - your questions are mostly answered there.
Why the jump to assume these things won't be supported? And what's the logic that having DNG makes these issues more dire? If anything, at least a broad standard reduces the number of exceptions made that lead to new proprietary formats.
Adobe does an enormous amount of work on Camera RAW, far beyond dcraw - if this wasn't the case then dcraw would be as powerful (at least in terms of development) as Camera RAW - it's not even close.
dcraw has provided some code I imagine for deconstructing the file formats - not for creating the "camera profiles" needed to develop linear image data into beautiful non-linear color images that meet users expectations. The output of dcraw has to be manipulated with additional transformations to come close - this is the bulk of the work Adobe has to do and requires more than just a few sample files to decode the file format. Ask Thomas Knoll - this seems to be what he does with much of his time.
There are really two factors affecting RAW formats:
1) The camera-specific mosaicing and bit-depth of their "raw" linear image data; this would not be easily done in any format without major modifications
2) The critical metadata needed in order to develop that image data into a useful digital photograph
DNG addresses both of these issues by standardizing the storage and description of RAW data, and by requiring a base level of metadata necessary for working with them without additional camera-specific knowledge on the software's part.
Yeah, well, color me shocked. People on Slashdot jumping the gun? Spouting off on issues they haven't researched? Unheard of.
Adobe can save money with the adoption of DNG - but more money will be saved by smaller developers who cannot do the ongoing reverse engineering that Adobe does to support new RAW formats.
Adobe is leveraging their reverse engineering work in providing the free DNG Converter - this will actually benefit smaller developers more than Adobe, as they will only have to tell their users to download DNG Converter to move their RAW into DNG - the third-parties can focus on supporting DNG and providing excellent processing tools, while Adobe will continue to do the hard work of camera support (until the cameras produce DNG directly - which is of course the long-term goal).
It's an extension to TIFF to support, in a standardized way, the many unique variables that go into a RAW file. No existing specification could capture this range of unique data encoding and metadata without extension - DNG as TIFF was the logical choice for many reasons.
This is not processing RAW into a TIFF - you can do that now with many tools. This is repackaging a RAW file into a new, universal RAW - this should open the RAW processor world to a new level of competition (as the greatest amount of R&D time was always wasted on reverse engineering RAW formats - something Adobe is now doing for you with DNG Converter).
DNG *is* TIFF.
First, PNG is not always indexed. However, it would have required massive extensions to PNG to turn it into something capable of being DNG, and TIFF is already well placed for extension (TIFF is a container format - most people think of it as a simple image format, but it is very flexible and capable of adaptation).
TIFF supports a huge variety of compression modes, including uncompressed, JPEG, LZW, and ZIP, and a variety of color modes.
DNG is an extension to TIFF, to allow the additional properties of a RAW to be expressed without losing the efficiencies of RAW (linear data, typically one color channel per pixel until processing). Just as a for instance - you can take your DNG into most any TIFF reader today and it will at the very least be able to read the preview embedded in the DNG without any mods to your TIFF library.
Many well known photographers, manufacturers, and developers were consulted. However, in a case like this, in the end it takes someone like Adobe taking the bull by the horns - the proliferation of RAW formats was not (and is not) going to be solved by slow-moving standards bodies - this will take a market force demanding adoption by the many stakeholders, who have not even shown interest in the problems let alone investing in a solution.
Preservation of digital photography in RAW formats is an ugly challenge and kudos to Adobe for taking the lead in a very serious issue. This is not a marketing ploy - in fact, if you understand the effort you'll see it's a very open attempt, and in some ways will be subsidized by Adobe - for instance, their DNG Converter will continue to provide the capability to convert any RAW format they support into DNG, leaving other DNG developers to focus on the act of processing DNG images and not on reverse engineering every new model camera's RAW format.
This format is not about replacing PNG, and no PNG does not provide the capabilities to do what DNG is about.
DNG is about unifying the mess of "RAW" formats - camera-specific proprietary file formats containing raw dumps of unprocessed sensor information and shot metadata.
Furthermore, DNG is not immediately about getting camera manufacturers to use it themselves - though that would be the ideal. DNG is a bridge format - something you can convert all of your RAW files to for the purposes of long-term preservation/storage. It is open and documented, and based on TIFF so there are existing reader libraries that can handle the basic format (they will need extensions to do anything with it of course).
Adobe has provided DNG Converter which will enable anyone - even non-Adobe users - to benefit from the ongoing R&D Adobe does to support the variety of RAW formats out there. This will simplify the task of building quality RAW converters by allowing small developers to focus on excellent RAW processing and not have to exert to support the many camera RAW formats out there.
Sorry, I just woke up so I'm not going to touch on everything - but this is a major announcement whose importance will become more clear in time.
I completely disagree - the only thing unique about Konfabulator was the sexy look, and much of that is inspired by OSX itself.
ControlStrip on the classic Mac OS, DesktopX, and many other projects have provided lightweight "applets" in various ways for years. In fact, these are also quite similar to the menu bar applets on OSX, though now liberated from the cramped menu bar.
What are the "rights of small developers"? Which aspect of Konfab is unique in the scope of computing? This reeks of the Watson/Sherlock "controversy", but only in that a developer creates a relatively sexy but not novel UI, and Apple eventually adopts a similar approach to solve the same problems for its users.
It's hard to define where Apple should stop and third-party tools should begin. I see people confusing superficial similarities for innovation being crushed - at what point does Apple stop improving OSX and require its users to buy third-party products?
There will no doubt be others crying about the RSS aggregator, but again these are similar solutions because they are solving the same problems for users. Should Apple just stick to the desktop and the Dock and leave all future goodness to shareware authors?
I love shareware on OSX, I support it religiously, but at some point there has to be an acknowledgement that OS vendors will encroach as user needs are identified. I would love to see Apple develop a grant program or something similar, to honor those developers who lead the way, but I don't think it's an option to just hold back the OS.
Right, I've never actually succeeded by following those directions explicitly. I'd recommend trying to satisfy the dependencies via Fink, at which point you should have an environment ready for Evolution to build.
Originally I found hints at http://primates.ximian.com/~aaron/doing/evo-osx.ht ml... if you've got the dependencies handled through Fink (fink install bundle-gnome should do it), any recent Evolution tarball should build easily, IIRC.