Space Shuttle computer has 1MB of RAM
astroblog.cosmobc.com
astroblog.cosmobc.com
"They Write the Right Stuff"
The only difference is for most software projects it is acceptable to have "bugs" as customers will still pay for it, even if it's in a poor state of quality. But "bugs" in a 2,717 ft tower are unacceptable.
It comes down to, in general the cost of a bug in most software is relatively low compared to other engineering disciplines. Of course if the software is critical support systems for Astronauts that's a different story.
The point of engineering is to make a system that is resilient to a certain level of faults. That's why the tower doesn't collapse if there is a 0.1 mm crack in one of the bolts.
I was involved in a case with a turbine blade fracture. The user claimed that there must have been a flaw, and yes the crack must have started at a single atom sized crystal flaw in the meta. But the choice of alloy was such that the crack would have grown at a rate which means it was under the failure size for at least twice the inspection interval - where the customer missed it.
This doesn't mesh with my experience to be honest. I often come across code that contains nasty bugs but is still somehow working accidentally. And even more often, there are bugs that stop just one feature from working while the rest of a large system pretty much acts as if the bug didn't exist.
People have a tendency to overlook "bugs" in architecture because of the immutability of the medium. But once you start noticing that the HVAC is uneven on your floor, the hot water takes five minutes for ramp up in your office's break room and the conduit runs for networking are bizarre you start to understand that architects and builders run into design and implementation problems as well.
In fact they have their own word for patching. Renovations.
In my present house we cannot have the central air turned on in the downstairs toilet if we want heating to the smallest bedroom (the 'infant' room) upstairs. Similarly the basement air vent was so distant from the conduits that the main level essentially has a heated floor (hot air can be felt escaping through almost every gap in the basement ceiling except the air vent it's supposed to come out of. Similarly the plumbing is so unbalanced that the shower can essentially be turned off by a good configuration of tap turns and toilet flushes.
Architecture is a joke, and the 'engineers' who design them should really consider building a house themselves, because I've seen every crazy design from doors being hinged to trap people in the corner of a hallway (literally you'd have to step into the far corner to squeeze around the door to exit the bedroom), to lighting layouts that didn't illuminate the room, or switches completely impracticably placed.
You're entirely right, people overlook 'bugs' in architecture, although in my experience it's largely because of ignorance of what it being right is. How do you compare a poor plumbing design in your house? Do you run through your best friend's place screwing around with his sinks and toilets while he's in the shower?
It's easy to compare two software programs to find a less buggy option, however it's hard to compare two houses to find a less buggy option.
No, it's good economics. In commercial software development, after a certain point, the marginal benefit of fixing bugs divided by the marginal cost of doing so starts to exceed what the market will bear for consumer software. We literally get what we pay for when it comes to commercial software.
In fact, it's a bit of a shame we still haven't got how to make correct software, but it's no way impossible and should be getting cheaper by the day.
I think should is the important word here. It's not and we have nobody but ourselves to blame.
edit: woah, feature-fail == bug? Why'd it take them until 2007 to not have to reboot whenever they reached a new year? I'd call that a rather significant, costly bug, even if they don't, and it may very well be one of the longest-running in actively-developed software.
That pretty strongly implies that all known strange-behavior is not a bug. Also, all known bugs are not bugs, as they can be known and worked around.
If you had to shut down your computer during the year cross-over, would you consider it a bug? Or what if you couldn't go on your business trip because of the year cross-over.
And a bug in the spec is still a bug. Oversights in specifications are equivalent to oversights in programming.
A similar parallel in consumer computing is switchable graphics. The first models that supported this required a reboot to accomplish it. That wasn't a bug, just part of the plan. They have since gotten more advanced and allow switching without a restart.
Not a minor feature, methinks.
It's sort of the thinking that goes into Erlang programs—rather than, say, thinking out complex GC strategies, you just create little process-sized vessels which grow, overflow, are killed, and then are recreated by other processes. It's not a "bug" that an individual process has died any more than it's a bug when one of the cells in your body dies.
At the time I was struggling to comprehend how to construct a basic circuit, so I was wow'd (and still am).
They are all NAND gates, since they have better electrical characteristics and are Universal Gates (they can form AND/OR/NOT gates in some combination).
What is surprising is that they used NOR gates - while they are Universal Gates as well, their fabrication apparently leads to poorer electrical properties.
Electrical Positive Negative
function logic logic
L L | H 0 0 | 1 1 1 | 0
L H | H 0 1 | 1 1 0 | 0
H L | H 1 0 | 1 0 1 | 0
H H | L 1 1 | 0 0 0 | 1
NAND NORNone of this really mattered at the time; the Apollo used resistor-transistor logic (RTL), which in turn used bipolar junction transistors (BJTs) instead of the CMOS (C is for complementary, meaning NMOS and PMOS) used for most digital logic today. In RTL (there are analogous logic families using CMOS too), instead of having a pull-up network of transistors, there is a weak pull-up resistor that makes the output high by default, unless it is pulled down by a network of (usually NPN) BJTs. In the case of an RTL NOR gate, it is just a bunch of NPN BJTs in parallel for the pull-down network, so it's pretty efficient ( http://www.play-hookey.com/digital/experiments/rtl_nor4.html ).
Sorry for the longish post.
Thanks for the explanation.
http://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/a...
nand is more likely.
"In complicated logical expressions, normally written in terms of other logic functions such as AND, OR, and NOT, writing these in terms of NAND saves on cost, because implementing such circuits using NAND gate yields a more compact result than the alternatives."
http://en.wikipedia.org/wiki/NAND_gate
Also see sandGorgon's comment above: http://news.ycombinator.org/item?id=1226971
Really? Really?
The capsule’s failsafe mechanisms where triggered and the it fell back to the harsher ballistic reentry instead of the normal controlled one (nobody was harmed). It seems that a system which has been in use since 1979 somehow got confused by the sensory data. Some sort of odd bug, they have never been able to reproduce it.
Fallback to ballistic reentries also happened later with TMA-10 and TMA-11 – in those two cases a damaged cable and a pyro bolt malfunction (which nearly got the crew killed) were responsible respectively.
There's a fascinating (and very detailed) series of lectures on the Shuttle's design online on MIT's OpenCourseware site: http://ocw.mit.edu/OcwWeb/Aeronautics-and-Astronautics/16-88...
It features an extensive interview with a guy from DLR, the German equivalent of NASA. They talk at length about culture (freedom to fail), practices (extensive re-use), and ballpark performance metrics (on the order of < 10 LOC per programmer per day).
http://en.wikipedia.org/wiki/IBM_AP-101
http://en.wikipedia.org/wiki/Space_Shuttle
PS: It's easy to forget just how old and hacked together the Space Shuttle is: Historically, the Shuttle was not launched if its flight would run from December to January (a year-end rollover or YERO). Its flight software, designed in the 1970s, was not designed for this, and would require the orbiter's computers be reset through a change of year, which could cause a glitch while in orbit. In 2007, NASA engineers devised a solution so Shuttle flights could cross the year-end boundary.[38]
It is. The 5th has just enough to get the shuttle home, and is designed by a separate team. The presumption being that anything that knocked out the first 4 is probably a systematic failure.
A GPS string might erroneously say it's day 367 or be one character too long because it printed 20010 or a telemetry link might ask for 4million readings because it calculated "-1"
Their task are very specific not really leaving room for flexibility. You can almost compare the importance of these systems working exactly as expected with the physical parts of the shuttle.
P.S. A BSoD would indeed really become a Blue Screen of Death.
But, yeah, it’s not all black and white. Building the ISS would have been very hard without the overblown space truck.
HAL/S looks a little bit like basic or FORTRAN. It was designed to be very readable and uses some interesting formatting. When you print out a module (lets say GG1ASC), it uses three lines for each line of code so that the superscripts and subscripts are above and below like they should be.
The shuttle software isn't necessarily a good engineering solution.Spending the same time/effort/budget on a more critical part might have saved some of the shuttle failures.
If you think of it in aircraft terms, is it better to spend $ making the avionics software 99.9999% reliable rather than 99.999% or is it better to fit smoke hoods/more exits/better weather radar etc.