The article suggests things that people worth their IT salt should have already implemented, or at least investigated. Really baseline stuff there.

However one big oversight I see a lot w.r.t. backups and local networks which toss large amounts of data around are configuring jumbo frames. This is often forgotten about when throughput is getting tight.

I wouldn't be so generous in your detraction.

ACR, as it stands today, does not appear to be built around dcraw as you imply. It may at some point in the past used snippets or knowledge gleaned from dcraw and just might still today, but ACR is very much Adobe's own creation. In fact, one of the very articles you sort of point to by urging the OP to "google around" talks about this, with Thomas Knoll of Adobe essentially saying "Thanks but no thanks" W.R.T. Mr. Coffin reverse engineering the encryption in Nikon's RAW format.

I use Lightroom and PS CS4 on a daily basis, so I have ACR available and did some snooping. One thing that jumps out at me:

[daleg@iridium]/Library/Application Support/Adobe/Plug-Ins/CS4/File Formats/Camera Raw.plugin/Contents/MacOS$ strings Camera\ Raw | grep -i copyright
Copyright 2009 Adobe Systems, Inc.
Copyright 2008 Adobe Systems, Inc.
17CCopyrightMLUCTag
Copyright %4d Adobe Systems Incorporated
$$$/Private/CRaw/About/Copyright=^C ^0 Adobe Systems Incorporated. All rights reserved.
copyright
xmpDM:copyright
COPYRIGHT : Copyright (c) 2002-2007, Adobe Systems Incorporated
Adobe XMP Core Copyright (c) 2002-2007, Adobe Systems Incorporated
Copyright
tiff:Copyright
Copyright (c) 1998 Hewlett-Packard Company
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright (c) Eastman Kodak Company, 1999, all rights reserved.
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright 2005 Adobe Systems Incorporated
Copyright 2006 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright 1999 Adobe Systems Incorporated
Copyright (c) 1998 Hewlett-Packard Company
Copyright 2000 Adobe Systems, Inc.
13CCopyrightTag

While probably not definitive, I would expect to see a salutation to Mr. Coffin and dcraw in there if there were dcraw bits present. There is one other binary installed with ACR, a library by the name of NkMiniLib.dylib. Given the name I would suppose this is a library containing the properly-licensed smarts required for ACR to decrypt Nikon NEF files. I admit that this is a hunch on my part, but I think it's a good one given the known circumstances around Nikon as a company and its RAW format - Nikon would rather you buy their Capture NX 2 software for RAW file manipulation. I can only imagine how much Adobe paid or pays for licensing the ability to do this in ACR (and by extension - in Lightroom and Photoshop.)

It is also well-known that Adobe's ACR team creates the profiles that plug into ACR for each camera, they don't lift them from dcraw. It's likely they get samples from manufacturers in advance or soon after a camera's release to divine the profile themselves for release in a future version of ACR.

So color me not convinced, regardless of what Mr. Coffin might put on his resume. In the course of "googling around" I cannot find one authoritative bit of info linking ACR to dcraw. ACR as it stands today doesn't appear to have a whiff of dcraw in it judging from some minor binary snooping... so until proven otherwise, I'd say that millions of photographers wordwide do not use his code as you might claim.

Assuming that the article's list of defendants is complete, it's interesting that this troll is going after companies which make finished systems, and not the companies which make the actual ethernet chipsets and MACs that go into those systems (Broadcom, Marvel, Intel, RealTek, etc)

One would think that those would be the source of any patent infringements (real or imagined) when talking about ethernet itself.

You're saying that Linux is 100% better because it can run on something that is exceedingly rare? Perhaps you might want to try considering some more run-of-the-mill use cases, such as those one run into in any data center and not just Los Alamos's. You know, things like serving, database server, backup server, storage and so on.

As already mentioned, the Bayer filter is part of the CMOS sensor itself. It's not a separate part that's tacked on near the end of the manufacturing process.

There is, however, a separate filter in front of the sensor on pretty much every DSLR. This is a IR cut-off filter. Naked CMOS sensors are very sensitive into the IR spectrum. This high-pass IR filter prevents deep red and IR from overwhelming the resulting image, producing a balanced red against the green and blue end of the visible spectrum.

