RPGs and AK-47s aren't doing anything to tanks. It's old Soviet artillery shells and the millions of tons of military explosives that they contain that are.
There isn't enough explosive in an RPG warhead to punch through a main battle tank's armor; but it's fairly trivial to bury enough in the dirt to blow it sky high and detonate when the tank drives over it.
Probably you could, but that's a significant gain in itself. You've just tripled the work that it takes to destroy the target; actually more than tripled, since firing three anti-tank weapons simultaneously from three different directions isn't exactly simple. You have to have some way of coordinating the attack, and you'd have to fire them at almost exactly the same time -- I assume the response time of the point defense system is quite fast, so if any of the weapons were lagging it would give the system an opportunity to destroy them. That necessitates not only firing them simulatenously but also having each launcher approximately the same distance from the target.
That said, I'm not sure that this system is really in touch with current threats. Most large-vehicle losses that I've seen on TV anyway don't seem to have come from RPGs, they've come from remote-detonated buried explosives. All the point defenses in the world aren't going to do anything to defeat those.
Not all programmers are peacenik hippies, you know. Even Linux ones.
I know of several Linux programmers that would probably slaver over the opportunity to program a giant killing machine. (Although perhaps only if it walked and shot lasers and was 50 feet tall. They might not be down with programming an uncool killing machine. I'll have to ask.)
On a more serious note, do you really think that IBM, HP, Sun, and all the rest of the companies that have paid into and supported this Linux thing would continue to do so if there was such a 'no military use' clause? If you think so, then you have no idea how much of many of those companies revenues come from government contracts, particularly defense ones. Do you think the NSA would help to secure it? I bet even NASA wouldn't touch it. (Most of their contractors who do the majority of the work wouldn't be able to, since a lot of them do a ton of military work on the side.)
And what is "military use" anyway? Is running a logistics or inventory management system 'military use,' if the inventory being managed is bombs and bullets? What if it's just MREs? What if it's a payroll system for military personnel? How about civilian contractors? Could you use it to run a firewall--if that firewall was in a missile silo?
Anyone who wanted to make a commercial software product and even had the dimmest hopes of ever selling it to government wouldn't be able to use any code under such a license. Not to mention the public-image damage you'd do by associating Linux with yet another political philosophy; as if Free Software isn't controversial enough to sell to management, you want to make sure that there's absolutely no chance that it's taken seriously?
It would be the best thing in the world for BSD, though...
I didn't realize you were responding to an AC there for a minute... I was pretty impressed; you would have taken online schizophrenia to a new level, even for Slashdot.
Although the author of TFA could have been a lot more clear, in his defense he does explain this (admittedly in a roundabout way):
The scheduler maintains a number of internal tables to manage the context of every running task in the system. It also manages resources using a pair of queues known as the run queue and the sleep queue. The run queue is where tasks that have all of their resources available are held. The sleep queue is for tasks that are waiting for one or more resources to be available.
He could have been a little more clear when he was talking about interpreting the output from ps, but it's not like he completely forgot to explain the concept.
Negative numbers (down to -19) have the highest priority, and positive numbers have the lowest priority. Yes, it's backwards and nonsensical and I can only assume that some programmer somewhere is having a good laugh at everyone who's ever been confused by it.
I personally haven't ever used "nice" on my Mac -- most of the stuff I launch from the commandline isn't that processor-intensive. I do use "renice" a lot, which modifies the priority of a process that's already running. So I think that would be what you'd use, if you wanted to bump Handbrake or something to a lower priority. (Not that I know from personal experience what Handbrake is, or does, or anything, *cough*)
I'm not sure if "renice" comes with OS X by default or whether I had to install it at some point.
I think this problem is why version control systems like CVS were invented. However, according to at least one document I've read, Linux does support locking at the filesystem level, both at the whole-file level and also byte ranges. But you're right, it's not rigidly enforced on applications. If you have the right permissions, you can probably clobber or change a file that's open somewhere else. I can't say I've really experimented with this heavily, myself.
According to this document, "Starting with 1.3, Linux now supports two types of file locks. One is flock locking, where a process can request to lock the entire file, and the other is POSIX locking, where it can lock specific regions of a file.... However, these locks are only advisory. That means they're a convention, just like the lockfile-based file locking."
More interestingly is a quote (apparently a comment from the kernel source):
* NOTE:
* I do not intend to implement mandatory locks unless demand is
* *HUGE*. They are not in BSD, and POSIX.1 does not require them.
* I have never seen any public code that relied on them. As Kelly
* Carmichael suggests above, mandatory locks requires lots of changes
* elsewhere and I am reluctant to start something so drastic for so
* little gain.
* Andy Walker (andy@keo.kvaerner.no), June 09, 1995
What's changed since 1995, if anything, I wonder?
At any rate, the majority of UNIX machines these days aren't used for direct shell access, but probably run filesharing protocols like CIFS/Samba or AFP/netatalk, which have their own file-locking systems on the exported volumes. (I'm not sure whether they use the Linux advisory locking to accomplish this. I also wonder what happens if you have the same volume exported by both Samba and netatalk in regards to locking when both a Samba user and a netatalk user try to modify something.)
The difference between rsync and rdiff is that rsync only keeps the most recent copy in each location (local and remote), overwriting old versions, while rdiff gives you space-efficient point-in-time snapshots. It can do what rsync does, but it can also give you incrementals.
Read below for my solution that provides bidirectional syncing with rsync.
You just sync from local to remote, then remote to local. Rsync is smart enough not to send anything over the wire that hasn't changed, so if someone hasn't modified anything on the remote end, then the second command will not transfer anything.
What you effectively get out of this though is a filesystem where you can't delete anything (if it's there long enough to get synced once) unless you go and delete it locally and remotely. If you let a file get sync'd to the remote server, then delete the local copy, it will reappear on the next sync. It seems to me that any bidirectional syncronization solution is going to have this issue though; otherwise it wouldn't really be bidirectional sync'ing.
Minolta makes (or made, as a discontinued product from a now-defunct company I guess the past tense is safe) a neat negative scanner that would take 35mm and medium format, I think it was called the Multi Pro. Their naming conventions have always escaped me, I think the "Dual" model in each new series is the 35mm/APS model and the "Multi" indicates medium format capabilities. So there were several different versions of it with different sensors, I think the last model was made in 2005: Review here http://www.kenrockwell.com/minolta/mp.htm
I looked at it for a while, but eventually picked up a used 35mm scanner and a high-quality flatbed with a transparency adapter separately for less than the Minolta was costing at the time. However, you might be able to get a gently used one now for a good price, and it would keep you from having to have two devices. In retrospect I wish I had sprung for the Multi Pro, and who knows maybe I still will.
For the 126, 117 and 110 stuff you'd probably have to build some sort of jig, but I don't think that would be very hard. I'd suggest using some strip styrene from any hobby store, and then cutting out holes as necessary using an X-Acto knife. The only thing you'd need to be very careful about is that you didn't leave any sharp edges that would scratch the negatives.
It might be a bit much for most people's level of interest, but at the very least I would suggest scanning ANYTHING that looks like it has informational value. If there's writing on the backs of the photos, scan the backs. (Frame numbers, name of the drugstore it was printed at--common with stuff from the 50s and earlier, handwritten notes, etc.)
But I wouldn't just stop at photos, I'd also suggest scanning the envelopes that the photos are in, and anything else that's in there with them. It's not as good as providing a description for every photo, but it at least retains a lot more than just scanning the photos themselves and ignoring any context. (Actually I would do this even if I was adding a total braindump of everything I knew about every photo to the scans.) In fact, if you have a digital camera, it might be worthwhile if you're scanning a box of photos or old photo album, to take some general pictures of the album or box. It might not seem relevant to you, but some relative down the road might not remember "Dad's Photo Album" but might remember "the big ugly blue photo album with the ducks on it." (Don't laugh, I have one that fits that description.)
I keep the raw scans of my photos and negatives just in one large directory, named according to xx-yy[F,B].tif where xx is the roll number, yy is the frame number, and after the frame number I use letters to indicate F or B for front/back, and sometimes A,B,C,D to indicate multiple versions or scans of a file. (Sometimes I'll scan a negative a few times with varying brightness settings to make sure I get the highlights and the shadows, because the scanner has less dynamic range than the film.)
Actually I heard someone propose a photo-scanning service that used offshored labor for the more repetitive tasks (I think this might have been in reference to scanning books), but the real problem is transportation. I think you're going to lose the advantage when you factor in the cost of FedExing all those photos to India or China or wherever, just to have somebody sit there and scan every one.
Plus, I've seen enough negatives and prints get lost just going from the minilab where I used to work, to the big Kodak outlab processing center in the next city and back. And that was handled by a private courier service. It's a pretty accepted piece of wisdom in the photo industry that once you lose somebody's negatives, you've lost them as a customer. I can't imagine what the loss rate would be of a service that had to ship everything to China.
And yes, I'm aware you were joking.:)
Perhaps a better option would be to use illegals? Bring the slave labor to the work, instead of the other way around.
Are you talking about scanning negatives or scanning prints?
$10 for 40 negatives makes sense (although personally I think it's a bit steep -- most WalMarts have Fuji Frontier series equipment, and a brain-damaged monkey could scan negatives on that; the trick is dust and quality control) but I'm not sure why you'd say anything like an "8x10" scan.
Saying "8x10" makes me think that they're cropping the frame to an 8x10 aspect ratio, which is different than a 35mm film frame -- the film is much longer than an 8x10 (35mm is actually closer to 8x12, or 2:3) -- so if they're doing that, you're losing a significant amount of information.
I think there's another avenue here that people aren't considering: organize and protect the negatives. Aside from the portable hard drive, and perhaps the DVDs (depending on how you did the digitization), a binder full of 35mm negatives in archival sheets have a very high information density.
Since they are the originals -- the true originals, not 1st generation copies like prints -- you have all the information needed to reconstruct prints at a later date. Physically, they're quite robust: I'd say they're on par with CD-Rs in terms of resistance to damage, properly stored. (I'm talking about negatives in sheets here, not kept in crummy little paper envelopes or whatever other horrible ways people tend to store them.)
If you assume that each frame is equivalent to a 60MB scan, which is what I'd say is sufficient to even have a shot at extracting the majority of the information from it, an 8x10 sheet of negatives (35 frames on mine) holds around 2,100 MB of information. By weight, I think that's probably ahead of CDs and close to DVDs. And you can put a whole lot of negative sheets into a 3" binder.
I'm not suggesting that a binder of negatives be your only backup option, but if you're going to go to the work of sorting through your photos anyway, it makes sense to pull out those negatives, put them in sheets, put the sheets in a binder, and put the binder somewhere safe. In fact, if you make digital copies, then you can keep the negatives off-site somewhere.
It might not help you too much if your house is totally destroyed (although I have mine in a cabinet next to my "go bag"; if I leave town in a hurry, it's going with me), but I just think that it's wise to remember that your old film photos already have a 'backup copy,' and that sometimes those analog backups are the best kind.
My question on the procedure isn't the resolution, it's the ease of use. Seems like it would be easier to just plop the prints face-down on a flatbed scanner and hit "Scan" than to set up what's essentially a homebrew copystand.
I've used a real copy-stand quite a bit for making 35mm slides from flat-work, and it's not exactly a brainless procedure. I wouldn't recommend doing it without white balancing, because otherwise your color could be all off, and while it has its place -- particularly if you want to digitize something from a book or other object that does't lend itself well to being smushed down on a flatbed, I question if it's the simplest route.
Why take photos instead of just using a $99 flatbed? Either way gets you enough resolution to see the film grain, it just seems like the former is unnecessarily complicated.
If the negative was saved as a.bmp file, it created a 36 MB file - the.jpg version was 2 or 3 MB.
I hope, therefore, that you chose to save them as BMPs... that file size ought to have been an indication of how much information it was throwing away in the JPG versions.
A while back here on Slashdot there was a discussion of what file format people would want to use for archival purposes -- really long-term storage, not just a few years or decades. There were some very convincing arguments for using plain-old 24-bit RGB bitmaps, since it's reasonably easy to build a reader for them, even if the format was otherwise dead. Interpreting a JPEG file without a reader...now that would be a challenge.
If you're really short on space, I think it's a better idea in principle to save to an uncompressed, non-lossy format and then compress the resulting files separately using some sort of well-documented algorithm. Still not as safe as just having BMP files, but I think you'd have a better chance of letting somebody down the road recover them without specialized tools. At least you'd be breaking the recovery problem into two separate and less-complex operation rather than into one huge format to unlock.
You might find it easiest to make up a 4x6 template, some bright lights, a glass coversheet, 2x polarizers and shoot thru the glass with a macro lense and capture a 6mp image of the 4x6.
I'm somewhat confused. Why is this method superior to using a device that's designed for digitizing flat work? Most inexpensive scanners can get 6MP from a 4x6 (that's less than 600 dpi), although frankly for dimestore/commercially printed 35mm prints I think that sort of resolution is overkill. You're going to be looking at film or paper grain at much more than 300 dpi. It would have to be a pretty high quality print to justify scanning it at 600 dpi, unless you're just burning storage space for fun.
Works just fine for me. You just need to go into Sharing, turn on Remote Desktop, and then I think under options you need to enable VNC access in addition to ARD. There are also some other options in there (set password, etc.). It's not difficult.
I've had no trouble at all connecting from my Windows machine at work; the only thing I've run into is that I need to leave the connection settings on the client to "Auto," and that it will only use 32-bit color, it just crashes if I select anything less. So if you don't have a good connection, it might be a good idea to run a more lightweight implementation -- but just as something that you could talk someone else through enabling so that you could remote administrate, it's great.
That doesn't quite make sense. If anything, the debt should make China more dependent on the US than the other way around, since they traded a whole lot of hard currency for some pieces of paper that are only worth anything because the US Treasury says so. If the US defaulted (not bloody likely, but speaking theoretically), they would be the ones left holding the bag. At that point it would become a question of what they'd do to make the US pay up -- they can't exactly send someone over to break our kneecaps.
However, the GP's question is still valid: there are a lot of countries that pull the free-trade card when it comes to having access to US markets, but are still staunchly protectionist when it comes to their domestic markets and industries. China, even Japan is like this to a certain extent; even some of the Western European countries (I'm looking at you, France) have "non tariff barriers" to trade that are really protectionism clothed in various regulatory outfits.
I suppose the US plays along because it's good for business to do so, at least in the short run. Whether building up the sort of trade and current-accounts deficit that we have is a good idea in the long run, I'm not so sure.
I used to wonder the same thing. The closest I've ever heard to an explanation is that Blackberry's "product" is less the little handsets but the infrastructure that the cellular carriers use to provide email service. Apparently BB is very easy to deploy, and they have patents on some rather vague concepts regarding (don't quote me on this exactly) where the email is cached. I think the crux of it is that when a cell carrier deploys a BB system, they don't have to dick around with actually running the mailservers or anything else; it's a very holistic/'total package' type solution from their perspective.
Now why somebody else doesn't just make a similar network and market it to the cell carriers, I'm not sure. That's where I'm betting the patents come in. But I think BB has sold itself to the cell carriers as being easier to implement and maintain than a roll-your-own solution, and their handsets and all-you-can-eat pricing (versus SMS) have gotten them a good userbase and the associated name recognition.
If anyone can elaborate on exactly how the BB system works, I would be interested.
Pity there's no functional screen-top, context sensitive menubar, though.
Right now I'm using Kubuntu and it's not exactly the world's most stable piece of software; I'd like to use Gnome, but they insist on using Windows-style menubars for everything. It's a crummy design[1] and I don't understand the resistance to having alternatives like KDE does.
[1] If you like it, more power to you; I think they suck and just want a choice, I don't care if you use it or not. The only good argument I've heard in favor of window-top menubars is that they're easier to use with multiple monitors, but really I think Linux could outdo MacOS in this respect and have an application's menubar jump to the top of the screen on which it was located, if people were bothered by this.
I don't know how PCs handle this, but on my PowerMac G5, there is actually a daemon that controls the fan and pump speeds in response to various temperature measurments. (There are some absurd number of temp sensors inside the case, off the top of my head there are sensors for each CPU core, the GPU, heatsink, intake air, hard drive bay, and back side of the motherboard / memory controller.)
It's possible to kill the daemon or boot up without launching it, but in the event of this, the hardware has a "fail safe" mode where all the fans go to max RPM immediately and stay there. Assuming none of the vents are blocked, this is enough to keep the system from overheating. (Actually it's more than enough, even fully loaded I can't get the fans to rev up that high under normal conditions; there is definitely some excess cooling capacity at room temperature.) I think it will also enter this mode if the daemon allows the temperatures to exceed a certain range, so that a "bad" or compromised daemon (i.e., if you got hacked) couldn't tell the fans to just shut off and let the cores melt.
So while there is software control of the cooling system, the hardware is designed so that you can't (easily) cause physical damage through software control.
It definitely is interesting though that we have gotten home computers to the level where they require this much self-protection in order to operate. I was looking inside mine and thinking how much like a car it is; basically it has a set of big fans that suck in air and blow it over a liquid-filled radiator. I wonder if people had similar reactions the first time they saw a liquid-cooled gasoline engine--wondering whether it was a good idea to design something that would destroy itself if the cooling system failed to function.
I could think of a few other ways to cause an overheat which aren't necessarily physical console access. They're not really remote exploits either, but let's say the target was in a datacenter. Even if you couldn't get into the datacenter, maybe you could interfere with the air conditioning equipment. (Which is usually outside / on the roof and less secure than the data equipment itself.) Or more simply perhaps, bribe/convince a janitor or someone in physical plant operations to divert or shut down cooling to a particular area after hours. Not to mention (against a desktop PC) the BOFH-style "air filter" attack. The point is, there are ways to make a system overheat that are potentially easier than compromising it in some other way might be, or less obvious than them. Having a system overheat, shut down, and then return to normal operation might not raise too many red flags, compared to discovering a keylogger or tap; it might get treated as an infrastructure problem rather than a possible break-in, delaying discovery.
It's probably not something that some guy in his basement in Russia is going to do to you, but if you have valuable information on a computer, it's another avenue of attack that you have to defend against, or at least be aware of.
Slashdot Mirror
RPGs and AK-47s aren't doing anything to tanks. It's old Soviet artillery shells and the millions of tons of military explosives that they contain that are.
There isn't enough explosive in an RPG warhead to punch through a main battle tank's armor; but it's fairly trivial to bury enough in the dirt to blow it sky high and detonate when the tank drives over it.
Probably you could, but that's a significant gain in itself. You've just tripled the work that it takes to destroy the target; actually more than tripled, since firing three anti-tank weapons simultaneously from three different directions isn't exactly simple. You have to have some way of coordinating the attack, and you'd have to fire them at almost exactly the same time -- I assume the response time of the point defense system is quite fast, so if any of the weapons were lagging it would give the system an opportunity to destroy them. That necessitates not only firing them simulatenously but also having each launcher approximately the same distance from the target.
That said, I'm not sure that this system is really in touch with current threats. Most large-vehicle losses that I've seen on TV anyway don't seem to have come from RPGs, they've come from remote-detonated buried explosives. All the point defenses in the world aren't going to do anything to defeat those.
Not all programmers are peacenik hippies, you know. Even Linux ones.
I know of several Linux programmers that would probably slaver over the opportunity to program a giant killing machine. (Although perhaps only if it walked and shot lasers and was 50 feet tall. They might not be down with programming an uncool killing machine. I'll have to ask.)
On a more serious note, do you really think that IBM, HP, Sun, and all the rest of the companies that have paid into and supported this Linux thing would continue to do so if there was such a 'no military use' clause? If you think so, then you have no idea how much of many of those companies revenues come from government contracts, particularly defense ones. Do you think the NSA would help to secure it? I bet even NASA wouldn't touch it. (Most of their contractors who do the majority of the work wouldn't be able to, since a lot of them do a ton of military work on the side.)
And what is "military use" anyway? Is running a logistics or inventory management system 'military use,' if the inventory being managed is bombs and bullets? What if it's just MREs? What if it's a payroll system for military personnel? How about civilian contractors? Could you use it to run a firewall--if that firewall was in a missile silo?
Anyone who wanted to make a commercial software product and even had the dimmest hopes of ever selling it to government wouldn't be able to use any code under such a license.
Not to mention the public-image damage you'd do by associating Linux with yet another political philosophy; as if Free Software isn't controversial enough to sell to management, you want to make sure that there's absolutely no chance that it's taken seriously?
It would be the best thing in the world for BSD, though...
Did Clippy touch you in the naughty place? It's okay, you're among friends here.
Actually this whole situation reminds me of a very different story; this one's British.
I didn't realize you were responding to an AC there for a minute ... I was pretty impressed; you would have taken online schizophrenia to a new level, even for Slashdot.
I think you're off by a factor of -1.
Negative numbers (down to -19) have the highest priority, and positive numbers have the lowest priority. Yes, it's backwards and nonsensical and I can only assume that some programmer somewhere is having a good laugh at everyone who's ever been confused by it.
I personally haven't ever used "nice" on my Mac -- most of the stuff I launch from the commandline isn't that processor-intensive. I do use "renice" a lot, which modifies the priority of a process that's already running. So I think that would be what you'd use, if you wanted to bump Handbrake or something to a lower priority. (Not that I know from personal experience what Handbrake is, or does, or anything, *cough*)
I'm not sure if "renice" comes with OS X by default or whether I had to install it at some point.
According to this document, "Starting with 1.3, Linux now supports two types of file locks. One is flock locking, where a process can request to lock the entire file, and the other is POSIX locking, where it can lock specific regions of a file.
More interestingly is a quote (apparently a comment from the kernel source):What's changed since 1995, if anything, I wonder?
At any rate, the majority of UNIX machines these days aren't used for direct shell access, but probably run filesharing protocols like CIFS/Samba or AFP/netatalk, which have their own file-locking systems on the exported volumes. (I'm not sure whether they use the Linux advisory locking to accomplish this. I also wonder what happens if you have the same volume exported by both Samba and netatalk in regards to locking when both a Samba user and a netatalk user try to modify something.)
The difference between rsync and rdiff is that rsync only keeps the most recent copy in each location (local and remote), overwriting old versions, while rdiff gives you space-efficient point-in-time snapshots. It can do what rsync does, but it can also give you incrementals.
Read below for my solution that provides bidirectional syncing with rsync.
I wanted a similar thing a while back, I found that the easiest thing was to use a shell script:
/foo/ remotesystem:/bar /foo
rsync -avz
rsync -avz remotesystem:/bar/
You just sync from local to remote, then remote to local. Rsync is smart enough not to send anything over the wire that hasn't changed, so if someone hasn't modified anything on the remote end, then the second command will not transfer anything.
What you effectively get out of this though is a filesystem where you can't delete anything (if it's there long enough to get synced once) unless you go and delete it locally and remotely. If you let a file get sync'd to the remote server, then delete the local copy, it will reappear on the next sync. It seems to me that any bidirectional syncronization solution is going to have this issue though; otherwise it wouldn't really be bidirectional sync'ing.
Minolta makes (or made, as a discontinued product from a now-defunct company I guess the past tense is safe) a neat negative scanner that would take 35mm and medium format, I think it was called the Multi Pro. Their naming conventions have always escaped me, I think the "Dual" model in each new series is the 35mm/APS model and the "Multi" indicates medium format capabilities. So there were several different versions of it with different sensors, I think the last model was made in 2005:
Review here http://www.kenrockwell.com/minolta/mp.htm
I looked at it for a while, but eventually picked up a used 35mm scanner and a high-quality flatbed with a transparency adapter separately for less than the Minolta was costing at the time. However, you might be able to get a gently used one now for a good price, and it would keep you from having to have two devices. In retrospect I wish I had sprung for the Multi Pro, and who knows maybe I still will.
For the 126, 117 and 110 stuff you'd probably have to build some sort of jig, but I don't think that would be very hard. I'd suggest using some strip styrene from any hobby store, and then cutting out holes as necessary using an X-Acto knife. The only thing you'd need to be very careful about is that you didn't leave any sharp edges that would scratch the negatives.
That's actually a really good idea.
It might be a bit much for most people's level of interest, but at the very least I would suggest scanning ANYTHING that looks like it has informational value. If there's writing on the backs of the photos, scan the backs. (Frame numbers, name of the drugstore it was printed at--common with stuff from the 50s and earlier, handwritten notes, etc.)
But I wouldn't just stop at photos, I'd also suggest scanning the envelopes that the photos are in, and anything else that's in there with them. It's not as good as providing a description for every photo, but it at least retains a lot more than just scanning the photos themselves and ignoring any context. (Actually I would do this even if I was adding a total braindump of everything I knew about every photo to the scans.) In fact, if you have a digital camera, it might be worthwhile if you're scanning a box of photos or old photo album, to take some general pictures of the album or box. It might not seem relevant to you, but some relative down the road might not remember "Dad's Photo Album" but might remember "the big ugly blue photo album with the ducks on it." (Don't laugh, I have one that fits that description.)
I keep the raw scans of my photos and negatives just in one large directory, named according to xx-yy[F,B].tif where xx is the roll number, yy is the frame number, and after the frame number I use letters to indicate F or B for front/back, and sometimes A,B,C,D to indicate multiple versions or scans of a file. (Sometimes I'll scan a negative a few times with varying brightness settings to make sure I get the highlights and the shadows, because the scanner has less dynamic range than the film.)
Actually I heard someone propose a photo-scanning service that used offshored labor for the more repetitive tasks (I think this might have been in reference to scanning books), but the real problem is transportation. I think you're going to lose the advantage when you factor in the cost of FedExing all those photos to India or China or wherever, just to have somebody sit there and scan every one.
:)
Plus, I've seen enough negatives and prints get lost just going from the minilab where I used to work, to the big Kodak outlab processing center in the next city and back. And that was handled by a private courier service. It's a pretty accepted piece of wisdom in the photo industry that once you lose somebody's negatives, you've lost them as a customer. I can't imagine what the loss rate would be of a service that had to ship everything to China.
And yes, I'm aware you were joking.
Perhaps a better option would be to use illegals? Bring the slave labor to the work, instead of the other way around.
Are you talking about scanning negatives or scanning prints?
$10 for 40 negatives makes sense (although personally I think it's a bit steep -- most WalMarts have Fuji Frontier series equipment, and a brain-damaged monkey could scan negatives on that; the trick is dust and quality control) but I'm not sure why you'd say anything like an "8x10" scan.
Saying "8x10" makes me think that they're cropping the frame to an 8x10 aspect ratio, which is different than a 35mm film frame -- the film is much longer than an 8x10 (35mm is actually closer to 8x12, or 2:3) -- so if they're doing that, you're losing a significant amount of information.
I think there's another avenue here that people aren't considering: organize and protect the negatives. Aside from the portable hard drive, and perhaps the DVDs (depending on how you did the digitization), a binder full of 35mm negatives in archival sheets have a very high information density.
Since they are the originals -- the true originals, not 1st generation copies like prints -- you have all the information needed to reconstruct prints at a later date. Physically, they're quite robust: I'd say they're on par with CD-Rs in terms of resistance to damage, properly stored. (I'm talking about negatives in sheets here, not kept in crummy little paper envelopes or whatever other horrible ways people tend to store them.)
If you assume that each frame is equivalent to a 60MB scan, which is what I'd say is sufficient to even have a shot at extracting the majority of the information from it, an 8x10 sheet of negatives (35 frames on mine) holds around 2,100 MB of information. By weight, I think that's probably ahead of CDs and close to DVDs. And you can put a whole lot of negative sheets into a 3" binder.
I'm not suggesting that a binder of negatives be your only backup option, but if you're going to go to the work of sorting through your photos anyway, it makes sense to pull out those negatives, put them in sheets, put the sheets in a binder, and put the binder somewhere safe. In fact, if you make digital copies, then you can keep the negatives off-site somewhere.
It might not help you too much if your house is totally destroyed (although I have mine in a cabinet next to my "go bag"; if I leave town in a hurry, it's going with me), but I just think that it's wise to remember that your old film photos already have a 'backup copy,' and that sometimes those analog backups are the best kind.
My question on the procedure isn't the resolution, it's the ease of use. Seems like it would be easier to just plop the prints face-down on a flatbed scanner and hit "Scan" than to set up what's essentially a homebrew copystand.
I've used a real copy-stand quite a bit for making 35mm slides from flat-work, and it's not exactly a brainless procedure. I wouldn't recommend doing it without white balancing, because otherwise your color could be all off, and while it has its place -- particularly if you want to digitize something from a book or other object that does't lend itself well to being smushed down on a flatbed, I question if it's the simplest route.
Why take photos instead of just using a $99 flatbed? Either way gets you enough resolution to see the film grain, it just seems like the former is unnecessarily complicated.
If the negative was saved as a .bmp file, it created a 36 MB file - the .jpg version was 2 or 3 MB.
... that file size ought to have been an indication of how much information it was throwing away in the JPG versions.
I hope, therefore, that you chose to save them as BMPs
A while back here on Slashdot there was a discussion of what file format people would want to use for archival purposes -- really long-term storage, not just a few years or decades. There were some very convincing arguments for using plain-old 24-bit RGB bitmaps, since it's reasonably easy to build a reader for them, even if the format was otherwise dead. Interpreting a JPEG file without a reader...now that would be a challenge.
If you're really short on space, I think it's a better idea in principle to save to an uncompressed, non-lossy format and then compress the resulting files separately using some sort of well-documented algorithm. Still not as safe as just having BMP files, but I think you'd have a better chance of letting somebody down the road recover them without specialized tools. At least you'd be breaking the recovery problem into two separate and less-complex operation rather than into one huge format to unlock.
You might find it easiest to make up a 4x6 template, some bright lights, a glass coversheet, 2x polarizers and shoot thru the glass with a macro lense and capture a 6mp image of the 4x6.
I'm somewhat confused. Why is this method superior to using a device that's designed for digitizing flat work? Most inexpensive scanners can get 6MP from a 4x6 (that's less than 600 dpi), although frankly for dimestore/commercially printed 35mm prints I think that sort of resolution is overkill. You're going to be looking at film or paper grain at much more than 300 dpi. It would have to be a pretty high quality print to justify scanning it at 600 dpi, unless you're just burning storage space for fun.
Works just fine for me. You just need to go into Sharing, turn on Remote Desktop, and then I think under options you need to enable VNC access in addition to ARD. There are also some other options in there (set password, etc.). It's not difficult.
I've had no trouble at all connecting from my Windows machine at work; the only thing I've run into is that I need to leave the connection settings on the client to "Auto," and that it will only use 32-bit color, it just crashes if I select anything less. So if you don't have a good connection, it might be a good idea to run a more lightweight implementation -- but just as something that you could talk someone else through enabling so that you could remote administrate, it's great.
That doesn't quite make sense. If anything, the debt should make China more dependent on the US than the other way around, since they traded a whole lot of hard currency for some pieces of paper that are only worth anything because the US Treasury says so. If the US defaulted (not bloody likely, but speaking theoretically), they would be the ones left holding the bag. At that point it would become a question of what they'd do to make the US pay up -- they can't exactly send someone over to break our kneecaps.
However, the GP's question is still valid: there are a lot of countries that pull the free-trade card when it comes to having access to US markets, but are still staunchly protectionist when it comes to their domestic markets and industries. China, even Japan is like this to a certain extent; even some of the Western European countries (I'm looking at you, France) have "non tariff barriers" to trade that are really protectionism clothed in various regulatory outfits.
I suppose the US plays along because it's good for business to do so, at least in the short run. Whether building up the sort of trade and current-accounts deficit that we have is a good idea in the long run, I'm not so sure.
I used to wonder the same thing. The closest I've ever heard to an explanation is that Blackberry's "product" is less the little handsets but the infrastructure that the cellular carriers use to provide email service. Apparently BB is very easy to deploy, and they have patents on some rather vague concepts regarding (don't quote me on this exactly) where the email is cached. I think the crux of it is that when a cell carrier deploys a BB system, they don't have to dick around with actually running the mailservers or anything else; it's a very holistic/'total package' type solution from their perspective.
Now why somebody else doesn't just make a similar network and market it to the cell carriers, I'm not sure. That's where I'm betting the patents come in. But I think BB has sold itself to the cell carriers as being easier to implement and maintain than a roll-your-own solution, and their handsets and all-you-can-eat pricing (versus SMS) have gotten them a good userbase and the associated name recognition.
If anyone can elaborate on exactly how the BB system works, I would be interested.
Pity there's no functional screen-top, context sensitive menubar, though.
Right now I'm using Kubuntu and it's not exactly the world's most stable piece of software; I'd like to use Gnome, but they insist on using Windows-style menubars for everything. It's a crummy design[1] and I don't understand the resistance to having alternatives like KDE does.
[1] If you like it, more power to you; I think they suck and just want a choice, I don't care if you use it or not. The only good argument I've heard in favor of window-top menubars is that they're easier to use with multiple monitors, but really I think Linux could outdo MacOS in this respect and have an application's menubar jump to the top of the screen on which it was located, if people were bothered by this.
I don't know how PCs handle this, but on my PowerMac G5, there is actually a daemon that controls the fan and pump speeds in response to various temperature measurments. (There are some absurd number of temp sensors inside the case, off the top of my head there are sensors for each CPU core, the GPU, heatsink, intake air, hard drive bay, and back side of the motherboard / memory controller.)
It's possible to kill the daemon or boot up without launching it, but in the event of this, the hardware has a "fail safe" mode where all the fans go to max RPM immediately and stay there. Assuming none of the vents are blocked, this is enough to keep the system from overheating. (Actually it's more than enough, even fully loaded I can't get the fans to rev up that high under normal conditions; there is definitely some excess cooling capacity at room temperature.) I think it will also enter this mode if the daemon allows the temperatures to exceed a certain range, so that a "bad" or compromised daemon (i.e., if you got hacked) couldn't tell the fans to just shut off and let the cores melt.
So while there is software control of the cooling system, the hardware is designed so that you can't (easily) cause physical damage through software control.
It definitely is interesting though that we have gotten home computers to the level where they require this much self-protection in order to operate. I was looking inside mine and thinking how much like a car it is; basically it has a set of big fans that suck in air and blow it over a liquid-filled radiator. I wonder if people had similar reactions the first time they saw a liquid-cooled gasoline engine--wondering whether it was a good idea to design something that would destroy itself if the cooling system failed to function.
I could think of a few other ways to cause an overheat which aren't necessarily physical console access. They're not really remote exploits either, but let's say the target was in a datacenter. Even if you couldn't get into the datacenter, maybe you could interfere with the air conditioning equipment. (Which is usually outside / on the roof and less secure than the data equipment itself.) Or more simply perhaps, bribe/convince a janitor or someone in physical plant operations to divert or shut down cooling to a particular area after hours. Not to mention (against a desktop PC) the BOFH-style "air filter" attack. The point is, there are ways to make a system overheat that are potentially easier than compromising it in some other way might be, or less obvious than them. Having a system overheat, shut down, and then return to normal operation might not raise too many red flags, compared to discovering a keylogger or tap; it might get treated as an infrastructure problem rather than a possible break-in, delaying discovery.
It's probably not something that some guy in his basement in Russia is going to do to you, but if you have valuable information on a computer, it's another avenue of attack that you have to defend against, or at least be aware of.