The Star Office version was *way* worse than what's there now. I'm glad they've pared it down this much, because the alternate-universe approach was just bonkers.
14 posts • joined 9 Jan 2015
I love the idea, but this is far harder than the FSF seems to think. I was one of the many, many people at Sun who were involved in the work required to turn Solaris into OpenSolaris. It was a monumental amount of work involving an army of engineers and lawyers. We had to establish the lineage of every source file and every contribution to it. Many things were purchased from third parties (e.g., the Mentat TCP/IP STREAMS code) long, long ago. Some were patched with contributions by other vendors. The documentation of these agreements was buried in offices all over the world, and known to people who'd either left the company or had died. And then there were patents to contend with, both Sun's and others.
We had to establish rights akin to ownership for everything such that we could then re-license (or sub-license) it for use by others. It was extraordinarily hard work.
If you don't care about being sued or enticing others into being sued, I suppose you can just dump it all on github and walk away as they seem to be suggesting. But in the world as it is today, that's just not going to fly. It's bonkers.
Based on what I saw, I think it'd be hard to estimate the effort required, but 30 man-years and USD$6m or so wouldn't be out of line. It may even be an order of magnitude or more than that, depending on just how much swill they've accumulated over the years and how well they've kept the records of it all.
They don't get to determine whether the gauge is an issue on their own -- except, perhaps, in a career-limiting, "sorry, I won't fly this thing."
Instead, it's determined in advance by the manufacturer's MMEL and the operator and local agency who figures out the MEL. If something's on that list, then you're good to go as long as you follow whatever rules the list specifies.
Just about all of these incidents and accidents reveal interesting things about the inter-related parts of the system, rather than just a simple "this guy blew it." It's often described in the US as getting all the holes in the Swiss cheese to line up just right so that an accident can occur. (I know that folks elsewhere have different cheese names. :->)
When I worked at Sun Microsystems, there were four "James Carlsons." Surprisingly, only one of them was me. I regularly received messages, sometimes highly privileged, that were misdirected to me.
One of the other "James Carlsons" was apparently a Director of Sales. A lot of his direct reports would send me their requests for vacation time. For a while, I put up with sending back a message letting them know that they should correct their request, because I couldn't do what they wanted. Eventually, I gave up and started rejecting them. One of them actually went to the trouble of calling me in a state of profound rage, demanding to know why I'd denied the vacation request. My answer was simple: I'm not your boss.
Treating the promotion of an RFC to "Standard" status as a starting point is a bit of a misunderstanding of the process. (See RFC 2026 for details.) (I sort of hope it was intended as an inside joke, but if not ...)
Standards-track RFCs start off life as Internet Drafts. As drafts are written and published, most vendors are in the process of producing interoperable implementations. Actual products are sold based on the drafts. Once rough consensus exists, it goes to Proposed Standard and is published for the first time as an RFC. If you don't already have an implementation in the field by this point, you're really a bit late to the game.
For many protocols, the story peters out there. Proposed Standard is awfully good. You don't have to have multiple interoperable implementations and active deployment underway to get there, but very often you do, and it's often used as an argument in favor of approval when the IESG is evaluating the request to publish. Most of the developers start drifting away to newer and better things at this point. If there are enough die-hards left to do the work of cataloging the implementation status, you might get promoted to Draft Standard.
After a very long time, a few protocols end up being promoted one last time as full Internet Standard status. But many of the things we rely on every day don't make it that far, because it's mostly an effort of paperwork by then, and not a protocol development exercise. It's a lot like getting a "lifetime achievement award."
So, yes, the July 2017 change is important for the protocol, but it really means nothing for the mature and robust implementations that have been in the field for 20+ years now.
Biting the hand that feeds IT © 1998–2020