There are several cases where one would want to modify their DSLR and have this filter removed. The primary users of this method are astrophotographers who wish to use a much cheaper DSLR on their telescopes vs. a very expensive purpose-made camera. There are a few small companies such as Hutech which can perform this service under warranty.

Why?

Nebulas and stars in particular emit light (human-visible and not) in a variety of specific wavelengths. These particular wavelengths are produced by ionized elements in the star or nebula complex. In your run-of-the-mill nebula, copious amounts of Hydrogen-alpha and doubly-ionized Oxygen tend to produce much of the light. H-alpha's emission line is deep in to the red spectrum, which the IR cut filter on DSLRs dutifully blocks from reaching the sensor. Removing this filter lets the DSLR capture additional light and detail from the nebula... stuff you wouldn't get with a stock DSLR.

If you take a stock DSLR and try to image (for example) the Horsehead Nebula, you're not going to get far because the thing emits almost entirely in the H-alpha band. Put on a camera that doesn't cut the deep red, and you'll get a result that's closer to what you'd expect.

There is a trade-off to doing this mod, of course... in that you're effectively turning your DSLR into a IR camera, and if you want it to be close to normal again, you'll need to put a IR filter on your lens.

I'm not sure that you realize the limitations of the radar systems themselves.

The nexrad doppler radar system uses systems designed in the early-mid 80's. Three meter resolution? Try 1km during the best situations.

Unfortunately said Pentium 4s also would fail 10x more often.

I don't know if you've worked (ie, have had direct administrative experience) with any of the larger Sun hardware such as E2900 and above, or even the Ex500's from back in the day, but if you did you'd also know that these servers have a knack for uptime and resiliency that x86 servers, even to this day, have never had. There was a reason for those higher costs.

You could, you know, call one of those people who have the profession of Electrician and have them install a receptacle in a convenient place (220V even, same as a electric dryer here in the US!)

Just sayin', but I'm sure you already thought of this before writing your post. Quite sure.

It's tough to not by cynical after reading about something like this happening to an established company. To many of us, this is being careless about data in the 1st degree.

But as one other poster pointed out, let this be a cautionary tale - but not only to those who fund and lead IT departments (aka, the "Suits") but for system administrators as well.

I don't claim at all to have any deep knowledge about this particular Journalspace setup, but I can get a decent idea just by gleaning tidbits from TFA and elsewhere. In the end, I have to conclude that Journalspace is/was a company that had a great idea or product, the product being an application, but the people whose full-time job was to maintain the app had no idea how to design the underlying infrastructure to properly run it.

This is a situation I find more and more these days since the advent of Web 2.0. The scenario goes something like this: A company is formed around an application, an assemblage of Java/PHP/Ruby/whatever code that runs a neat service or online tool. The company brings in people who know the idea/code/language well and improve it. *Running* the application, however, on the systems infrastructure, is not their strong point. They're coders. They know Java classes and whatnot inside and out, but there's a reason why these people are full-time app coders and not systems/storage administrators.

One of two scenarios then happen. Sometimes both occur. First, one of the app coder employees who knows just enough about running a OS or designing a systems infrastructure is co-opted by the group to do this, to run their app. This person can get a lot of things right, but the devil is in the details and misconceptions or misunderstandings about certain things lead to stuff like RAID mirroring being considered as a backup mechanism or choosing to run your company on OSX Server because its GUI is familiar or whatever the reason may be.

The other scenario is that the group of app coders try to hire in people with the right kinds of experience to setup a infrastructure, but because they're interviewing people for a job they don't know how to properly quantify, they end up hiring under-experienced admins who are good at feeding them BS.

In the end, you get a turd of a infrastructure that works most of the time, but always has at least one hidden domino threatening to topple. When that domino eventually does, Journalspace happens. Single database servers? No real backups? That's a some basic stuff right there. It makes me wonder about more nuanced things that help keep a infrastructure straight such as security policies (network, host, physical), change control, funding, and so on.