It's only a kludge because Linux is designed that way. Look at an something like FMI/OS, and filesystem drivers fit into userland perfectly (though for that matter, so do the disk controller's drivers -- and darned dear everything else!). (I very much like FMI/OS's design, btw -- it means that practically everything can be replaced or restarted at runtime -- or run step-by-step in a userland debugger living on the same host! Let's see Linux do that).
I use Linux at work (and at a lot of play I can talk people into paying me for)... but I certainly don't consider it even close to the last word in kernel design. Microkernels can be made very clean and very fast, if done correctly.
I'm not distributing the API's header files. It doesn't matter that I make a copy in RAM on my machine.
Not so much, no -- but it does matter that the final binary is derived from them; the precompiler's output is the last human-readable representation of what your software is before it undergoes transformation into a binary blob. Could you have created a binary compliant with the covered software's ABI without either the inclusion of the header files within the precompiler's output [and thus the compiler's input]? (Additionally, to what extent is your source impacted by the creative decisions of the individual designing the library? If you're writing to a GPLed framework [Qt without the commercial license is a good example here], it's likely that the very structure of your program is based around that fact).
Admittedly, it's a gray area -- after all, a header at its core can be functional when stripped of its creative aspects and reduced to a machine-readable description of a method for using an API [which arguably doesn't contain any copyrightable elements, being written exactly as it is because nothing else will serve interoperability], and the compiler can be argued to likewise include only those purely functional, arguably non-protectable elements within its output. (This doesn't necessarily apply if there are macros defined in the header which could be written differently, but let's take it for granted for the moment that such isn't the case here).
I'll certainly grant that an effective argument can certainly be made both ways -- but I can nonetheless see the FSF's point of view. More to the point, selecting the GPL or LGPL as a license is a clear and explicit statement of intent on the part of the copyright holder, and I would be shocked to see a judge choose to rule against Trolltech in a manner which eviscerates their revenue model in favor of allowing freeloaders to make unrestricted commercial use of their work in violation of their explicitly stated intent.
Says the FSF. Which Federal Court agrees with them?
About what?
Agrees that writing software against a different program's API implies derivation? No court, but it's a pretty damned easy argument to make, at least for programs written in C and C++ (and other languages where libraries' headers are included during a precompilation phase): You're writing your code the way you do only because of the external API being structured the way it is, and would not write your code that way otherwise. Moreover, structures and values from the API's header files are copied into your source during precompilation. There may not be settled precedent -- but in a precedent-setting case, this would be a favorable side to be on.
Agrees that writing software against a standard API doesn't imply derivation from any specific implementation of that API? Well, duh. If you statically link your code with that implementation to generate a binary, that binary certainly is a derivative work -- but if you're doing dynamic linking, your generated binary does not contain any portion of the work (other than the structures &c. from the header -- but because those are generated to conform with the 3rd-party API, there's no creative [and thus no copyrightable] element in them), and your source neither contains any portion of the work or is influenced in any way individually traceable back to the work.
The FSF's position may not have been fully validated by case law, but it is a very reasonable interpretation, prone to being effectively argued in court. Remember that to a significant extent, the reason there is relatively little case law regarding the FSF's interpretation of their licenses is that offending parties whom the FSF has communicated with almost universally settle.
Static linking implies derivation, because the executable contains code from the library as well as the covered program. Shared library linkages only imply derivation if the program in question is written to use an interface which is specific to the covered program -- so the standard C library does not apply. It makes sense: If I'm writing to the libgnome API, I'm creating a product which would not possibly work without libgnome. If I'm writing to the standard C API, I'm creating something which works with all manner of standard C libraries; if my code happens to be dynamically linked against a GPLed C library implementation, that doesn't change the fact that that code was not in any way written with knowledge of the specific implementation.
The GPL, taken literally, can be reasonably complied with.
Hm, right. I guess I must have been thinking of the LGPL, which says "linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library".
The LGPL's preamble is guilty of some of the overreaching you refer to, but the license itself clarifies (in section 5) that generated executables are derived works only inasmuch as they contain parts of the library (which is indeed the case with static linking) or potentially in cases where a program is dependent on a covered program's headers to compile (but the license text makes it explicit in these cases that copyright law is not entirely clear what constitutes a derivative work in these cases). Obviously, in cases where those headers implement a standardized interface (for which differently licensed implementations exist), 3rd party software is not dependent on said headers to compile (though they can optionally be compiled with these headers); hence, no grounds to argue status as a derivative work.
If you ignore the preamble and focus on the text, there's not much there that's objectionable.
You're overstating the GPL's claimed definition. GPLv2 simply references copyright law's definition of derived works; only GPLv3 specifically references shared-library linkages as inferring derivative status, and even then only when the 3rd-party code is written to the interface provided by the GPLed code ("shared libraries and dynamically linked subprograms that the work is specifically designed to require", such that use of a common, standardized interface not specific to some GPLed work is explicitly acceptable).
My wife is obese but has the lowest blood pressure of her entire immediate family (well within range for normal, healthy people with a reasonable weight).
In the common case, high blood pressure is fat people -- but assuming that your rules hold in all cases is just asking for trouble.
Nothing evil about it, so long as the pool within each tiered risk level is sufficiently large that an incident such as cancer or heart surgery is rare enough to be smoothed out.
I'm not necessarily even arguing that tiering should be done along the lines of hereditary factors... but putting smokers or alcoholics in the same tier as individuals who avoid vices damaging their health is every bit as unreasonable as putting cancer patients in a tier all their own.
I had always thought that the point of insurance was to spread the risk of an incident over a large number of people, and over a large period of time.
Well, yes.
But spreading risk over people within a comparable risk profile means that you normalize out the chance of losing your house over a non-elective life-saving surgery, but without subsidizing the lifestyles of those who make less health-centric decisions. Doing that, though, means price discrimination based on risk profile is necessary.
Look -- I have a benign but unusual cancer in my personal medical history, and my wife's family medical history is ugly as well; I'm not some health nut who's freaking out at paying the health costs for everyone less fanatic than me. That said, normalizing risks across comparable lifestyles without normalizing them for everyone is entirely legitimate; it means, among other things, that individuals have motivation to take some reasonable level of personal responsibility for their health, while still allowing recovery from unforseeable events.
Is normalizing out things like family history and diseases not caused by known and avoidable factors a reasonable thing for insurance to do? It can be argued either way... but at least some level of tiered pricing is entirely and inherently appropriate. Smokers, alcoholics, skydivers and the like create extra costs which, unless internalized (and charged to them individually) are borne by everyone in the system; ergo, it's only fair in such cases for pricing to be tiered. Weight, BMI and other measures of actual health (as opposed to individuals' actions) are trickier to decide on a fair policy regarding, because these can be heavily influenced by family history -- but to say that insurance should by its nature normalize everyone's risks regardless of what those individuals choose to do leads to less than desirable results.
re. "Isn't the entire point of insurance to charge higher for higher risk people, and lower for lower risk people?"....well, no. That would be a state called "uninsured".
Flood insurance is more expensive if you're on a floodplain. Fire insurance is cheaper if you're next door to a fire station or your house is constructed of concrete and steel. Auto insurance varies with your driving record and other factors indicative of your risk level.
Some state governments have programs available for folks who are otherwise unable to find coverage. It's not necessarily cheap, but it's something rather than nothing.
I can't speak for Cincinnati, but to my knowledge most US cities in areas with any local agricultural community have farmers markets at least weekly; Austin, San Jose and Chico (roughly my last three places of residence) have all had these, and farming co-ops are not by any means unheard of (my mother is a member of one in her hometown near Seattle, where she assists with gardening in exchange for a reduced price on the food they grow). Whole Foods and its ilk also have significant penetration within the US, and companies specializing in home delivery of locally grown (or, failing that, organic) foods are not by any means unheard of.
That said, almost all supermarkets carry some amount of fruit, and have for as long as I can remember; the only reason I can think of that your coworker would have directed you to a location outside town was the "fresh" qualifier.
I was in the same boat about 6 years ago (except for being much younger and closer to the start of my professional career); I moved from California to Austin, bought a house (for about twice my pre-tax annual salary), and have been quite happy in the time since. (That's the ultra-summarized version, of course, but the gist for these purposes is accurate).
I'm not saying you don't have room to complain -- but I am saying that there's something you could do about it.
In terms of personal experiences -- in all the cases I'm personally familiar with the attacker was a family member, not a random stranger online. Granted, a good chunk of these date back to before Internet access was widely available.
I've seen alarming numbers myself regarding the behavior of random strangers online -- but those were numbers regarding total attempts, as opposed to successful attempts. There's a very big difference, and I'd argue that the latter is what defines the scope of the problem.
(All that said -- I've spent years as part of a household with children, but not where said kids have been at a point where they have (or are interested in) unsupervised Internet access. Certainly, there are issues to be wrestled with, and I don't mean to indicate that unsupervised communication with random strangers is OK so long as children know not to go along with whatever those strangers suggest. However, my current view is that there are a lot of potential bad influences on the Internet. Are predators unsuccessfully fishing for victims as serious a problem as porno spam and popups or peers who cuss uncontrollably in online games or a culture that promotes shorthand and poor spelling to the point where they bleed into schoolwork and (later) business communications? As long as predators are unsuccessful, they're just one of a multitude of comparable issues [which do need to be handled, lest the baby go with the proverbial bathwater]; it's only when they're successful that they constitute a problem of a different magnitude entirely).
Sexual exploitation of minors is a serious problem in this country.
Really? Are you making this statement on your personal knowledge of the relative statistics on how often it happens in the US as opposed to elsewhere in the world (and the probability of a child ever being an actual, as opposed to attempted, victim), or do you simply take the position that it's a serious problem because the media (which, after all, makes money off of the eyeballs they can hold when talking about scary and dramatic things) and the special-interest groups (who would like to promote legislation to log all mechanisms by which folks can communicate on the Internet, or make web site owners liable for a failure to screen users who sign up for their system, or do any number of other silly and impractical things) says that it's so?
I've seen a lot of bad legislation crafted by people whose cry is "think of the children!", and I've seen a lot of bad memes (don't talk to strangers!) spread by well-meaning parents who overestimate the risk their children are at otherwise. My distinct impression is that the majority of things categorized as sex crimes are comparatively harmless (public urination, consensual sex between an 18-year-old and a 17-year-old), but the public as a whole thinks about them (and decides on appropriate punishments) based only on the most dramatic examples (sexual abuse of young children by adults). I'm not saying that legislation intended to protect children is inherently invalid, or that teaching children to think critically about things they're told by people they don't have reason to trust is inappropriate... but I am saying that humans tend to overestimate dramatic risks (terrorism, sexual predators, airplane crashes) and underestimate everyday ones (car accidents), and overreaction is extremely easy to do.
(Your general point -- that laws making attempts to commit a crime punishable are valid, and thus that Dateline's actions are legitimate -- is something I agree with wholeheartedly; however, the argument that the specific issue of sexual abuse of children is an extremely widespread and serious problem within the United States in particular is something which I simply do not buy).
Ron Paul will be taken seriously when he can explain how he is "in support of personal liberty" but is pro-life.
That's easy: Ron Paul keeps his personal beliefs out of his politics. It's the same way he's personally opposed to homosexuality but consistently votes against attempts to legislatively disallow states the ability to recognize gay marriages: His principals regarding the proper role of the federal government trump his personal beliefs regarding how individuals should behave.
Ron Paul the individual is very much anti-choice, and is not quiet about that position. Ron Paul the Senator does not believe it is the federal government's role to allow or disallow abortion, but rather is a decision which properly belongs to the states. Every bit as importantly, his behavior in other cases where his personal beliefs conflict with his political principals is consistent with this explanation.
While I am pro-choice, I am also in favor of a smaller, more constitutionally limited federal government (with the roles abandoned by such a government taken over by the states). As such, Ron Paul's position resonates with me. I may not agree much with Ron Paul the person, but I would be quite happy to elect Ron Paul the Senator as President.
You'll never roll-your-own for cheaper than SenSage/EMC-Centera.
Let me correct that:
You'll never roll-your-own comparable solution for cheaper than SenSage/EMC-Centra. There, done.
Not everyone needs gigabytes of log data every day, or even hundreds of megs. If you're designing something to meet extremely demanding requirements, you're clearly going to make design decisions which involve more development time and expenditure than if you were designing to target less extensive requirements. On the low end, one can keep logs on random-access media (with offsite backup) and contract with a third party digital notary service such as Surety or DigiStamp to make them tamper evident.
Nearly as capable as the SenSage solution? Of course not. Cheaper? Hell, yes.
Killing people is a well-understood problem space, with a multitude of solutions. Almost anyone can implement onesuch solution in linear time, though frequently with unintended side effects.
Attacking a strong secure hash function is a poorly-understood problem space, for a sufficiently restricted definition of "strong secure hash function". "[R]un[ning] [a] computer program" isn't so much the issue; writing a computer program which will finish execution with a useful result before the end of the universe is the trick.
There are cryptographic protocols which are provably secure (at least within the bounds of current technology). When such protocols are correctly implemented within a real-world system with adequate safeguards, it is entirely possible to set up security mechanisms which hold (for adequately restricted values of "hold" -- such as being tamper-evident rather than tamper-proof) even against attacks by major governments. Such a system needs to be designed to withstand collusion between multiple insiders (who presumably can be bought) -- but such is not impossible, only very difficult.
Saying that an opponent with resources which, while substantial, are less than those which major governments use to protect or steal each others' secrets could break any system whatsoever is simply giving up.
Of course the datetime field is covered by the clearsigning.
But who provides the datetime field? Is it part of the data being clearsigned, or part of the signature? If the former, it's inadequate -- the notary service should be able to vouch for the point in time when the signing took place, in a way which can't be subverted by the entity requesting the signature. (I used to know OpenPGP quite well -- tried to do a GnuPG port to PalmOS once -- but that was a long time ago, and memory retention has never been among my strengths).
And a missing file is obvious when the sequence is chronologically fixed.
Only if the files can't be copied or renamed without notice. Copy ${RANDOM_GOOD_AUDIT_LOG} over ${BAD_AUDIT_LOG} and it may be noticed if a human looks at it and sees that the timestamps within the data are wrong -- but a typical quick little check-all-the-signatures shell script won't.
However, you have a good point that data retention has to be considered. But the OP only asked for alteration.
Adding or removing a file from a sequence of files (or overwriting one file in the sequence with another having an individually valid signature) is alteration, or close as makes no difference. Sure, it's alteration of the sequence, rather than alteration of an individual file, but do you think that makes any difference from a SOX-compliance perspective?
That said... the HIPAA requirements for what constitutes write-once status (as our HIPAA consultant explained them to us) are laughable. I'm presuming in all of this that SOX is a bit more serious.
If you have that kind of access to a system you can change anything you like. Probably if you're in charge of this system you are also in charge of the signing service also - go set it's clock back, recommit your modified files to the backup, set the clock correctly again, and voila!
This is why the signing service should be run by a separate business entity with a reputation to protect. If I had the money, I'd hire Counterpane. "Open source" != "securely implementable in-house".
There are no end of ways to work around the system, at some point it has to be "fit for purpose". Automating everything and locking the machines down in a secure location with logs of who accessed that location and when is probably good enough, no? After all, if there is something really damaging that you want to get rid of, "Damn, we had a fire in our storage center" or "Lost in transit" are actually much easier to pull off and leave no recovery method.
Only one storage center and no offsite backup? No offsite backup of the copy you sent by courier? You're probably not SOX compliant.
(I don't know SOX; I do know HIPAA, but it's considerably more lenient).
Clearsigning alone isn't enough -- someone can delete a clearsigned file, and you'll never know it went missing.
You also need to chain them -- have the signed data include the signatures for the last several signed entries -- and have a separately located, controlled, and secured trusted system be responsible for applying those signatures (and maintaining accurate timestamps within them; probably it should be its own Tier 1 time server, which isn't all that expensive with the ubiquity of GPS equipment these days).
I wouldn't say that an open source solution is infeasible. Cryptographic protocols for this kind of thing are well-established; I believe Applied Cryptography, 2nd edition included one when I read it a few times back in school. The result is not necessarily write-once -- but it is tamper-evident, which is close enough for horseshoes. (For true write-once, after all, one needs to use WORM media... and how many folks do that?)
The one that comes to mind is use of a digital notary service which does chained, timestamped signatures (such that each signature also includes the hashes of the documents which were signed before it, such that no documents can be added or removed to the history chain).
For obvious reasons, this digital notary service should be controlled by a separate, unrelated entity with no interest in the records being archived and a great deal of interest in its reputation. Perhaps Counterpane could be hired for the purpose? They'd also be some of the best folks available to implement it.
Slashdot Mirror
It's only a kludge because Linux is designed that way. Look at an something like FMI/OS, and filesystem drivers fit into userland perfectly (though for that matter, so do the disk controller's drivers -- and darned dear everything else!). (I very much like FMI/OS's design, btw -- it means that practically everything can be replaced or restarted at runtime -- or run step-by-step in a userland debugger living on the same host! Let's see Linux do that).
I use Linux at work (and at a lot of play I can talk people into paying me for)... but I certainly don't consider it even close to the last word in kernel design. Microkernels can be made very clean and very fast, if done correctly.
Admittedly, it's a gray area -- after all, a header at its core can be functional when stripped of its creative aspects and reduced to a machine-readable description of a method for using an API [which arguably doesn't contain any copyrightable elements, being written exactly as it is because nothing else will serve interoperability], and the compiler can be argued to likewise include only those purely functional, arguably non-protectable elements within its output. (This doesn't necessarily apply if there are macros defined in the header which could be written differently, but let's take it for granted for the moment that such isn't the case here).
I'll certainly grant that an effective argument can certainly be made both ways -- but I can nonetheless see the FSF's point of view. More to the point, selecting the GPL or LGPL as a license is a clear and explicit statement of intent on the part of the copyright holder, and I would be shocked to see a judge choose to rule against Trolltech in a manner which eviscerates their revenue model in favor of allowing freeloaders to make unrestricted commercial use of their work in violation of their explicitly stated intent.
Agrees that writing software against a different program's API implies derivation? No court, but it's a pretty damned easy argument to make, at least for programs written in C and C++ (and other languages where libraries' headers are included during a precompilation phase): You're writing your code the way you do only because of the external API being structured the way it is, and would not write your code that way otherwise. Moreover, structures and values from the API's header files are copied into your source during precompilation. There may not be settled precedent -- but in a precedent-setting case, this would be a favorable side to be on.
Agrees that writing software against a standard API doesn't imply derivation from any specific implementation of that API? Well, duh. If you statically link your code with that implementation to generate a binary, that binary certainly is a derivative work -- but if you're doing dynamic linking, your generated binary does not contain any portion of the work (other than the structures &c. from the header -- but because those are generated to conform with the 3rd-party API, there's no creative [and thus no copyrightable] element in them), and your source neither contains any portion of the work or is influenced in any way individually traceable back to the work.
The FSF's position may not have been fully validated by case law, but it is a very reasonable interpretation, prone to being effectively argued in court. Remember that to a significant extent, the reason there is relatively little case law regarding the FSF's interpretation of their licenses is that offending parties whom the FSF has communicated with almost universally settle.
Nuh-uh -- read the license before you spout off.
Static linking implies derivation, because the executable contains code from the library as well as the covered program. Shared library linkages only imply derivation if the program in question is written to use an interface which is specific to the covered program -- so the standard C library does not apply. It makes sense: If I'm writing to the libgnome API, I'm creating a product which would not possibly work without libgnome. If I'm writing to the standard C API, I'm creating something which works with all manner of standard C libraries; if my code happens to be dynamically linked against a GPLed C library implementation, that doesn't change the fact that that code was not in any way written with knowledge of the specific implementation.
The GPL, taken literally, can be reasonably complied with.
If you ignore the preamble and focus on the text, there's not much there that's objectionable.
You're overstating the GPL's claimed definition. GPLv2 simply references copyright law's definition of derived works; only GPLv3 specifically references shared-library linkages as inferring derivative status, and even then only when the 3rd-party code is written to the interface provided by the GPLed code ("shared libraries and dynamically linked subprograms that the work is specifically designed to require", such that use of a common, standardized interface not specific to some GPLed work is explicitly acceptable).
In the common case, high blood pressure is fat people -- but assuming that your rules hold in all cases is just asking for trouble.
Nothing evil about it, so long as the pool within each tiered risk level is sufficiently large that an incident such as cancer or heart surgery is rare enough to be smoothed out.
I'm not necessarily even arguing that tiering should be done along the lines of hereditary factors... but putting smokers or alcoholics in the same tier as individuals who avoid vices damaging their health is every bit as unreasonable as putting cancer patients in a tier all their own.
But spreading risk over people within a comparable risk profile means that you normalize out the chance of losing your house over a non-elective life-saving surgery, but without subsidizing the lifestyles of those who make less health-centric decisions. Doing that, though, means price discrimination based on risk profile is necessary.
Look -- I have a benign but unusual cancer in my personal medical history, and my wife's family medical history is ugly as well; I'm not some health nut who's freaking out at paying the health costs for everyone less fanatic than me. That said, normalizing risks across comparable lifestyles without normalizing them for everyone is entirely legitimate; it means, among other things, that individuals have motivation to take some reasonable level of personal responsibility for their health, while still allowing recovery from unforseeable events.
Is normalizing out things like family history and diseases not caused by known and avoidable factors a reasonable thing for insurance to do? It can be argued either way... but at least some level of tiered pricing is entirely and inherently appropriate. Smokers, alcoholics, skydivers and the like create extra costs which, unless internalized (and charged to them individually) are borne by everyone in the system; ergo, it's only fair in such cases for pricing to be tiered. Weight, BMI and other measures of actual health (as opposed to individuals' actions) are trickier to decide on a fair policy regarding, because these can be heavily influenced by family history -- but to say that insurance should by its nature normalize everyone's risks regardless of what those individuals choose to do leads to less than desirable results.
Try again.
Some state governments have programs available for folks who are otherwise unable to find coverage. It's not necessarily cheap, but it's something rather than nothing.
I can't speak for Cincinnati, but to my knowledge most US cities in areas with any local agricultural community have farmers markets at least weekly; Austin, San Jose and Chico (roughly my last three places of residence) have all had these, and farming co-ops are not by any means unheard of (my mother is a member of one in her hometown near Seattle, where she assists with gardening in exchange for a reduced price on the food they grow). Whole Foods and its ilk also have significant penetration within the US, and companies specializing in home delivery of locally grown (or, failing that, organic) foods are not by any means unheard of.
That said, almost all supermarkets carry some amount of fruit, and have for as long as I can remember; the only reason I can think of that your coworker would have directed you to a location outside town was the "fresh" qualifier.
As far as DOSbox is concerned, Quake is data.
I was in the same boat about 6 years ago (except for being much younger and closer to the start of my professional career); I moved from California to Austin, bought a house (for about twice my pre-tax annual salary), and have been quite happy in the time since. (That's the ultra-summarized version, of course, but the gist for these purposes is accurate).
I'm not saying you don't have room to complain -- but I am saying that there's something you could do about it.
In terms of personal experiences -- in all the cases I'm personally familiar with the attacker was a family member, not a random stranger online. Granted, a good chunk of these date back to before Internet access was widely available.
I've seen alarming numbers myself regarding the behavior of random strangers online -- but those were numbers regarding total attempts, as opposed to successful attempts. There's a very big difference, and I'd argue that the latter is what defines the scope of the problem.
(All that said -- I've spent years as part of a household with children, but not where said kids have been at a point where they have (or are interested in) unsupervised Internet access. Certainly, there are issues to be wrestled with, and I don't mean to indicate that unsupervised communication with random strangers is OK so long as children know not to go along with whatever those strangers suggest. However, my current view is that there are a lot of potential bad influences on the Internet. Are predators unsuccessfully fishing for victims as serious a problem as porno spam and popups or peers who cuss uncontrollably in online games or a culture that promotes shorthand and poor spelling to the point where they bleed into schoolwork and (later) business communications? As long as predators are unsuccessful, they're just one of a multitude of comparable issues [which do need to be handled, lest the baby go with the proverbial bathwater]; it's only when they're successful that they constitute a problem of a different magnitude entirely).
I've seen a lot of bad legislation crafted by people whose cry is "think of the children!", and I've seen a lot of bad memes (don't talk to strangers!) spread by well-meaning parents who overestimate the risk their children are at otherwise. My distinct impression is that the majority of things categorized as sex crimes are comparatively harmless (public urination, consensual sex between an 18-year-old and a 17-year-old), but the public as a whole thinks about them (and decides on appropriate punishments) based only on the most dramatic examples (sexual abuse of young children by adults). I'm not saying that legislation intended to protect children is inherently invalid, or that teaching children to think critically about things they're told by people they don't have reason to trust is inappropriate... but I am saying that humans tend to overestimate dramatic risks (terrorism, sexual predators, airplane crashes) and underestimate everyday ones (car accidents), and overreaction is extremely easy to do.
(Your general point -- that laws making attempts to commit a crime punishable are valid, and thus that Dateline's actions are legitimate -- is something I agree with wholeheartedly; however, the argument that the specific issue of sexual abuse of children is an extremely widespread and serious problem within the United States in particular is something which I simply do not buy).
It's possible to buy a new phone without camera support. Tricky (and ended me up with a big, bulky Blackberry), but possible.
Ron Paul the individual is very much anti-choice, and is not quiet about that position. Ron Paul the Senator does not believe it is the federal government's role to allow or disallow abortion, but rather is a decision which properly belongs to the states. Every bit as importantly, his behavior in other cases where his personal beliefs conflict with his political principals is consistent with this explanation.
While I am pro-choice, I am also in favor of a smaller, more constitutionally limited federal government (with the roles abandoned by such a government taken over by the states). As such, Ron Paul's position resonates with me. I may not agree much with Ron Paul the person, but I would be quite happy to elect Ron Paul the Senator as President.
You'll never roll-your-own comparable solution for cheaper than SenSage/EMC-Centra.
There, done.
Not everyone needs gigabytes of log data every day, or even hundreds of megs. If you're designing something to meet extremely demanding requirements, you're clearly going to make design decisions which involve more development time and expenditure than if you were designing to target less extensive requirements. On the low end, one can keep logs on random-access media (with offsite backup) and contract with a third party digital notary service such as Surety or DigiStamp to make them tamper evident.
Nearly as capable as the SenSage solution? Of course not. Cheaper? Hell, yes.
Killing people is a well-understood problem space, with a multitude of solutions. Almost anyone can implement onesuch solution in linear time, though frequently with unintended side effects.
Attacking a strong secure hash function is a poorly-understood problem space, for a sufficiently restricted definition of "strong secure hash function". "[R]un[ning] [a] computer program" isn't so much the issue; writing a computer program which will finish execution with a useful result before the end of the universe is the trick.
There are cryptographic protocols which are provably secure (at least within the bounds of current technology). When such protocols are correctly implemented within a real-world system with adequate safeguards, it is entirely possible to set up security mechanisms which hold (for adequately restricted values of "hold" -- such as being tamper-evident rather than tamper-proof) even against attacks by major governments. Such a system needs to be designed to withstand collusion between multiple insiders (who presumably can be bought) -- but such is not impossible, only very difficult.
Saying that an opponent with resources which, while substantial, are less than those which major governments use to protect or steal each others' secrets could break any system whatsoever is simply giving up.
That said... the HIPAA requirements for what constitutes write-once status (as our HIPAA consultant explained them to us) are laughable. I'm presuming in all of this that SOX is a bit more serious.
(I don't know SOX; I do know HIPAA, but it's considerably more lenient).
Clearsigning alone isn't enough -- someone can delete a clearsigned file, and you'll never know it went missing.
You also need to chain them -- have the signed data include the signatures for the last several signed entries -- and have a separately located, controlled, and secured trusted system be responsible for applying those signatures (and maintaining accurate timestamps within them; probably it should be its own Tier 1 time server, which isn't all that expensive with the ubiquity of GPS equipment these days).
I wouldn't say that an open source solution is infeasible. Cryptographic protocols for this kind of thing are well-established; I believe Applied Cryptography, 2nd edition included one when I read it a few times back in school. The result is not necessarily write-once -- but it is tamper-evident, which is close enough for horseshoes. (For true write-once, after all, one needs to use WORM media... and how many folks do that?)
The one that comes to mind is use of a digital notary service which does chained, timestamped signatures (such that each signature also includes the hashes of the documents which were signed before it, such that no documents can be added or removed to the history chain).
For obvious reasons, this digital notary service should be controlled by a separate, unrelated entity with no interest in the records being archived and a great deal of interest in its reputation. Perhaps Counterpane could be hired for the purpose? They'd also be some of the best folks available to implement it.