At least here in Texas, unless you make a deal with the prosecutor, you don't get off the hook; you just get other people onto it. There's no concept of an "accomplice" here -- if you were involved in the crime, you're responsible for it as much as the person who pulled the trigger up until sentencing comes up (at which point you can argue how minimally you were involved). Think about what you're arguing here: Let's say your boss tells you to steal a car, and that he'll fire you if you don't. Do you honestly think that the fact that you were just following orders would get you off?
In civil cases, more than one defendant can be named -- and if your company is too cheap to pay for their own software, do you think they're going to have their lawyer defend you as well? (Further, if they go bust and the corporate veil can't be pierced, that leaves you as the only remaining defendant -- and that's a lousy position to be in).
In short, I would be extremely skeptical of any attempts to leverage your line of reasoning -- particularly now that copyright violation is in many cases a criminal rather than civil act -- without first consulting with a competent lawyer.
What Bruce thinks is that as computing becomes a utility the security needs will decrease.
That's not what he argues, though.
If you RTFM, Bruce's article argues that as computing becomes a utility, security will become "baked in" such that 3rd-party, add-on security products will, to the extent that they exist at all, be implicit functionality that users don't need to think about. To the extent that security will become cheaper, that's because R&D on it will be largely paid for by the utilities (who have an interest in lowering costs) rather than the vendors (who don't).
The parent's proposal covers not just if/then, but all conditional jump instructions -- which are used by your compiler to implement if/then, switch, and other conditional flow control.
I can't argue that there are much bigger inefficiencies than the transcriptionists and billing clerks; indeed, you make a lot of good points along those lines. As for suitability of EHRs for smaller sites in general, we're mostly selling to smaller clinics presently, so they're the group I can most comfortably address.
We've traditionally had a significant amount of range in terms of customer satisfaction -- but our happier customers say we really have saved them significant amounts of time (no longer needing to do paperwork after hours) and money (automated coding == no need to be ultra-conservative to avoid getting caught in a mistake, hence more effective billing). The unhappier customers are the ones I interact with (being level 4 support tends to work out that way), but there've been less of them lately -- either level 1-3 support is getting better, or the product itself is improving; either of those is good news. To be sure, lots of EHRs are severely expensive -- but from my perspective (making one that's priced to be affordable even for 1- or 2-doctor practices), that's great. (As for needing to hire staff to maintain the system, we sell the hardware and provide remote administration and network backup service, and do pretty much everything else; it's sold as a black-box solution, so additional support staff aren't needed).
As for generating billing codes being difficult to automate -- yes, it's difficult to automate. That said, we've done it, and we haven't had a customer fined yet for an inaccurate code we generated -- indeed, I've yet to hear of such a bug. Given the severity if we goofed up, QAing the logic in question is something we put a lot of work into.
And yes, I entirely agree about many many many healthcare-related systems having security as an afterthought at best -- but that's a topic for a different discussion.
You've got questions, I've got answers -- though if it looks like we might need to get into much more detail, this discussion might be best taken offline.
1) For the physicians, the preferred UI is a tablet PC with all the handwriting recognition controls installed. I don't know that we've tested those with Citrix, and I wouldn't be surprised if there were problems. That said, if you don't need the handwriting recognition, the client platform is just Firefox and IE; nothing there should be trouble. 2) That's an area of ongoing work. We have a multi-tiered architecture intended to support a "just-throw-more-servers-at-it" approach -- bunch of app servers on that tier, an Oracle RAC cluster on the database tier, and there you go. That said, I wouldn't deploy it to a customer site until we've had a full dev and QA cycle with that kind of hardware (and Oracle RAC licenses for dev and QA) in-house. That might be happening in the rather near future -- but it hasn't happened yet. If a pretty good sized healthcare provider came to us and indicated that they'd be willing to pay for the hardware and RAC licenses, it'd probably happen pretty darned fast. 3) We introduced strong auditing within the last year, as part of our drive for CCHIT compliance. 4) We have some clinics that maintain hours significantly longer than 8x5, and our current release fixes the backup system such that there isn't regular downtime required for that process; consequently, we have no remaining known issues which would prevent 24x7 operation. As for HA, see the answer to #2 -- multi-tiered architecture, multiple servers to a tier, redundant shared storage at the database tier. 5) If you want the handwriting recognition, we have a Firefox plugin which adds that support on Windows. To stop it from potentially conflicting with any other Gecko-based browser installs, we have a rebranded Firefox branch which comes with this plugin preinstalled. Other than that, nothing fancy. There might be some gotchas left relating to IE7/Vista; getting those ironed out is very much on our TODO list, though.
Yes. My point (which I meant to reinforce via use of italics) is that having a comprehensive standard in existence doesn't do much good until it's actually implemented across enough products to provide meaningful interop. Making it a CCHIT requirement would make that happen, or having a big player like GE go first.
Having a standards-compliant format that covers progress notes in particular would be great, and I look forward to this getting on our radar as something to implement. That said, until there's a major competitor using it who we want to provide interoperability with or a migration path from, or we have prospective customers inquiring, it's going to be a hard thing to push onto the schedule. Limited number of development hours, full slate of features planned... you know the drill.
Unless, of course, it's already on the schedule. I'm not really involved in planning new features unless there's a question of feasibility that the Java folks on staff can't answer unassisted, so I wouldn't necessarily know.
please tell me you guys have platform neutrality in your technology plan.
if you don't then your product is yet another dead end that will haveto be rebuilt from scratch at some point in the (near) future.
Our UI is browser-based and renders in Firefox; the server is Java; we presently do the server end of our deployments on Linux. Some of our dependencies (for things like faxing) expect a POSIX-compliant OS, but those are all things that can be replaced if need be -- the interface points are clean. The client, via some browser plugins, will take advantage of some fancy Windows-only functionality (mostly the excellent handwriting recognition engine Microsoft bought) if you're running it on a Tablet PC -- but if a handwriting recognition engine comes out that'll work elsewhere, is good enough for doctors' handwriting and is cheap, the transition is easy.
In short: Our technical platform was determined by engineering, not marketing, and it shows.
I said "widely accepted and comprehensive". Having a standard is one thing; having a widely implemented standard is another. Frankly, I don't see ubiquitous acceptance of a common format until it's required for CCHIT.
I'm senior tech staff at a late-stage startup making an EHR product (consider my bias declared), and I have a fairly decent window into at least a few of the places where the healthcare system is broken.
Overhead. Doctors need to hire transcriptionists and billing clerks to do work that could be largely automated. (Our product addresses this).
Ease-of-use. Most of the EHRs on the market require an office to switch to a very low patient load for a very long training period. This makes migration to a product intended to improve communications and efficiency into an extremely expensive and cumbersome proposition. (Our product addresses this).
Lack of communications (or standardized records formats). There are *some* standards (HL7 is what we use for integration with 3rd-party scheduling and billing systems where possible), but nothing widely accepted and comprehensive enough to be able to give a patient a flash drive with their complete medical history in a format any doctor's EHR product will understand. Worse, a lot of systems won't integrate with anything else without requiring the customer to fork out serious $$$ for the add-on functionality. (As just one small vendor, there's not so much we can do about this right now)
There are a bunch of other benefits that EHR vendors try to sell folks on -- automatic warnings about allergies, ability to guide the physician towards checking for symptoms that could indicate a serious problem, etc etc etc; I'm coming at this from the back-office geek point of view, though, so I really have no idea how significant these are in the grander scheme of things.
Is adding more expensive IT products magic fairy dust that'll make healthcare cheap? Of course not. But technology that's well-thought-out, well-implemented and sanely priced certainly can help to make healthcare less expensive -- and putting records in a portable format benefits everyone.
(That said, there's a lot of poorly-implemented technology in healthcare... but that's a topic for a different, much more anonymous forum).
I actually really like C# as a language, but I'm one of those people that thinks strict typing makes programming easier.
Hmm. Did I put in a Boo plug in my previous post? I thought I did, at least in one of the drafts.
Take a look at Boo's typing system -- it's friggin' beautiful. The compiler infers the type, but then does proper compile-time checking based on it, and lets you explicitly select duck typing behavior (at a per-declaration level) if you want.
I haven't used it for anything serious yet, and as previously discussed, I'm a Pythonista; you may not find Boo quite as interesting as I do... but then again, you might.
While C# is one of the primary programming languages for.NET, VB.NET is also fully-supported/top-level, so giving C# some special status as first-class citizen among.NET-targeted languages isn't necessarily accurate. (This is different from Java, since last I knew, all languages other than the Java language targeting the JVM bytecode were effectively second-class citizens).
The.NET virtual machine is also known as the CLR ("Common Language Runtime").
(I'm a Pythonista, myself, so I don't really care too much about the.NET/Java wars unless folks go writing code that doesn't port to Mono -- which is unfortunately quite a bit easier than it ought to be).
Subversion's backend is a transactional filesystem (though it sits on top of a BDB interface or a separate FS), and many of the tools it provides work by describing a set of changes as filesystem operations (go down this directory, now go down that directory, now open this file, now seek to this position, now write this text...)
That said, revision control is about much, much more than just storing snapshots that can be retrieved later. Think about branching and merging -- particularly intelligent merge algorithms where you want metadata about exactly where each patch that was merged came from such that if you merge two branches you aren't trying to re-merge patches common between the two. Also, the storage constraints for a revision control system are tighter -- you want to compress your deltas, since you're going to be storing tens of thousands of revisions.
There are also requirements such as being able to backup and restore your full history; modify it (in corner cases -- let's say a developer checked in some test code with a critical password hardcoded); and do all sorts of other things that a COW filesystem won't typically have written support for.
Taking a naive view of revision control that leaves out branching and merging is a sure way to make revctl geeks mad at you (or ignite a snapshot-versus-changeset flamewar -- the snapshot view, which is what a filesystem approach [like what SVN does] lends itself to, is considerably less powerful than the changeset approach [like what BitKeeper or Arch do] in terms of the merge algorithms that can be welded on top without a force-fit).
If information shouldn't be public, lobby your congresscritters (at the state level, mostly) to get it out of public records. Relying on the "security" of having something be inconvenient to access is a false security at best; all it does right now is limit access to this information to those willing to pay (not very much $$) to get at it. It's nothing but security through obscurity -- and while there are cases where that can be useful, giving folks a perception of privacy while they actually enjoy no such thing is hardly one of them.
By highlighting what information is available through public records, Google both helps promote government transparency, and makes it easy for folks to know what information is out there. Maybe if it's impossible to ignore how bad mothers' maiden name and SSN are for authentication tokens, people will stop using them as such. Imagine!
We're talking about CFLs, not standard fluorescents. CFLs typically have less than 9mg of mercury -- and given that I could consume that 9mg of mercury with no ill effects whatsoever, I find the "6000 gallons of drinking water" claim difficult to believe.
"I can, however, use proper capitalization, grammar, and spelling." who gives a fuck. your just trying to divert the argument to save some face.
Who gives a fuck? The folks who are reading the thread, that's who. When you're having an argument in a public forum (particularly of the mixed-audience variety), the audience is part of the point: They're the folks who are being informed or entertained, deciding which of 'yall do believe, and effectively keeping score.
When you don't care enough about your opponent or your audience to make an effort to proof your post for spelling or grammar errors, it's implicit that you probably also didn't care enough to do any factual research -- and that you certainly don't respect the audience enough put together something which flows well when read.
Being right on the facts is important, and I'm not commenting on the merits of the individual arguments here (except to note that your opponent need not worry excessively much about "saving face" -- right or wrong, there's obviously research behind their position) -- but online, as in real life, form is important as well.
My slashdot posts, like almost all of my activity online, are part of a Real Life identity that I wouldn't mind a potential employer digging up and going through. Can you say the same?
1) Why destroy when jamming is easier and cheaper?
I left out a key word there, but my intended phrasing was "destroy or disable"; jamming falls into the latter category. That said, jamming is more of a local defensive measure than an asymmetric attack; it doesn't have the same impact on civilian or commercial operations and other interests (ie. ability to wage war in theaters other than that in which the immediate conflict is taking place).
2) How much of this is a genuine survivability requirement than just hubris about using someone else's system (or everybody else's systems together)?
I'm not qualified to address that, except to note that survivability is very much a legitimate concern, and that having the military be nonreliant on GPS means reduces one's target profile by preventing a single mode of attack (disabling satellites, which -- as previously discussed -- at least one potentially hostile state has the demonstrated ability to do) from impacting both military and civilian targets.
This is more a matter of removing the motive for $OTHER_COUNTRY to try to confuse the US's offensive infrastructure by destroying disabling our GPS satellites. It works both ways, obviously, if $OTHER_COUNTRY is using similar technology -- but any missile which is going to do really significant damage will be able to get close enough to where it needs to be using inertial guidance, so the example you give isn't a serious concern.
Moreover, disabling GPS is really an asymmetric threat -- it's easy to do (if you're China, for whom the necessary technology is already a sunk cost), and has an impact on your opponent far greater than its marginal cost. Avoiding unfavorable asymmetric threats is a Good Thing.
For what you say about XPath and XSLT, I would grant that that would be useful - especially in a corporate environment or publishing house - but there are many programs that use XML (such as Apple's Pages program) whose formats are only theoretically interesting as they can't be opened by any other application. Sure one could use a Pages doc in the same way, but you are fundamentally stuck to one application. It is only really by this plugin which you gave the link to that one has the freedom to use the editor of one's choice - much like plain text gives one the freedom to use vim or emacs
It really depends on whether you're speaking as a producer or a consumer of software.
I'm right now working (effectively) as programmer-at-large in a late-stage startup. Most of our technical staff have a specialty (be it Java, or Oracle, or network administration); I'm the guy who gets all the interesting problems that don't fall so neatly into one specialist's space. As such, I get a wide array of projects to build and ideas to analyze for feasibility -- and having as many tools in my toolbox as possible is critical to doing this well. Being able to easily write tools that interact with office documents is, as tools go, quite powerful; I've alluded elsewhere to some of what I can do with that kind of ability. So -- if you're acting as an end-user, having a readily manipulable document format may not provide so much by way of direct benefits. As a toolmaker, on the other hand, I find it extremely useful -- and hopefully some of that utility filters down in terms of extra value to the user provided (directly or indirectly) by the tools that standards-based formats enable.
Realistically and short-term, though, yes, this is largely corporate-environment stuff -- the tools I write generally fall into the realm of site-local, proprietary infrastructure. That said, I would hope that the indirect benefits of the larger product this infrastructure supports being (ever so slightly) cheaper and more efficient to produce would have some kind of positive impact, noticeable or otherwise, on society as a whole.
True enough Office could interoperate with almost any format - the question is whether it is worth the time and money to develop the software to do so... and probably from the MS standpoint, probably not, as they get more money from people being forced to use documents in their format (and thus with their program). Microsoft plays the format wars because they know that no matter what format you have, you still need the program to use it.
The thing is, Microsoft aren't the only folks who can do this, and interested third parties have already decided that supporting ODF from Word is worth the time and money. See the da Vinci ODF plugins for Office. In short -- MS Word already is an ODF editor, though roundtrip support will be substantially improved after ODF 1.2 comes out.
Well, even if ODF was vastly superior to OOXML, if the tool you have to create documents is vastly inferior, there is no question as to what tool to use - and the format will follow the tool, not the other way around.
As I think I've established, the market leader among the tools is already -- with the use of some zero-cost 3rd-party software -- able to use either format. This means that the folks who do care about the format can select that independently. For some of my purposes, the ability to use XPath and XSLT-style templates with ODF is extremely helpful; other folks are more concerned about long-term document compatibility, lest Office 2043 be unable to read documents created today with Office 2003.
Putting my idealist hat on, I'd argue that in cases where documents are intended to be disseminated to the public at large, accessibility (to those who can't afford MS Office or those who run on a platform where Office is unavailable) is socially responsible as well. To be sure, lossy conversion is available -- but using a format developed as an open standard with ease-of-implementation and standards reuse in mind in mind (and thus which is reasonably implementable by more than one vendor) strikes me as the Right Thing to do. Taking the idealist hat back off, I still support ODF -- because it makes the things I want to do with my IT infrastructure (using XPATH and a bunch of preexisting infrastructure to build servers based on the contents of site survey forms provided by sales reps) easy, and allows me the ability to leverage 3rd-party implementations of reused standards for which open toolkits are available in future infrastructure as well.
I said that the money has been (and is being) spent largely because of Massachusets. I didn't say Massachusets was actually taking advantage of it yet.
Office suites may compete on features, but not all of those features need imply format extensions. There used to be competition between different OS vendors' networking stacks as well, but I think we're all better off now that everyone uses Ethernet and speaks IP -- and that standardization hasn't resulted in stagnation in the operating system market or a mess of incompatible IP variants.
I find it interesting that you advance the argument that having a standardized final format is adequate and folks can use whatever source formats they please while slamming me for naiveté. Applications where the ability to send documents which can be edited and transformed between parties in different organizations is critical abound, so using a view-only destination format for external communication is clearly inadequate. Preserving presentation is fine in a significant number of cases -- but if I'm standardizing on the document format used for communicating site surveys (which may be parsed and used to automatically configure servers) between my company (where the engineering department does not run Windows), its support and sales staff and VAR force (which largely do), I need documents which are editable, archivable into a database server and queryable at each stage (the latter being something XForms is quite useful for; I understand that Microsoft's InfoPath may provide some comparable functionality).
Slashdot Mirror
At least here in Texas, unless you make a deal with the prosecutor, you don't get off the hook; you just get other people onto it. There's no concept of an "accomplice" here -- if you were involved in the crime, you're responsible for it as much as the person who pulled the trigger up until sentencing comes up (at which point you can argue how minimally you were involved). Think about what you're arguing here: Let's say your boss tells you to steal a car, and that he'll fire you if you don't. Do you honestly think that the fact that you were just following orders would get you off?
In civil cases, more than one defendant can be named -- and if your company is too cheap to pay for their own software, do you think they're going to have their lawyer defend you as well? (Further, if they go bust and the corporate veil can't be pierced, that leaves you as the only remaining defendant -- and that's a lousy position to be in).
In short, I would be extremely skeptical of any attempts to leverage your line of reasoning -- particularly now that copyright violation is in many cases a criminal rather than civil act -- without first consulting with a competent lawyer.
That's not what he argues, though.
If you RTFM, Bruce's article argues that as computing becomes a utility, security will become "baked in" such that 3rd-party, add-on security products will, to the extent that they exist at all, be implicit functionality that users don't need to think about. To the extent that security will become cheaper, that's because R&D on it will be largely paid for by the utilities (who have an interest in lowering costs) rather than the vendors (who don't).
Not the same thing at all.
The parent's proposal covers not just if/then, but all conditional jump instructions -- which are used by your compiler to implement if/then, switch, and other conditional flow control.
I can't argue that there are much bigger inefficiencies than the transcriptionists and billing clerks; indeed, you make a lot of good points along those lines. As for suitability of EHRs for smaller sites in general, we're mostly selling to smaller clinics presently, so they're the group I can most comfortably address.
We've traditionally had a significant amount of range in terms of customer satisfaction -- but our happier customers say we really have saved them significant amounts of time (no longer needing to do paperwork after hours) and money (automated coding == no need to be ultra-conservative to avoid getting caught in a mistake, hence more effective billing). The unhappier customers are the ones I interact with (being level 4 support tends to work out that way), but there've been less of them lately -- either level 1-3 support is getting better, or the product itself is improving; either of those is good news. To be sure, lots of EHRs are severely expensive -- but from my perspective (making one that's priced to be affordable even for 1- or 2-doctor practices), that's great. (As for needing to hire staff to maintain the system, we sell the hardware and provide remote administration and network backup service, and do pretty much everything else; it's sold as a black-box solution, so additional support staff aren't needed).
As for generating billing codes being difficult to automate -- yes, it's difficult to automate. That said, we've done it, and we haven't had a customer fined yet for an inaccurate code we generated -- indeed, I've yet to hear of such a bug. Given the severity if we goofed up, QAing the logic in question is something we put a lot of work into.
And yes, I entirely agree about many many many healthcare-related systems having security as an afterthought at best -- but that's a topic for a different discussion.
You've got questions, I've got answers -- though if it looks like we might need to get into much more detail, this discussion might be best taken offline.
1) For the physicians, the preferred UI is a tablet PC with all the handwriting recognition controls installed. I don't know that we've tested those with Citrix, and I wouldn't be surprised if there were problems. That said, if you don't need the handwriting recognition, the client platform is just Firefox and IE; nothing there should be trouble.
2) That's an area of ongoing work. We have a multi-tiered architecture intended to support a "just-throw-more-servers-at-it" approach -- bunch of app servers on that tier, an Oracle RAC cluster on the database tier, and there you go. That said, I wouldn't deploy it to a customer site until we've had a full dev and QA cycle with that kind of hardware (and Oracle RAC licenses for dev and QA) in-house. That might be happening in the rather near future -- but it hasn't happened yet. If a pretty good sized healthcare provider came to us and indicated that they'd be willing to pay for the hardware and RAC licenses, it'd probably happen pretty darned fast.
3) We introduced strong auditing within the last year, as part of our drive for CCHIT compliance.
4) We have some clinics that maintain hours significantly longer than 8x5, and our current release fixes the backup system such that there isn't regular downtime required for that process; consequently, we have no remaining known issues which would prevent 24x7 operation. As for HA, see the answer to #2 -- multi-tiered architecture, multiple servers to a tier, redundant shared storage at the database tier.
5) If you want the handwriting recognition, we have a Firefox plugin which adds that support on Windows. To stop it from potentially conflicting with any other Gecko-based browser installs, we have a rebranded Firefox branch which comes with this plugin preinstalled. Other than that, nothing fancy. There might be some gotchas left relating to IE7/Vista; getting those ironed out is very much on our TODO list, though.
Yes. My point (which I meant to reinforce via use of italics) is that having a comprehensive standard in existence doesn't do much good until it's actually implemented across enough products to provide meaningful interop. Making it a CCHIT requirement would make that happen, or having a big player like GE go first.
Having a standards-compliant format that covers progress notes in particular would be great, and I look forward to this getting on our radar as something to implement. That said, until there's a major competitor using it who we want to provide interoperability with or a migration path from, or we have prospective customers inquiring, it's going to be a hard thing to push onto the schedule. Limited number of development hours, full slate of features planned... you know the drill.
Unless, of course, it's already on the schedule. I'm not really involved in planning new features unless there's a question of feasibility that the Java folks on staff can't answer unassisted, so I wouldn't necessarily know.
In short: Our technical platform was determined by engineering, not marketing, and it shows.
Next question?
I said "widely accepted and comprehensive". Having a standard is one thing; having a widely implemented standard is another. Frankly, I don't see ubiquitous acceptance of a common format until it's required for CCHIT.
- Overhead. Doctors need to hire transcriptionists and billing clerks to do work that could be largely automated. (Our product addresses this).
- Ease-of-use. Most of the EHRs on the market require an office to switch to a very low patient load for a very long training period. This makes migration to a product intended to improve communications and efficiency into an extremely expensive and cumbersome proposition. (Our product addresses this).
- Lack of communications (or standardized records formats). There are *some* standards (HL7 is what we use for integration with 3rd-party scheduling and billing systems where possible), but nothing widely accepted and comprehensive enough to be able to give a patient a flash drive with their complete medical history in a format any doctor's EHR product will understand. Worse, a lot of systems won't integrate with anything else without requiring the customer to fork out serious $$$ for the add-on functionality. (As just one small vendor, there's not so much we can do about this right now)
There are a bunch of other benefits that EHR vendors try to sell folks on -- automatic warnings about allergies, ability to guide the physician towards checking for symptoms that could indicate a serious problem, etc etc etc; I'm coming at this from the back-office geek point of view, though, so I really have no idea how significant these are in the grander scheme of things.Is adding more expensive IT products magic fairy dust that'll make healthcare cheap? Of course not. But technology that's well-thought-out, well-implemented and sanely priced certainly can help to make healthcare less expensive -- and putting records in a portable format benefits everyone.
(That said, there's a lot of poorly-implemented technology in healthcare... but that's a topic for a different, much more anonymous forum).
There are experimental shells for Unix that do that sort of thing; most of us just don't see the point.
http://geophile.com/osh/index.html
http://dispatch.sourceforge.net/
Take a look at Boo's typing system -- it's friggin' beautiful. The compiler infers the type, but then does proper compile-time checking based on it, and lets you explicitly select duck typing behavior (at a per-declaration level) if you want.
I haven't used it for anything serious yet, and as previously discussed, I'm a Pythonista; you may not find Boo quite as interesting as I do... but then again, you might.
Pretty much right. Some little nitpicks...
.NET, VB.NET is also fully-supported/top-level, so giving C# some special status as first-class citizen among .NET-targeted languages isn't necessarily accurate. (This is different from Java, since last I knew, all languages other than the Java language targeting the JVM bytecode were effectively second-class citizens).
.NET virtual machine is also known as the CLR ("Common Language Runtime").
.NET/Java wars unless folks go writing code that doesn't port to Mono -- which is unfortunately quite a bit easier than it ought to be).
While C# is one of the primary programming languages for
The
(I'm a Pythonista, myself, so I don't really care too much about the
Subversion's backend is a transactional filesystem (though it sits on top of a BDB interface or a separate FS), and many of the tools it provides work by describing a set of changes as filesystem operations (go down this directory, now go down that directory, now open this file, now seek to this position, now write this text...)
That said, revision control is about much, much more than just storing snapshots that can be retrieved later. Think about branching and merging -- particularly intelligent merge algorithms where you want metadata about exactly where each patch that was merged came from such that if you merge two branches you aren't trying to re-merge patches common between the two. Also, the storage constraints for a revision control system are tighter -- you want to compress your deltas, since you're going to be storing tens of thousands of revisions.
There are also requirements such as being able to backup and restore your full history; modify it (in corner cases -- let's say a developer checked in some test code with a critical password hardcoded); and do all sorts of other things that a COW filesystem won't typically have written support for.
Taking a naive view of revision control that leaves out branching and merging is a sure way to make revctl geeks mad at you (or ignite a snapshot-versus-changeset flamewar -- the snapshot view, which is what a filesystem approach [like what SVN does] lends itself to, is considerably less powerful than the changeset approach [like what BitKeeper or Arch do] in terms of the merge algorithms that can be welded on top without a force-fit).
If information shouldn't be public, lobby your congresscritters (at the state level, mostly) to get it out of public records. Relying on the "security" of having something be inconvenient to access is a false security at best; all it does right now is limit access to this information to those willing to pay (not very much $$) to get at it. It's nothing but security through obscurity -- and while there are cases where that can be useful, giving folks a perception of privacy while they actually enjoy no such thing is hardly one of them.
By highlighting what information is available through public records, Google both helps promote government transparency, and makes it easy for folks to know what information is out there. Maybe if it's impossible to ignore how bad mothers' maiden name and SSN are for authentication tokens, people will stop using them as such. Imagine!
On light quality with CFLs, you might find this interesting.
We're talking about CFLs, not standard fluorescents. CFLs typically have less than 9mg of mercury -- and given that I could consume that 9mg of mercury with no ill effects whatsoever, I find the "6000 gallons of drinking water" claim difficult to believe.
Who gives a fuck? The folks who are reading the thread, that's who. When you're having an argument in a public forum (particularly of the mixed-audience variety), the audience is part of the point: They're the folks who are being informed or entertained, deciding which of 'yall do believe, and effectively keeping score.
When you don't care enough about your opponent or your audience to make an effort to proof your post for spelling or grammar errors, it's implicit that you probably also didn't care enough to do any factual research -- and that you certainly don't respect the audience enough put together something which flows well when read.
Being right on the facts is important, and I'm not commenting on the merits of the individual arguments here (except to note that your opponent need not worry excessively much about "saving face" -- right or wrong, there's obviously research behind their position) -- but online, as in real life, form is important as well.
My slashdot posts, like almost all of my activity online, are part of a Real Life identity that I wouldn't mind a potential employer digging up and going through. Can you say the same?
This is more a matter of removing the motive for $OTHER_COUNTRY to try to confuse the US's offensive infrastructure by destroying disabling our GPS satellites. It works both ways, obviously, if $OTHER_COUNTRY is using similar technology -- but any missile which is going to do really significant damage will be able to get close enough to where it needs to be using inertial guidance, so the example you give isn't a serious concern.
Moreover, disabling GPS is really an asymmetric threat -- it's easy to do (if you're China, for whom the necessary technology is already a sunk cost), and has an impact on your opponent far greater than its marginal cost. Avoiding unfavorable asymmetric threats is a Good Thing.
I'm right now working (effectively) as programmer-at-large in a late-stage startup. Most of our technical staff have a specialty (be it Java, or Oracle, or network administration); I'm the guy who gets all the interesting problems that don't fall so neatly into one specialist's space. As such, I get a wide array of projects to build and ideas to analyze for feasibility -- and having as many tools in my toolbox as possible is critical to doing this well. Being able to easily write tools that interact with office documents is, as tools go, quite powerful; I've alluded elsewhere to some of what I can do with that kind of ability. So -- if you're acting as an end-user, having a readily manipulable document format may not provide so much by way of direct benefits. As a toolmaker, on the other hand, I find it extremely useful -- and hopefully some of that utility filters down in terms of extra value to the user provided (directly or indirectly) by the tools that standards-based formats enable.
Realistically and short-term, though, yes, this is largely corporate-environment stuff -- the tools I write generally fall into the realm of site-local, proprietary infrastructure. That said, I would hope that the indirect benefits of the larger product this infrastructure supports being (ever so slightly) cheaper and more efficient to produce would have some kind of positive impact, noticeable or otherwise, on society as a whole.
Putting my idealist hat on, I'd argue that in cases where documents are intended to be disseminated to the public at large, accessibility (to those who can't afford MS Office or those who run on a platform where Office is unavailable) is socially responsible as well. To be sure, lossy conversion is available -- but using a format developed as an open standard with ease-of-implementation and standards reuse in mind in mind (and thus which is reasonably implementable by more than one vendor) strikes me as the Right Thing to do. Taking the idealist hat back off, I still support ODF -- because it makes the things I want to do with my IT infrastructure (using XPATH and a bunch of preexisting infrastructure to build servers based on the contents of site survey forms provided by sales reps) easy, and allows me the ability to leverage 3rd-party implementations of reused standards for which open toolkits are available in future infrastructure as well.
I said that the money has been (and is being) spent largely because of Massachusets. I didn't say Massachusets was actually taking advantage of it yet.
Office suites may compete on features, but not all of those features need imply format extensions. There used to be competition between different OS vendors' networking stacks as well, but I think we're all better off now that everyone uses Ethernet and speaks IP -- and that standardization hasn't resulted in stagnation in the operating system market or a mess of incompatible IP variants.
I find it interesting that you advance the argument that having a standardized final format is adequate and folks can use whatever source formats they please while slamming me for naiveté. Applications where the ability to send documents which can be edited and transformed between parties in different organizations is critical abound, so using a view-only destination format for external communication is clearly inadequate. Preserving presentation is fine in a significant number of cases -- but if I'm standardizing on the document format used for communicating site surveys (which may be parsed and used to automatically configure servers) between my company (where the engineering department does not run Windows), its support and sales staff and VAR force (which largely do), I need documents which are editable, archivable into a database server and queryable at each stage (the latter being something XForms is quite useful for; I understand that Microsoft's InfoPath may provide some comparable functionality).
I've done a lot of reading on how ODF was created, and I hold to my position.