So a non-CPL pilot who can only accept a split of the gas cost, they're going to (in theory) be racking up hours on a airframe faster than they normally would, which will lead to more frequent mandated inspection and overhaul events... events that their prior fares wouldn't have put any money towards. Not to mention defraying the cost of any hangaring or parking fees. I fail to see how "Uber for Planes" would work for the private pilot outside of purely opportunistic "hey, you're going my way?" one-offs.
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.
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.
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.
Yes yes yes, you can do that with just $1000 and a afternoon at Fry's or browsing Newegg, right?
Everyone's missing the point here, and a lot of what is being said could be applied (just as wrongly) to NetApp... after all, those are just x86 boxes running a BSD kernel.
The special sauce here is not so much the underlying OpenSolaris OS (which does provid the IO and services such as CIFS, NFS, iSCSI, data replication, and so on) but the Fishworks software put on top of it. Built-in failover clustering, the integrated web GUI and CLI... if you weren't paying attention to the console during boot, you might not even have a clue that's it's OpenSolaris underneath... which is one of the marks of a good appliance OS... easy to manage and the idiosyncrasies of the underlying OS is sufficiently abstracted away.
You don't need to be a Solaris admin to use this, just like you don't need to know about BSD to run a NetApp. The difference here is that this takes pretty high-end x86 hardware and does better than NetApp, for cheap. Ever see a support contract for any of the NetApp filers? I guarantee you'll spin a 180 on your heals and pretend you never saw the number.
You're making a bad assumption here, here's why:
As another respondent indicated, optics are one of the limiting factors here.
The other major factor is the imaging device itself and the size of the individual pixels on the sensor. The amount of photons a individual pixel can collect is governed by the size of that pixel. The larger the pixel, the more photons it can gather. The more photons, the more light-sensitive it is.
Now the sensor used on everything from your pocket P&S camera to a imaging device such as this are of a certain, finite size. You can fit only so many pixels on in its surface area.... the more pixels, the smaller they have to be in order to fit. Fewer pixels allows each pixel to occupy more space and gather more light. See the trade-off?
With more pixels comes higher resolution at a cost of lower sensitivity, generally speaking. The capability of the optics is a moderator here as it has its own resolution limit. Given this optical limit, a point is reached where the addition of more pixels on the sensor becomes, essentially, a useless exercise with no return in terms of resolution and a definite loss in overall per-pixel sensitivity.
So say you have Comcast's triple-play or some VOIP service that rides out of your house on your Comcast connection. You get cut off for one reason or another, such as exceeding this cap. Is your phone service dead, too? Better have a mobile phone if 911 needs to be called?
...by design. TFA doesn't delve into too much detail, but a sudden power loss on such software RAID systems is a condition that ZFS accounts for. Its Copy-on-write (COW) and write-length stiping strategy prevents things such as the RAID5 write hole condition, a condition that has the biggest chance of occurring when a power loss event happens.
There's actually a good reason behind why the power cord(s) is/are packaged separately, and hence in their own boxes - international differences in electrical sockets.
It would suck for inventory and man power if you constantly had to manage how many of each of your servers have continental europe, british, north american and so on power cords with them in the box.
Yeah, I've used Apple Airports (previously, the "UFO" kind and currently, the Extreme (1Gb ports) and Express (for my home theater) and have never had to do "therapeutic" reboots on them.
But I have been irked due to having to reboot the router to make even the slightest of config changes - such as changing its syslog destination or adding a port to the forwarding table. You'd think that these and other operations, short of a firmware upgrade, could be handled without a full-blown reset, but apparently not. One has to wonder why that is so in this day and age.
Just responding to reinforce your situation. I have a 10" solid tube dob (Orion XTi) that I would set up on the campus of the university where I worked on clear nights.
One such night, a university cop pulled up and asked what I was up to. He didn't seem alarmed, but made a off-hand comment as he left, saying that it looked like I was sighting in a mortar.
You know, after reading the above reply, I really do think geeks tend to try too much to apply sterile and uncompromising forms of logic to human- or individual-level problems real or perceived.
There's no "seriously, though" about what you've said. Threads? Interrupts? Critical paths? Are you kidding? Do you walk around during your day thinking "beep boop I'm a computer" and refer to or even think to yourself - let alone others - in these terms?
Its ironic, in a way, as researchers try to teach computers to be more human, and at the same time we have humans that try to think of themselves more as computers.
From the article:
The information is wirelessly transmitted to a central location over a 2-megabit-per-second DS3 connection. Sign me up for those wireless 2Mbit/s T-3s.
Current versions of ZFS have the feature where the ZIL (ZFS Intent Log) can be separated out of a pool's data devices and onto it's own disk. Generally, you'd want that disk to be as fast as possible, and these SSDs will be the winner in that respect. Can't wait!
What would it take? A lot. And it would exist only on the Windows version.
The "COM" part of "ASCOM" actually refers to Windows' Common Object Model, which the ASCOM driver stack is based on. As a result this means that the ASCOM stack and its device-specific drivers are confined to the Win32 world.
The only reason why the Mac versions of Starry Night Pro and TheSky X have (or will have) telescope control is because their authors implemented their own device-specific drivers directly in the app.
I never would have expected it, especially in a MS product, but the folks who put the WWT app together also blessed it with ASCOM capabilities, so one may use the WWT app to drive a computerized telescope mount (aka, a "goto mount").
While there areother ASCOM-enabled apps that astronomers have been using for years to point their optics (and manage dome robotics, and focusers, and cameras), I have to say that the basic mount control in WWT is a pretty cool tip of the hat towards to astronomy community in practical terms.
One can also say, with some agreeable degree of accuracy, that RMS birthed the GPL and chose that for his code due to an agenda of his own.
Is it a surprise to you that licenses are chosen and nix'd based on how in line they are with the choosing org's goals? That's an agenda dictating things. Everyone has one. The question is, is whether you are amicable towards that agenda, or not.
But, yes, some people can be bafflingly dumb and pick a license out of thin air with no purpose or foresight behind why they did so.
The Linux community CAN'T change to a more permissive license. Welcome to the bed that RMS, via Linus, has made for you. Please - sleep in it.
You're just upset that there's this cool thingy called ZFS and DTrace and you're smarting because your favorite OS cannot have it in part due to a decision made long ago by one Linus Torvalds.
Sour grapes. Linux/GPL zealots need to stop blaming everyone but themselves for things they've barred themselves from accessing. No one in this world is obligated to release code under the GPL, no matter what RMS would have you believe. That is true freedom. I believe that the concept of freedom of choice was a core concept of the Linux/GPL camp before it got too big for its britches.
Slashdot Mirror
So a non-CPL pilot who can only accept a split of the gas cost, they're going to (in theory) be racking up hours on a airframe faster than they normally would, which will lead to more frequent mandated inspection and overhaul events... events that their prior fares wouldn't have put any money towards. Not to mention defraying the cost of any hangaring or parking fees. I fail to see how "Uber for Planes" would work for the private pilot outside of purely opportunistic "hey, you're going my way?" one-offs.
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.
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:
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.
Yes yes yes, you can do that with just $1000 and a afternoon at Fry's or browsing Newegg, right?
Everyone's missing the point here, and a lot of what is being said could be applied (just as wrongly) to NetApp... after all, those are just x86 boxes running a BSD kernel.
The special sauce here is not so much the underlying OpenSolaris OS (which does provid the IO and services such as CIFS, NFS, iSCSI, data replication, and so on) but the Fishworks software put on top of it. Built-in failover clustering, the integrated web GUI and CLI... if you weren't paying attention to the console during boot, you might not even have a clue that's it's OpenSolaris underneath... which is one of the marks of a good appliance OS... easy to manage and the idiosyncrasies of the underlying OS is sufficiently abstracted away.
You don't need to be a Solaris admin to use this, just like you don't need to know about BSD to run a NetApp. The difference here is that this takes pretty high-end x86 hardware and does better than NetApp, for cheap. Ever see a support contract for any of the NetApp filers? I guarantee you'll spin a 180 on your heals and pretend you never saw the number.
You're making a bad assumption here, here's why: As another respondent indicated, optics are one of the limiting factors here. The other major factor is the imaging device itself and the size of the individual pixels on the sensor. The amount of photons a individual pixel can collect is governed by the size of that pixel. The larger the pixel, the more photons it can gather. The more photons, the more light-sensitive it is. Now the sensor used on everything from your pocket P&S camera to a imaging device such as this are of a certain, finite size. You can fit only so many pixels on in its surface area.... the more pixels, the smaller they have to be in order to fit. Fewer pixels allows each pixel to occupy more space and gather more light. See the trade-off? With more pixels comes higher resolution at a cost of lower sensitivity, generally speaking. The capability of the optics is a moderator here as it has its own resolution limit. Given this optical limit, a point is reached where the addition of more pixels on the sensor becomes, essentially, a useless exercise with no return in terms of resolution and a definite loss in overall per-pixel sensitivity.
So say you have Comcast's triple-play or some VOIP service that rides out of your house on your Comcast connection. You get cut off for one reason or another, such as exceeding this cap. Is your phone service dead, too? Better have a mobile phone if 911 needs to be called?
...by design. TFA doesn't delve into too much detail, but a sudden power loss on such software RAID systems is a condition that ZFS accounts for. Its Copy-on-write (COW) and write-length stiping strategy prevents things such as the RAID5 write hole condition, a condition that has the biggest chance of occurring when a power loss event happens.
There's actually a good reason behind why the power cord(s) is/are packaged separately, and hence in their own boxes - international differences in electrical sockets.
It would suck for inventory and man power if you constantly had to manage how many of each of your servers have continental europe, british, north american and so on power cords with them in the box.
I would hope you'd remember to change the policy after doing that.
Yeah, I've used Apple Airports (previously, the "UFO" kind and currently, the Extreme (1Gb ports) and Express (for my home theater) and have never had to do "therapeutic" reboots on them.
But I have been irked due to having to reboot the router to make even the slightest of config changes - such as changing its syslog destination or adding a port to the forwarding table. You'd think that these and other operations, short of a firmware upgrade, could be handled without a full-blown reset, but apparently not. One has to wonder why that is so in this day and age.
Just responding to reinforce your situation. I have a 10" solid tube dob (Orion XTi) that I would set up on the campus of the university where I worked on clear nights.
One such night, a university cop pulled up and asked what I was up to. He didn't seem alarmed, but made a off-hand comment as he left, saying that it looked like I was sighting in a mortar.
You know, after reading the above reply, I really do think geeks tend to try too much to apply sterile and uncompromising forms of logic to human- or individual-level problems real or perceived.
There's no "seriously, though" about what you've said. Threads? Interrupts? Critical paths? Are you kidding? Do you walk around during your day thinking "beep boop I'm a computer" and refer to or even think to yourself - let alone others - in these terms?
Its ironic, in a way, as researchers try to teach computers to be more human, and at the same time we have humans that try to think of themselves more as computers.
Current versions of ZFS have the feature where the ZIL (ZFS Intent Log) can be separated out of a pool's data devices and onto it's own disk. Generally, you'd want that disk to be as fast as possible, and these SSDs will be the winner in that respect. Can't wait!
What would it take? A lot. And it would exist only on the Windows version.
The "COM" part of "ASCOM" actually refers to Windows' Common Object Model, which the ASCOM driver stack is based on. As a result this means that the ASCOM stack and its device-specific drivers are confined to the Win32 world.
The only reason why the Mac versions of Starry Night Pro and TheSky X have (or will have) telescope control is because their authors implemented their own device-specific drivers directly in the app.
I never would have expected it, especially in a MS product, but the folks who put the WWT app together also blessed it with ASCOM capabilities, so one may use the WWT app to drive a computerized telescope mount (aka, a "goto mount").
While there are other ASCOM-enabled apps that astronomers have been using for years to point their optics (and manage dome robotics, and focusers, and cameras), I have to say that the basic mount control in WWT is a pretty cool tip of the hat towards to astronomy community in practical terms.
One can also say, with some agreeable degree of accuracy, that RMS birthed the GPL and chose that for his code due to an agenda of his own. Is it a surprise to you that licenses are chosen and nix'd based on how in line they are with the choosing org's goals? That's an agenda dictating things. Everyone has one. The question is, is whether you are amicable towards that agenda, or not. But, yes, some people can be bafflingly dumb and pick a license out of thin air with no purpose or foresight behind why they did so.
You're just upset that there's this cool thingy called ZFS and DTrace and you're smarting because your favorite OS cannot have it in part due to a decision made long ago by one Linus Torvalds.
Sour grapes. Linux/GPL zealots need to stop blaming everyone but themselves for things they've barred themselves from accessing. No one in this world is obligated to release code under the GPL, no matter what RMS would have you believe. That is true freedom. I believe that the concept of freedom of choice was a core concept of the Linux/GPL camp before it got too big for its britches.