I have an excellent idea of how multistage clinical trials work, and why. I have family members who were strongly affected by well known drugs that failed to be safe in general practice.
The specific technique in question has worked in all the mammals it's been tried in. That doesn't mean you can just skip ahead to doing it in humans on large scale without trials, no. But it was having problems getting approval to get the trials started, in no small part because of the insane federal government stem cell regulations from the previous administration. T his was particularly offensive because it entirely uses the patient's own stem cells (you liposuction some body fat to extract the stem cells from), and had nothing to do with embryonic stem cells.
I wouldn't be complaining if it had been winding its way through approval. The FDA had threatened vets who were doing this and who had openly discussed doing a less rigorous Phase 0 study on themselves as human test subjects. Admittedly that's not nearly as rigorous as a fully rigorous Phase 0, but it will at least give you some bounds on serious side effects.
As an aside on the normal pharmaceutical testing protocol, there are cases where severe or uniformly fatal diseases exist and people will die anyways. It took a long time to get the FDA to approve shorter protocols and widening Phase III trials to allow a chance of saving some dying patients with the study phase drugs; some of the AIDS drugs were the catalytic agent for that change. There are some cases where even a worst case - the drug kills everyone who takes it - would not be necessarily a societal or individual moral disaster compared to the underlying diseases.
You should have enough risk mitigation from Phase 0 and Phase 1 that a wider Phase 2 in many acute or terminal conditions is entirely called for. A number of medical ethicists have commented that liability risks (someone will sue, even if their loved one would have died within a month anyways) and FDA inertia are holding back a number of treatments that fall into these categories.
Just to be clear - The joint repair stem cells aren't relevant to that question - joint injuries and damage are a quality of life not survival disease.
The one place where stem cell treatment seems to have good scientific basis - joint repair, where stem cells are centrifuged out of fat cells and injected into the joint - is stuck in FDA human trials hell in the US.
It works great in a number of animals, and is available for dogs and horses (at least) via vets.
There's no reason for him to go into a high security prison. It costs more for the feds to hold high security prisoners, he's never been accused of violence, he seems to be a low risk to guards or other prisoners. Him being a foreign national doesn't really play into it.
His supporters in England are using the "He could theoretically be sentenced to high-security!" as a scare tactic, along with a number of others. Sure, he could be - they could send him to SuperMax in Colorado. But they won't, because it's expensive and there's nothing he's done that justifies anything more than minimum security.
If he's convicted he gets to go to minimum security federal jail for probably 2-4 years. How is that savage punishment?
Aspergers is neither a cause of computer hacking nor an excuse for it. "Oh, a trial or jail will traumatize him" isn't a valid reason to not put someone on trial either in the US or in England.
This guy was misguided rather than intentionally malicious, but he misguided himself into a bunch of federal felonies. Aspergers doesn't change your ability to understand legal vs illegal acts.
The instability was due to the dynamics of the drogue parachute, which was intended to ensure that the vehicle didn't turn upside down due to air drag before the engine lit. It did that but the length of the parachute harness ended up being such that the vehicle moved unsteadily at that descent rate.
That's a minor problem and easy to fix, with a different length harness or other aerodynamics.
With a vehicle which was aerodynamically stable going down base first, it wouldn't be a problem either. That particular test craft (and Masten's similar one) will probably turn and fall nose-first if they fall any significant distance. These are low altitude test rockets, not the final high speed high altitude models, so some problems appear with these models that will be engineered out of the final models.
You fix those short-term problems with the most cheap and reliable band-aid you can, since you're planning on a different airframe as the long term fix. The parachute was the band-aid. Not a perfect band-aid, but an acceptable one.
Isn't that like an officer being able to tell the BAC of driver visually?
You can do that, up close, with reasonable accuracy. There's a distinct pattern of jumpiness in how people's eyes move. You can usually spot it in conversational settings, and doing the move light left and right across field of vision test is pretty solid.
There's a slight confounding factor; tired people have a different type of jumpiness to the eye motion. But if you know what you're looking for they're clearly distinct behavior.
The sun was down too far on the horizon to generate any useful power (or absorb heat directly) during winter.
Mars has axial tilt of 25 degrees; Earth's is 23.5 degrees or so. So there's an equivalent Arctic Circle zone where the sun's below the horizon during the worst of winter. Earth's Arctic Circle is at 66 degrees north; with slightly greater tilt, Mars' Arctic Circle will be even lower. The landing site was around 67 degrees north on Mars.
The sun would have been down long enough that no reasonable amount of batteries could have kept it warm overwinter. A RTG could - as discussed - or little RHU units (Radioactive Heater Unit - it's like a mini-RTG heat source module, with the protection but no power generation units, just designed to keep parts warm). But there was a decision made that the lander was unlikely to survive with all the overwinter issues, so they didn't bother.
One of my schoolmates released some software with a custom license, which was basically the old-form original UC Berkeley BSD license with a restriction prohibiting any use by persons in "Country Code F", defined as (paraphrasing from memory):
"France, Belgium, Quebec, Sengal, Ghana, Did we mention France?"
I think it was bad experiences with language classes in high school, but I'm not sure.
Large raindrops have caused fatal damage levels to some ICBM reentry vehicles in past testing.
This particular mechanism - where an interceptor hits the rocket body but doesn't kill the RV - only applies to missiles with their RVs attached. ICBMs separate RVs of necessity; either a MIRV bus or the single warhead comes off the upper stage soon after the burn is done. Once they're separated the warhead is targetable by itself, and they've been hit successfully with high reliability.
If you hit the missile during ascent, and don't disrupt the warhead, it will fall far short of the target and be militarily useless.
Shorter range and intermediate range missiles sometimes keep the RV attached. An intercept on one of those, after burnout, in which the interceptor strikes the empty stage may or may not disrupt the warhead. If the warhead is not intended to reenter by itself, it may not be aerodynamically stable without the rest of the vehicle body attached, so it might spin out of control and break up on reentry. Or it might keep going pointed nose first and impact Ok, slightly further downrange as there's less drag from the stage.
If you hit those shorter range missiles during ascent they fail anyways.
If you look at actual SRBM and IRBM systems, pretty much everyone more advanced than Scud variants uses separating warheads. So - this system might not give you 100% reliable kills on Scuds, with nuclear warheads.
Scuds are pretty common, but their warheads are also pretty small - the Iranian reentry vehicle designs for their probably Nuclear IRBMs (Sajil, etc) are too big to fit on top of Scuds. North Korea's warheads for their probably Nuclear IRBMs are too big for Scuds. All those RV/warhead systems separate.
A number of modern US weapons would fit within the envelope and dynamic characteristics required for a Scud warhead, but are advanced enough that someone would probably have to do a nuclear test of the warhead design to make sure it worked.
Summary: Postol is right, for a narrow slice of the threat envelope, which is unlikely to pose a nuclear threat anyways.
If someone who actually might threaten us develops a Scud compatible nuclear warhead, it would take 2 shots with a SM-3 (one to disrupt the missile body, one to kill the remaining warhead) instead of 1, separated by enough time that the warhead coming off the debris from the body was detectable on radar and IR sensors, so probably 5-10 seconds apart. Given normal engagement envelopes this is not a big deal.
I've done some quick and dirty followups. Drive arrays on a concrete floor are much faster than those in a normal steel or aluminum rack with more drive arrays.
This is real.
You can demonstrate it with one drive array, a rack, and a solid floor. Put other equipment in the rack. Put the array in, test it. Stop testing, put it on the floor, start testing again. Put it back in the rack, test it again. The floor, test it again.
There are some time delays involved as the drives adapt to higher and lower vibration environment - the mechanism here is the drive seems to be adopting a strategy of more error correction on reads and writes when it thinks the head's vibrating more. It will ramp that up and down as it figures out that the environment has changed.
..at SustainIT 2010, Turner had a really good analysis. Still some gaps - figuring out what frequencies hurt the most, and how individual drive types respond to what, is necessary followon. How various vendors' drive units transfer vibration from the rack into the unit, into the drive carrier, into the drive. That sort of thing. Now that the phenomena is identified, a lot more to do on it.
At the least, keep performance sensitive drives away from large sources of environmental vibration, such as your AC unit and so forth.
Lots of people did dumb things here, in my humble opinon, including but not limited to:
The San Francisco CIO and IT Security Officer for not ensuring they had the centralized security password management their policy required, and for not ensuring they actually had all the system passwords they were supposed to;
His (direct) boss, not getting his system passwords under the central management appropriately to start with;
His boss, asking him on an open phone line with a conference room full of other people for the passwords, which should probably have gotten his boss fired or sanctioned by the SF IT Security director;
Childs, for inventing several fictional excuses rather then reading the IT Security policy when asked about it;
His boss, for starting a legal confrontation over it rather than defusing the situation somehow;
Childs, for failing to disclose the passwords to the IT Security director, who led the team who unambiguously had central systems password management/tracking system data authority, whether they had a database for them or not;
Several legal people, for reasons others have articulated.
One of these was chargeably criminal, though it probably should have been handled in a less confrontational manner than that. The rest were just dumb.
You can't disclose *your* passwords yes. But router passwords aren't personal passwords; they're system account passwords.
Which the policy clearly required be held by the apparently nonexistent common system passwords database - but did in any case have to be available to others in the infrastructure (the bus rule).
The correct answer was "The security policy says that I can't disclose the system password on an open conference call, sir. I will turn the password over to the IT office security officer or to you in private immediately, but not here, please."
No, the whole "contractually required to only disclose to the Mayor" was a complete fabrication.
He stated that the Mayor was the person he'd give them to, after he was arrested, and he did. But that's not in the City IT Security policy nor in his contract.
The City IT Security Policy requires that system passwords be in a (then apparently nonexistent) encrypted central system passwords management database, managed by the City IT security office, for retrieval in case someone dies or is fired. The City failed to build that, but at the very least he should have been willing to tell the City IT security manager what it was, and arguably his manager, even if his manager was not competent.
To some extent this is true - SpaceX has spent about 2x what they thought they would to a given point in their development program, though they're still liquid and moving forwards at good pace. A number of startups have spent tens of millions of dollars and not flown.
However - Two startup companies and an independent team combined spent 1/10 of the cost of the DOD / NASA DC-X / DC-XA program to fly in the X-Prize Lunar Lander cup competition, which was a comparable technical challenge and vehicle performance specification. And DC-X was widely hailed for having come in at 1/5 of the price that competitors (Of McDonnell Douglas, who actually built and flew it for DOD) said it would cost.
There were teams at large companies that were asked to quote an equivalent vehicle to Burt Rutan / Scaled Composites' SpaceShip One, and came up with numbers 8-15 times larger than it took Burt to build and fly and win the main X-prize.
Perhaps the large companies don't know how easy it can be. Evidence is that some startups are succeeding reliably, and by comparison extremely cheaply, albeit slowly. There's a lesson there, too.
If you look at the website, the multiple counties model policy document is from 2003, and the enacting executive order for San Francisco making that the ruling policy was from 2007, so these were in effect at the time Childs was employed (at least by the end) and at the time he was terminated and then arrested.
These are the applicable, contemporary policies he was operating under, apparently with little or no modification still in effect now.
Except that the policy of SanFran (quoted in a response to previous article on Slashdot, so I'm going to be lazy and let you do your own damn research for once) SPECIFICALLY required that he not reveal the passwords to anyone but the mayor, and certainly not to someone on an open fucking conference call to which anyone else, especially the "spy girl" who he had turned in when he caught her rummaging through shit after hours, might have been party.
He delivered the passwords, AS PER WRITTEN SANFRAN POLICY, to the Mayor in a face-to-face meeting. That is what was required of him by SanFran code. The people who tried to get him to break that policy are the idiots who should lose their jobs and be on trial.
This is rapidly becoming myth rather than fact-based.
4. Policy 4.1. General
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis.
All production system-level passwords must be part of the security administered global password management database.
(removed)
B. Password Protection Standards Do not use the same password for County accounts as for other non-County access (e.g., personal Internet Service Provider (ISP) account, option trading, benefits, etc.). Where possible, don’t use the same password for various County access needs. For example, select one password for the network systems and a separate password for application systems. Also, select a separate password to be used for a NT account and an AS400 or UNIX account. Do not share County passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential County information. Here is a list of things to avoid:
Giving your password over the phone to ANYONE.
Sending a password in an e-mail message.
Telling your boss your password.
Talking about a password in front of others.
Hinting at the format of a password (e.g., “my family name”).
Writing in your password on questionnaires or security forms.
Sharing your password with family members.
Telling your co-workers your passwordwhile on vacation. If someone demands a password, refer him or her to this document or have him or her call someone in Information Security. Never use the “Remember Password” feature of applications (e.g., Eudora, Outlook, Netscape Messenger). If you must your passwords down, store them is a secure place and never anywhere in your office. Passwords stored in a file on ANY computer system (including Palm Pilots or similar devices) can be compromised if encryption isn’t used to secure them. Change passwords at least once every three months (except system-level passwords, which must be changed monthly). Changing them more often is better. If you suspect that your account or password is compromised, report the incident per the Incident Response Policy and change all passwords. Password strength checking may be performed on a periodic or random basis by departmental or county IT or its delegates. Any passwords found out during one of these scans will require the user to change it.
Though the "Do not tell anyone your password" sect
I can understand Childs' frustration with some managers - but IT folks don't set corporate or city policy. Sometimes we are asked to write a draft policy for security - or participate in organizational efforts to draft one - but we don't get to arbitrarily impose one.
In particular, sitting on all access and passwords and refusing to share or divulge them is effectively the last refuge of someone who's on a power trip, or about to get let go and is trying to delay that.
They aren't your systems. The people who paid for them - the city, and its elected and hired management, the company, the shareholders of the company and their hired execs and management - they own the systems. When IT starts to assert ownership, it's wrong.
We need to assert responsibility - and that includes not giving out the passwords and access controls inappropriately. But appropriate sharing of that information is required. Any of us could have a heart attack or be hit by a bus tomorrow. If you haven't thought through the impact of the "Bus Test" on each of your coworkers, and yourself, then you're not doing your job. Your boss absolutely must be able to tell your emergency replacement how to do their job. If they can't do their job, or take an inordinate amount of time hacking in to everything to get access that you didn't share, you did your job wrong.
I don't think he should have been charged as he was. But he did wrong. He probably deserved to be suspended or fired for doing it as persistently as he did, even if his bosses were bozos (and I have no personal knowledge or opinion on that point). If he thought his bosses were doing wrong, he should have escalated within his management chain, ultimately to the mayor. But just saying no, until arrested, isn't responsible or reasonable.
Unless security policy already says "don't tell managers this" and management has already signed off on that - and there's another techie, or a envelope in the safe with the info, in case of Bus - when managers in the management chain insist on it, you give it up, or immediately escalate to more senior management. Period. Even if you think it's going to be a disaster. You are not the last and final judge of who gets it and who doesn't, and if you think you are, your career is likely not going to last that long.
Slashdot Mirror
I have an excellent idea of how multistage clinical trials work, and why. I have family members who were strongly affected by well known drugs that failed to be safe in general practice.
The specific technique in question has worked in all the mammals it's been tried in. That doesn't mean you can just skip ahead to doing it in humans on large scale without trials, no. But it was having problems getting approval to get the trials started, in no small part because of the insane federal government stem cell regulations from the previous administration. T his was particularly offensive because it entirely uses the patient's own stem cells (you liposuction some body fat to extract the stem cells from), and had nothing to do with embryonic stem cells.
I wouldn't be complaining if it had been winding its way through approval. The FDA had threatened vets who were doing this and who had openly discussed doing a less rigorous Phase 0 study on themselves as human test subjects. Admittedly that's not nearly as rigorous as a fully rigorous Phase 0, but it will at least give you some bounds on serious side effects.
As an aside on the normal pharmaceutical testing protocol, there are cases where severe or uniformly fatal diseases exist and people will die anyways. It took a long time to get the FDA to approve shorter protocols and widening Phase III trials to allow a chance of saving some dying patients with the study phase drugs; some of the AIDS drugs were the catalytic agent for that change. There are some cases where even a worst case - the drug kills everyone who takes it - would not be necessarily a societal or individual moral disaster compared to the underlying diseases.
You should have enough risk mitigation from Phase 0 and Phase 1 that a wider Phase 2 in many acute or terminal conditions is entirely called for. A number of medical ethicists have commented that liability risks (someone will sue, even if their loved one would have died within a month anyways) and FDA inertia are holding back a number of treatments that fall into these categories.
Just to be clear - The joint repair stem cells aren't relevant to that question - joint injuries and damage are a quality of life not survival disease.
The one place where stem cell treatment seems to have good scientific basis - joint repair, where stem cells are centrifuged out of fat cells and injected into the joint - is stuck in FDA human trials hell in the US.
It works great in a number of animals, and is available for dogs and horses (at least) via vets.
People? Nope. Go fish.
There's no reason for him to go into a high security prison. It costs more for the feds to hold high security prisoners, he's never been accused of violence, he seems to be a low risk to guards or other prisoners. Him being a foreign national doesn't really play into it.
His supporters in England are using the "He could theoretically be sentenced to high-security!" as a scare tactic, along with a number of others. Sure, he could be - they could send him to SuperMax in Colorado. But they won't, because it's expensive and there's nothing he's done that justifies anything more than minimum security.
If he's convicted he gets to go to minimum security federal jail for probably 2-4 years. How is that savage punishment?
Aspergers is neither a cause of computer hacking nor an excuse for it. "Oh, a trial or jail will traumatize him" isn't a valid reason to not put someone on trial either in the US or in England.
This guy was misguided rather than intentionally malicious, but he misguided himself into a bunch of federal felonies. Aspergers doesn't change your ability to understand legal vs illegal acts.
The instability was due to the dynamics of the drogue parachute, which was intended to ensure that the vehicle didn't turn upside down due to air drag before the engine lit. It did that but the length of the parachute harness ended up being such that the vehicle moved unsteadily at that descent rate.
That's a minor problem and easy to fix, with a different length harness or other aerodynamics.
With a vehicle which was aerodynamically stable going down base first, it wouldn't be a problem either. That particular test craft (and Masten's similar one) will probably turn and fall nose-first if they fall any significant distance. These are low altitude test rockets, not the final high speed high altitude models, so some problems appear with these models that will be engineered out of the final models.
You fix those short-term problems with the most cheap and reliable band-aid you can, since you're planning on a different airframe as the long term fix. The parachute was the band-aid. Not a perfect band-aid, but an acceptable one.
Yes; about 2 years in orbit is the estimate.
This test capsule had no functional heatshield (apparently), so it will burn up high in the atmosphere when it comes down.
You can do that, up close, with reasonable accuracy. There's a distinct pattern of jumpiness in how people's eyes move. You can usually spot it in conversational settings, and doing the move light left and right across field of vision test is pretty solid.
There's a slight confounding factor; tired people have a different type of jumpiness to the eye motion. But if you know what you're looking for they're clearly distinct behavior.
Obviously, you build a new power entrance, transformers set, etc.
Which is cheap, compared to the generators and UPSes to switch over to in case the mains go poof.
The AC system and chillers will cost more than the mains feed, less than the UPS / generators.
Raised floor isn't cheap, but it's cheap enough.
Once you've done a bunch of datacenters with multiple thousand systems per building, it's just a question of statistics.
The sun was down too far on the horizon to generate any useful power (or absorb heat directly) during winter.
Mars has axial tilt of 25 degrees; Earth's is 23.5 degrees or so. So there's an equivalent Arctic Circle zone where the sun's below the horizon during the worst of winter. Earth's Arctic Circle is at 66 degrees north; with slightly greater tilt, Mars' Arctic Circle will be even lower. The landing site was around 67 degrees north on Mars.
The sun would have been down long enough that no reasonable amount of batteries could have kept it warm overwinter. A RTG could - as discussed - or little RHU units (Radioactive Heater Unit - it's like a mini-RTG heat source module, with the protection but no power generation units, just designed to keep parts warm). But there was a decision made that the lander was unlikely to survive with all the overwinter issues, so they didn't bother.
One of my schoolmates released some software with a custom license, which was basically the old-form original UC Berkeley BSD license with a restriction prohibiting any use by persons in "Country Code F", defined as (paraphrasing from memory):
"France, Belgium, Quebec, Sengal, Ghana, Did we mention France?"
I think it was bad experiences with language classes in high school, but I'm not sure.
Large raindrops have caused fatal damage levels to some ICBM reentry vehicles in past testing.
This particular mechanism - where an interceptor hits the rocket body but doesn't kill the RV - only applies to missiles with their RVs attached. ICBMs separate RVs of necessity; either a MIRV bus or the single warhead comes off the upper stage soon after the burn is done. Once they're separated the warhead is targetable by itself, and they've been hit successfully with high reliability.
If you hit the missile during ascent, and don't disrupt the warhead, it will fall far short of the target and be militarily useless.
Shorter range and intermediate range missiles sometimes keep the RV attached. An intercept on one of those, after burnout, in which the interceptor strikes the empty stage may or may not disrupt the warhead. If the warhead is not intended to reenter by itself, it may not be aerodynamically stable without the rest of the vehicle body attached, so it might spin out of control and break up on reentry. Or it might keep going pointed nose first and impact Ok, slightly further downrange as there's less drag from the stage.
If you hit those shorter range missiles during ascent they fail anyways.
If you look at actual SRBM and IRBM systems, pretty much everyone more advanced than Scud variants uses separating warheads. So - this system might not give you 100% reliable kills on Scuds, with nuclear warheads.
Scuds are pretty common, but their warheads are also pretty small - the Iranian reentry vehicle designs for their probably Nuclear IRBMs (Sajil, etc) are too big to fit on top of Scuds. North Korea's warheads for their probably Nuclear IRBMs are too big for Scuds. All those RV/warhead systems separate.
A number of modern US weapons would fit within the envelope and dynamic characteristics required for a Scud warhead, but are advanced enough that someone would probably have to do a nuclear test of the warhead design to make sure it worked.
Summary: Postol is right, for a narrow slice of the threat envelope, which is unlikely to pose a nuclear threat anyways.
If someone who actually might threaten us develops a Scud compatible nuclear warhead, it would take 2 shots with a SM-3 (one to disrupt the missile body, one to kill the remaining warhead) instead of 1, separated by enough time that the warhead coming off the debris from the body was detectable on radar and IR sensors, so probably 5-10 seconds apart. Given normal engagement envelopes this is not a big deal.
I've done some quick and dirty followups. Drive arrays on a concrete floor are much faster than those in a normal steel or aluminum rack with more drive arrays.
This is real.
You can demonstrate it with one drive array, a rack, and a solid floor. Put other equipment in the rack. Put the array in, test it. Stop testing, put it on the floor, start testing again. Put it back in the rack, test it again. The floor, test it again.
There are some time delays involved as the drives adapt to higher and lower vibration environment - the mechanism here is the drive seems to be adopting a strategy of more error correction on reads and writes when it thinks the head's vibrating more. It will ramp that up and down as it figures out that the environment has changed.
..at SustainIT 2010, Turner had a really good analysis. Still some gaps - figuring out what frequencies hurt the most, and how individual drive types respond to what, is necessary followon. How various vendors' drive units transfer vibration from the rack into the unit, into the drive carrier, into the drive. That sort of thing. Now that the phenomena is identified, a lot more to do on it.
At the least, keep performance sensitive drives away from large sources of environmental vibration, such as your AC unit and so forth.
Lots of people did dumb things here, in my humble opinon, including but not limited to:
The San Francisco CIO and IT Security Officer for not ensuring they had the centralized security password management their policy required, and for not ensuring they actually had all the system passwords they were supposed to;
His (direct) boss, not getting his system passwords under the central management appropriately to start with;
His boss, asking him on an open phone line with a conference room full of other people for the passwords, which should probably have gotten his boss fired or sanctioned by the SF IT Security director;
Childs, for inventing several fictional excuses rather then reading the IT Security policy when asked about it;
His boss, for starting a legal confrontation over it rather than defusing the situation somehow;
Childs, for failing to disclose the passwords to the IT Security director, who led the team who unambiguously had central systems password management/tracking system data authority, whether they had a database for them or not;
Several legal people, for reasons others have articulated.
One of these was chargeably criminal, though it probably should have been handled in a less confrontational manner than that. The rest were just dumb.
You can't disclose *your* passwords yes. But router passwords aren't personal passwords; they're system account passwords.
Which the policy clearly required be held by the apparently nonexistent common system passwords database - but did in any case have to be available to others in the infrastructure (the bus rule).
The correct answer was "The security policy says that I can't disclose the system password on an open conference call, sir. I will turn the password over to the IT office security officer or to you in private immediately, but not here, please."
Not "no".
Additionally, he was obligated by contract not to disclose the passwords, and he was meeting that obligation by not releasing them.
No, he was not. Stop repeating the myth.
No, the whole "contractually required to only disclose to the Mayor" was a complete fabrication.
He stated that the Mayor was the person he'd give them to, after he was arrested, and he did. But that's not in the City IT Security policy nor in his contract.
The City IT Security Policy requires that system passwords be in a (then apparently nonexistent) encrypted central system passwords management database, managed by the City IT security office, for retrieval in case someone dies or is fired. The City failed to build that, but at the very least he should have been willing to tell the City IT security manager what it was, and arguably his manager, even if his manager was not competent.
Before I write a possibly longer post, are you really, REALLY saying that "Democrats don't infringe copyright" ?
They have not infringed artists copyrights for use in political ads any time in recent memory.
BELIEVE, anyone?
To some extent this is true - SpaceX has spent about 2x what they thought they would to a given point in their development program, though they're still liquid and moving forwards at good pace. A number of startups have spent tens of millions of dollars and not flown.
However - Two startup companies and an independent team combined spent 1/10 of the cost of the DOD / NASA DC-X / DC-XA program to fly in the X-Prize Lunar Lander cup competition, which was a comparable technical challenge and vehicle performance specification. And DC-X was widely hailed for having come in at 1/5 of the price that competitors (Of McDonnell Douglas, who actually built and flew it for DOD) said it would cost.
There were teams at large companies that were asked to quote an equivalent vehicle to Burt Rutan / Scaled Composites' SpaceShip One, and came up with numbers 8-15 times larger than it took Burt to build and fly and win the main X-prize.
Perhaps the large companies don't know how easy it can be. Evidence is that some startups are succeeding reliably, and by comparison extremely cheaply, albeit slowly. There's a lesson there, too.
If you read the original science paper ( http://www.lpi.usra.edu/meetings/lpsc2010/pdf/1601.pdf ) they looked at topology and geology. The ring is not just a surface feature, it's in the deeper geography.
It had been identified in 2006 by visual circularity only by another researcher ( http://impacts.rajmon.cz/data/Impact_database_2009_2.xls or http://impacts.rajmon.cz/data/Impact_database_2009_2.kmz ). The Italian researchers did some of the geology to support that.
More geology is needed, you want to find impact breccia and shatter cones and so forth. But there's more there than "Dude, it's round!".
If you look at the website, the multiple counties model policy document is from 2003, and the enacting executive order for San Francisco making that the ruling policy was from 2007, so these were in effect at the time Childs was employed (at least by the end) and at the time he was terminated and then arrested.
These are the applicable, contemporary policies he was operating under, apparently with little or no modification still in effect now.
I've never found any press source with a contract quote that said that, or any filing in court.
If you have the source, post a reference, or at least the text of the contract.
As I said above - coverage of this case is largely myth-based. Bring actual facts - they work better.
This is rapidly becoming myth rather than fact-based.
The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853
The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251
Which, basically, says "follow this inter-county planning document":
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf
The password policy in CCISDA states:
(pp 32 of the document)
Though the "Do not tell anyone your password" sect
I can understand Childs' frustration with some managers - but IT folks don't set corporate or city policy. Sometimes we are asked to write a draft policy for security - or participate in organizational efforts to draft one - but we don't get to arbitrarily impose one.
In particular, sitting on all access and passwords and refusing to share or divulge them is effectively the last refuge of someone who's on a power trip, or about to get let go and is trying to delay that.
They aren't your systems. The people who paid for them - the city, and its elected and hired management, the company, the shareholders of the company and their hired execs and management - they own the systems. When IT starts to assert ownership, it's wrong.
We need to assert responsibility - and that includes not giving out the passwords and access controls inappropriately. But appropriate sharing of that information is required. Any of us could have a heart attack or be hit by a bus tomorrow. If you haven't thought through the impact of the "Bus Test" on each of your coworkers, and yourself, then you're not doing your job. Your boss absolutely must be able to tell your emergency replacement how to do their job. If they can't do their job, or take an inordinate amount of time hacking in to everything to get access that you didn't share, you did your job wrong.
I don't think he should have been charged as he was. But he did wrong. He probably deserved to be suspended or fired for doing it as persistently as he did, even if his bosses were bozos (and I have no personal knowledge or opinion on that point). If he thought his bosses were doing wrong, he should have escalated within his management chain, ultimately to the mayor. But just saying no, until arrested, isn't responsible or reasonable.
Unless security policy already says "don't tell managers this" and management has already signed off on that - and there's another techie, or a envelope in the safe with the info, in case of Bus - when managers in the management chain insist on it, you give it up, or immediately escalate to more senior management. Period. Even if you think it's going to be a disaster. You are not the last and final judge of who gets it and who doesn't, and if you think you are, your career is likely not going to last that long.
xcalc -rpn on a linux smartphone?
I still use my 23+ year old HP-15C at home, though.