It is possible that the spacecraft is going through layers of falesafes, until it finally just points its solar panels at the Sun, points its radio antenna at Earth, and cries for help. Remember the mission to Eros: http://klabs.org/richcontent/Reports/Failure_Reports/NEAR_Rendezvous_Burn.pdf
Likewise I say "true GB" for 1024-based and "salesman's GB" for 1000-based. Because the 1024-based units ARE the true units, and the 1000-based units WERE created just to make hard drives look bigger than they actually were.
Your second sentence turns out not to be correct. The decimal prefixes were long-established by the time binary computers were invented. I use GiB for binary and GB for decimal. If Microsoft Windows did the same, confusion would be reduced.
If the computer industry can't adapt to counting the way of the rest of the world does, that's our problem. We should be pointing at whoever originally decided that they should usurp the already established term Kilo to mean 1024 and slapping them upside the head. Anything less is pure arrogance on our part.
I don't know who originally decided to mis-use "kilo" to mean 1024, but the mistake was made in the late 1950s or early 1960s. I first heard that the PDP-1 was a "4K" machine in 1963, and the terminology was already well-established. It might have been done by several people independently.
The difference between 1000 and 1024 is only 2.4%, and the Ki prefix didn't exist yet, so perhaps the misuse is forgivable. However, there is a slippery slope: once you are comfortable with Kilo as 1024, it is easier to successively misuse Mega as 1048576 (4.9%), Giga as 1073741024 (7.4%), Tera as 1099511627776 (10%) and Peta as 1125899906842620 (12.6%).
The obvious solution is for all operating systems, even Microsoft Windows, to display hard drive sizes in decimal, and RAM sizes in binary. When displaying RAM sizes they should use the binary prefixes.
If you are interested in early software, consider FLINT. FLINT was a floating-point package for the IAS computer, which was designed by John von Neumann in the early 1950s. FLINT was intended to be a high-level language which could be implemented on other computers.
FLINT, "which, as far as its user is concerned, transforms our machine into a slower, less sophisticated instrument for which coding is much simpler," insulated the end user from having to communicate directly with the machine. "The planned general external language should be influenced as little as possible by the peculiarities of the machine; in other words, it should be as close as possible to the thinking of the programmer" it was explained. The user "need not know machine language at all, even, and in particular, while debugging his program."
The above paragraph is from Turing's Cathedral: the origins of the digital universe by George Dyson, 2012, ISBN 987-1-4000-7599-7, page 318. The quotations are from "Institute for Advanced Study Electronic Computer Project Monthly Progress Report, January 1957", page 3. See also http://paw.princeton.edu/issues/2012/04/04/pages/1670/index.xml?page=7&.
I'm certain Star Trek was one of the top reasons many of the engineers at NASA became interested in engineering in the first place.
That may be so, but the previous generation of NASA engineers was inspired by the Walt Disney program Man in Space, which featured Wernher von Braun.
Given how frequently (and often painfully, toward the end) companies seem to founder in the face of structural changes that they can't do much about (short of essentially re-founding as something else, just carrying over the campus and the capital), I have to wonder if there has been any work done outside of the barbaric corporate raider sector on building companies with clean exit strategies...
After all, there isn't any reason why a company needs to struggle to perpetuate its existence forever (any more than a company would struggle to perpetuate the existence of a given product line forever). Sure, the process that companies who do fight and then die go through is pretty grim; but that is, at least in part, because they keep struggling even after the situation is hopeless, and just bleed and bleed and bleed.
Is there a process where you just quit before you are behind, wind down neatly, rather than the corporate equivalent of spending a few years stuck full of tubes and unresponsive in the ICU?
It is possible for a company to cease operations without lots of pain. All it requires is a management willing to face facts. Ken Olsen, founder of Digital Equipment Corporation, used to tell the story of a corner barbershop that knew its finances very well. When their landlord increased the lease on their parking lot, they immediately closed: they knew that with the increased cost they could not survive.
Some years ago, I owned and operated a store which sold and serviced the Commodore Amiga. When Commodore folded, I had two choices: convert to an IBM PC store, or close. There were already several IBM PC stores in town, better established than I would have been, so I decided to close.
I decided that December 31 would be my last day. I told my technician to go home, but I would continue his health benefits through the end of the year. I paid my rent and hired kids off the street to help me clean out the store. Most of the stuff in the store was trashed, but I took a few items home. I kept the store name for my personal consulting business.
No pain, no tears, just the orderly end of a retail business that had lost its manufacturer.
The two things I ask about are a design document and an automated QA system.
Don Knuth's Literate Programming is the very best way to write a design document, but even much less than that is better than nothing. The worst case is having nothing but uncommented code. I once had a programmer tell me that he didn't need to comment his code: the names of the variables provided enough information. He was coding in Macro-10, a language that limited variable names to six characters.
The automated QA system is crucial for maintenance. You need a test for every feature described in the documentation, plus one for every bug fixed, to make sure it doesn't come back. The QA system must be automated or management will insist you skip running it because a bug fix has to ship "right now", and you don't have two days to run the manual tests. Having a QA system that can be run after each build is so important that it should be the first thing you write when taking over legacy code. If you aren't allowed to write it because fixing bugs or adding features is more important, pass on the project.
When I started programming I didn't have to deal with legacy code, even though I was at a large university. That was because when I started programming there was no legacy code: we wrote everything ourselves. A friend of mine wrote the original recursive binary to decimal conversion subroutine for the DEC PDP-1, and was astonished when it worked the first time. The world has moved on, however, and the situation I was in no longer exists.
Nevada or New Mexico or Oregon are alllll calling...
Don't forget New Hampshire! We have high property taxes, but no sales tax (other than stuff tourists buy) and no tax on wages.
A couple of weeks ago I was talking to a truck driver from Montreal. He comes here every few weeks with his wife and daughter to shop. He said the prices are lower, he can take back everything he buys duty-free, he can get the famous brands of stuff, and the quality of the cloth in the clothing is better. Anybody who will drive an 18-wheeler from Montreal to southern New Hampshire to shop has got to be motivated!
There's not a single car sold in America that gets 50+ mpg....
I drive a 2000 Honda Insight, which is rated by the EPA at 53 miles per gallon. You can't buy them new, but they are available on the used market.
.... You already have the people that could do the job, but I suspect there's too much pork, and possibly outright corruption, bound up in all that money that goes into local voting systems, to do it without a lot of resistance even if it was done at a state instead of federal level.
It's not so much pork or corruption, but a desire for local control, based on a distrust of higher levels of government. Where I live, we vote for the Town and School District budgets every year. Our property taxes are based on those budgets, so they are very important to every property owner. We have election procedures which are efficient and transparent. We don't want the State (or, worse, the Federal Government) telling us how to run our elections.
When I first moved into my town, ballots were placed in boxes. When the polls closed, volunteers counted in pairs: one counting and the other verifying. We switched roles occasionally to stay alert. When the lally was finished the ballots went back into the box in case the totals were close and someone called for a recount. Today, we use a Scantron for the preliminary count, with the paper ballots retained inside the machine. The results are available on the Town web site the day after the election.
If we were to convert to an electronic system, perhaps the results could be available an hour after the polls close. That would please the national media, but we are afraid of losing the transparency that makes our system work. I have seen the loser shake the hand of the winner after the preliminary count was complete, and wish him well. Without confidence in the accuracy of the count, close races might lead to endless bickering.
I introduced my girlfriend to Star Trek by buying a color TV small enough to fit in my studio apartment, and inviting her over once a week to watch the next episode. We watched the original broadcast of what is now called the “original series”. She liked so much she married me. We raised our two kids to love Star Trek and other types of science fiction and fantasy.
At our son's wedding a few years ago, I ended the traditional father-of-the-groom speech with “live long and prosper” and the accompanying hand gesture. His friends were amused, but knew exactly what I meant.
As a long-time geek, I carry lots of pens in my shirt pocket. I decided to turn them into business cards.
I had a bunch of nice-looking personalized pens made, with my e-mail address inscribed on them. If someone asks me for my e-mail address, I hand them a pen. I then have to explain that the pen is not to write down my e-mail address, but it has my e-mail address alreay on it, and they can keep the pen. I have handed out more than 100 pens in the last couple of years. People tend to keep them longer than paper business cards because they have utility: you can write with them.
My e-mail address includes my name, and if you search the Web for my e-mail address you get my web site (hosted by the workstation under my desk at home) and my résumé, which includes a picture of me, my telephone number, and my mailing address. That's better than a business card.
Scale is still a problem
Chances are many of the source systems belong to customers, suppliers and other third parties. Coordinating the testing would be complicated. Tracking the configuration would be even more complicated.
It'll be a lot cheaper for him to take a couple of minutes of outage every few years.
It's not quite that bad. You need a test version of your system anyway, so you can make changes without risking bringing down the production system. You hack NTP for the test system as a whole and observe what breaks. You fix problems and re-test, just as you do for any modification, until the test sytem functions correctly. You then copy those changes to the production system.
When a new version of an external component changes, you verify that it works using your test system. You would do this even if you were not worried about leap seconds. However, now that you have the hacked version of NTP available, you also test for leap seconds handling. If you find a new leap seconds problem you work around ir and/or report it to your vendor, just as you do with any new bug that you find.
Yes, it will probably be cheaper to take a couple of minutes of outage every few years. However, you now have an advantage over your competition that can be exploited by your marketing department. If a customer is seriously interested in maximizing his up time, he will have a "leap seconds" box to check off on his RFP. If you are the only one who can check it off, you can charge higher rates.
I think the original poster's problems are on a scale much larger than 'fix your software'. He/she is getting data from multiple, disparate systems, and probably does not have any way to tell if a given source supports leap seconds or not. Without that info, there really isn't a fix available.
By hacking NTP to introduce frequent leap seconds, he can discover how each source handles leap seconds, and develop workarounds for each source he cannot fix. For example, if a particular source sits at 23:59:59 for two seconds, he might recognize that and write a filter or post-processor to convert the second second to 23:59:60 in messages received from that source.
...That will, of course, be charged to our SLA downtime, which will affect everyone's performance reviews at the end of the year. All this for a single goddamn second.
If you are concerned about your SLA, fix your software so it handles leap seconds correctly. You can test your fixes by hacking NTP to insert a positive or negative leap second at the end of every minute. When you get it working, you will have a competitive advantage over everyone who has to shut down.
2.4 statute miles of surgical tubing at Yale U. = 1 I.V.League
