F-22 Avionics Require Inflight Reboot

An anonymous reader writes "The Atlanta Journal & Constitution is fronting a lengthy piece on the USAF's new F-22 and its upcoming shootout with the existing fleet of F-15's & 16's. One line in the article really jumped out at me: 'When avionics problems crop up now, pilots must restart the entire system as if rebooting a personal computer.' I did some googling, and this is about as much as I could find: The hardware backbone for the system is the Hughes Common Integrated Processor, which, in turn, appears to be built around the Intel i960 CPU. I couldn't find a name for the operating system, but it appears to be written in about one and a half million lines of Ada code; more on the Ada hardware integration and Ada i960 compilers is here. Any Slashdotters working on this project? If so, why do you need the inflight reboot? PS: Gamers will be interested to learn that nVidia's Quadro2 Go GPU and Wind River's VxWorks Operating System are melded in the F-22's Multi-Function Display."

Comments

Why a reboot - because the creators are bozos

[putaro]

Long ago a friend of mine was working on an add-in computer driven compass for the F-16 for a big defense contractor. She called me up looking for graphics algorithms (she was the junior engineer on the project). She was fighting with her boss who wanted to install an FPU to speed up their circle drawing routine (this drew the compass rose onto the screen) while she thought they could speed it up by switching algorithms. Why did her boss want an FPU - well, because software sine and cosine routines were too slow. (BTW, the circle was always the same size and just the tick marks actually moved).

Re:Why a reboot - because the creators are bozos

[TheStruuus]

not bozos, it's the government guidlines. For instance the fuel systems have redundent processor units. when started both are online with the slave electronicly disconencted. Following FAA guidlines dictates that a one strike and your out is enforced. At the first sign of CPU trouble (crash,freeze,any electronic part failing within the system) all inputs and ouputs on the unit are sent to high-z and the other unit takes over. Now the reboot part, the first unit will sit in a frozen state indefintly until it is manualy reset with a POR or full HR. But the plane will fly just fine on the redundent system. In an emergency the pilot can manualy reboot the halted system and it will either start up again (if the inital failure was some glitch) or immidiatly halt again if it was a critical falure.

Finally!

[decaying]

My years of Comp Sci with Ada as the language of choice (Uni's not mine).... I struggled with it, and grew to hate it.....

At least I know who uses the bloody thing.... The tutors never could.....

Re:Finally!

[Jeppe Salvesen]

Ada is excellent for this sort of stuff. It's been designed for implementing anal designs. That is exactly what is required in military systems.

I also thought Ada is a good language for teaching in Uni. You don't like it, but it will teach you a lot of important concepts, from its strong typing amongst other things.

That being said, it's not the right tool for most software development being done currently.

Re:Finally!

[lrichardson]

"That being said, it's not the right tool for most software development being done currently."

The older I get, the more I find this problem ... people get locked into 'language' mind-sets, without evaluating what is the best choice for the task at hand.

Take a look at VB. It's the McDonald's paradigm ... fast, and any grunt can do it with minimal training. Tasks can be easily seperated. Of course, the flip side is that debugging is hell (wtf is that code?), typing is next to useless, and performance ... not to mention it runs on windows ;)

Compare that to something like assembler ... takes forever to code, and, in most respects, kinda hard to debug. But runs great, and all the code in one place.

For projects like this, where the requirements are stability, stability and stability, you don't want any language known for problems in that area. Modularity is good, and forcing strong constraints (whether OO or not (e.g. Java and Pascal)) is vital.

I'm not sure I'd actually use Ada (and it's ilk)... any language where you're putting all the info on one line (e.g. Ada.Text_IO.Put_Line("Eject!")) is following the McDonald's paradigm, to an extent. Not to mention that sort of line level complexity severely impacts comprehension.

*Send Eject Message to Screen and HUD Msg="Eject!;"

Send Msg to Screen;

Send Msg to HUD;

Return;

Is a heck of a lot clearer, and thus less prone to errors. One of the cardinal rules about languages ... less errors per line and less lines required are both good and multiplicative. And choosing the languuage appropriate to the task (e.g. don't use Assembler for Web sites ;) reduces the number of lines

Remember the Yorktown? The ship that was dead in the water for hours, thanks to forgetting that rule ... anything requiring stability shouldn't be built on Windows (NT, IIRC)

Re:Finally!

[Afrosheen]

The trolls disappoint today. Where's the predictable goatse.cx link in response to this post?

Re:Finally!

[dvdeug]

I'm not sure I'd actually use Ada (and it's ilk)... any language where you're putting all the info on one line (e.g. Ada.Text_IO.Put_Line("Eject!"))

That's why you have use clauses; so you can write stuff like

with Ada.Text_IO; use Ada.Text_IO;

and then just write Put_Line ("Eject!");

Re: Finally!

[Black Parrot]

> Unfortunately your experience is far too common I have experience teaching Ada and C++ and was always amazed at the things people found to not like about Ada.

Me too, though I'm not sure I mean the same thing as you did when you wrote that.

Side note, the Ada old-timers often wryly point out that the reasons they often hear people give now for liking newer languages such as Java are often the same reasons people gave for not liking Ada 20 years ago.

> When using Ada I was often suprised at the level of frustration caused when a reasonably intellegent person is forced to jump through a lot of hoops in order to get a piece of code to compile.

Actually, that's exactly why I think Ada should be used as an introductory language. If beginners would learn to say what they mean and mean what they say, the world would be full of better programmers. If it takes a surly compiler to enforce a bit of discipline on beginners, then I'm all for it.

The software crisis isn't a result of having trouble getting programs to compile; it's the result of the attitude that anyone who can get something to compile is a programmer. We need to raise the bar on that somewhat.

Boeing's Avionics press release

[Perdo]

Boeing, responsible for integrating the F-22 Raptor's advanced avionics, has been testing software packages in both its avionics integration lab, or AIL, since 1998, and on its 757 Flying Test Bed, or FTB, since March 1999.
Both the AIL and FTB are helping reduce avionics risks and contain development costs by enabling extensive evaluation and troubleshooting before full avionics are ever installed on the F-22. Testing in the AIL and aboard the 757 FTB has allowed for early delivery of avionics Operational Flight Packages, or OFPs, to the F-22 test aircraft.

To date, Boeing has completed more than 21,000 hours of avionics testing in the AIL and 800 hours on the FTB.

Despite an accelerated delivery schedule for the year 2000 to support the Defense Acquisition Board, or DAB, requirements, the Boeing Avionics Integration team was able to integrate, test and deliver all Operational Flight Programs, or OFP's, ahead of plan. This included delivery of the Block 1.2 OFP on July 5, 2000, and Block 2/3S OFP on July 20, 2000. The AIL was also able to deliver the Block 3.0 OFP Engineering version to the Avionics Flying Test Bed aircraft a month ahead of schedule (Sept. 4, 2000) to allow for early testing and maturing of the OFP, which resulted in the first demonstration of multi-sensor fusion (Sept. 13, 2000).

The most significant accomplishment of the AIL for 2000 was the delivery of the Block 3.0 OFP, the first fully integrated avionics package, to F-22 aircraft 4005 on Nov. 21. This was a critical milestone since the Block 3.0 OFP was the first complete avionics software package to be flown on the F-22 aircraft, one of the most challenging DAB milestones accomplished to date.

The Boeing Avionics' Systems Engineering team's performance testing on the radar has resulted in all Test Performance Measurements, or TPMs, meeting or exceeding specification requirements. A significant milestone was reached on Nov. 15, 2000, when Raptor 4004 conducted its first flight, and targets were successfully detected and tracked in the air. Performance of the radar system was described as "eye-watering" by the pilot who flew the mission. A second major milestone occurred on Jan. 5, 2001, when Raptor 4005 flew for the first time utilizing Avionics Block 3.0 with the full complement of Radar Modes incorporated. Once again, targets were detected and tracked at long range, and the radar performance was outstanding.

Avionics Radar and Power Supplies Production activities continue to be a high priority. All shipments for PRTV I have been completed, PRTV II shipments are well under way, and hardware manufacturing for Lot 1 has begun. In the area of affordability, the implementation of Boeing-funded process improvements on several components of the radar/power supply systems, to include the T/R module and circulators, have been a tremendous success. The predicted cost savings have been substantiated in the first three production contracts and the targeted cost savings of $350 million dollars over the production life have been legitimized.

The next critical avionics milestone is delivery of Block 3.1 avionics. Block 3.1 will provide additional functionality to the F-22 Raptor and allow it to accomplish a significant amount of flight testing. Block 3.1 is scheduled to be delivered to Lockheed Martin this fall.

Overall, the F-22 avionics program is very much on target in the areas of performance, cost and schedule. The avionics packages have been performing exceptionally well, and all major milestones have been met on or ahead of schedule.

Re:Boeing's Avionics press release

[philipsblows]

According to what this says, the avionics package meets or exceeds expectations. Now, this is not an MS bash, but I can recall of the top of my head that our intelligence services have database software that can only search on one term that probably met or exceeded expectations, and there's that ship that had to be towed back to port due to some NT failures.

Now this is more of an MS bash... people have come to expect system failures, and I've read admissions that 5-9's uptime is just too difficult and expensive a goal, and so-on, and of course this mostly points to MS desktop and server software. I wonder if people who sit at desks and write specs all day for military projects decided that only having to reboot now and then exceeds expectations as set by people not flying in the aircraft.

I'll probably get modded down, but I just think this sort of thing (Boeing's press release, the actual performance as reported, and the overall state of technology in our government) is a bit troubling and it doesn't appear to be getting better.

Re:Boeing's Avionics press release

[Anonvmous Coward]

"Now this is more of an MS bash... people have come to expect system failures, and I've read admissions that 5-9's uptime is just too difficult and expensive a goal, and so-on, and of course this mostly points to MS desktop and server software"

That's an interesting read, my company chose Windows 2000 for stability as desktop machines, and we're doing fine. 19 desktops and laptops, all running 2k. My job is to maintain them, and I find way too much time to post on Slashdot. ;)

We've also got an NT4 webserver running IIS, and it's been up for 3 months. It would have been up longer except I had to shut the box down to move it.

I'll tell you something, it was a huge relief to go to 2000 from 98. Nobody bugs me about anything anymore. We have computers running all weekend processing video data. We haven't had an 'over the weekend crash'. We'll have 4 video files going at once, two per processor, and they'll all be done by Monday. As you can see, we beat our machines pretty hard sometimes.

*Thought it'd be nice for you to hear from somebody who's had good experiences with MS for a change.*

I've drifted off topic a bit. Sorry. The point I'm basically making is that Windows 2000 is a fine OS and would probably be up to the job, at least run-time wise. I know that comment's going to draw criticism, but oh well. I've worked around a ton of these machines for the last two years and you're not going to change my mind about it. Heck, I have a computer in my bedroom right now capturing TV shows as a home-brew Tivo. Hasn't been rebooted in over a month. Not bad given how buggy the TV drivers are. Heh.

Re:Boeing's Avionics press release

[forgoil]

Those who would criticise you must be pretty stupid. You simply tell your experience with win2k. I have found it to be a very stable OS as well, and any problems have more usually been a case of bad hardware/drivers in my experience.

Windows XP has also been really stable for me (and others). I have 10 days of uptime right now, without a problem. I only reboot for updates, and I do that at convienient times. The server 10 feet away only boots when need to fiddle with its hardware (behind a firewall after all). Win2k is just as stable as the two debian machines besides it.

Stop thinking that all windowses are as stable as Win9x, it is just not true. It would be like saying MacOS X is crashing all the time because MacOS 7.x did. Lying after all doesn't give good arguments in the long run. Let it be sufficient to say that Linux is stable and leave it at that, don't make such a point out of it being more stable than Win9x, nobody is speaking about how well Linux 1.2 does these days do they?

That said, I just installed Gentoo 1.3b at home, all the other distros are now 0wned;)

Re:Boeing's Avionics press release

[Your_Mom]

We've also got an NT4 webserver running IIS, and it's been up for 3 months. It would have been up longer except I had to shut the box down to move it.

So, when's the last time youve applied patches on that box? 3 months uptime means you are missing at least 1 major IIS patch that plugs a hole that allows an attacker to run arbitrary code.

Re:Boeing's Avionics press release

[dillon_rinker]

The point I'm basically making is that Windows 2000 is a fine OS and would probably be up to the job, at least run-time wise.

Up to the job...well, as a desktop OS for a typical business, I'll agree with you. For an avionics platform, though, I'd be afraid to be on the plane until it had been in use for 3-4 years and proven itself safe.

Re:Boeing's Avionics press release

[Shanep]

Up to the job...well, as a desktop OS for a typical business, I'll agree with you. For an avionics platform, though, I'd be afraid to be on the plane until it had been in use for 3-4 years and proven itself safe.

Absolutely.

Some embedded OS are required to respond to I/O within some seriously short time spans. Win2k, Linux/BSD with real-time scheduling might not be up to the task.

Win2k on the desktop, good choice if you want to pay for it. Win2k responding to a fault with an engine spinning at extreme rpms? No thanks.

Re:Boeing's Avionics press release

[Shanep]

Routine rebooting (probably -- I hope) wouldn't be tolerated in the final sytem.

Me too. Anyone seen the footage of the F-22 (I think from memory) which had computer failure during take off?

Seconds after the wheels left the ground the pilot was unable to stop the plane from pitching up and down. It smacked right into the ground.

I would LOVE to see someone try to fly an F-117 with a faulty avionics computer, since the magic of the F-117 is NOT the small RADAR signature, but the fact that it flies at all.

Re:Boeing's Avionics press release

[Your_Mom]

An unpatched IIS server on the intranet is still a problem. On our Intranet behind our massive firewall-o-doom, one of our developers ran an unpatched IIS server (unbenownst to IT). Someone from another department, who /also/ was running an unpatched IIS server somehow got infected with Nimda, compromised the developer's server.

Result? About 2 straight days of various servers getting their shares filled with .eml and .nws files. (Yes, we were running Virus protection, up until 2 days into the attack, Norton's virii definitions did not stop the virus from completely executing, it just stopped it from infecting machine)

So, Yes, its not the same, but, there are still major problems from running servers with holes, and it should not be done.

Re:Boeing's Avionics press release

[JWW]

IIS is turned off on our NT file server and it hasn't been rebooted in months (since its DLT drive ate a tape).

That being said, generally there is a patch, or software chnage, or settings change that requires a reboot 3-4 times a year. Almost all of our unix boxes have uptimes greater that that with the top one having an uptime (wait let me check....) of 559 days.

NT Servers can be stable. Win 2000 servers can be stable, but are they as stable?

Back on topic, when running a jet airplane that requires computers to keep it in the air you need 5 (or 6) nines of uptime. Anything else should be unacceptable. My belief is that this means a hand written "OS" to run the plane. Everything should be built from the groud up with an eye always on the uptime and reliability. And with this being a handmade OS, so to speak, I'm sure they will find the bugs causing the problem and fix them themselves. Something you can't do with NT (I guess you could do it if you bulit off of Linux, though).

Re:Boeing's Avionics press release

[pmz]

Despite an accelerated delivery schedule...

So why should we be suprised about any problems? Lack of time and/or budget for development are among the top causes for software failing in actual use.

While the F-22 is a beautiful and amazing aircraft, has the software industry matured enough to really handle its complexity?

Re:Boeing's Avionics press release

[Amazing Quantum Man]

but this is military product we're talking about.

They're pretty much free to accept whatever code they want, as long as it's written in Ada.


Disclaimer IWADC (I was a defense contractor).

A reboot in flight would be considered a "Priority 1" problem. Systems generally do not pass qual testing with any 1's or 2's.

Re:Boeing's Avionics press release

[Shanep]

You mistyped the last paragraph.

No I didn't, it's a straight cut and paste.

It's not consistent with the paragraph before it:

Hardly matters when A. my post follows his, B. I am clearly speaking about desktop OS, not Win2k specifically, C. I reference Win2k also and D. this...

Of course, you neglect to mention nobody would credibly assert that any of these 'interactive user-oriented' OSes are suited for that kind of high speed real time operation. That's what embedded controllers are in the mix for. Often tightly interfaced to a slower responding system that supervises everything.

is EXACTLY my point.

Re:Boeing's Avionics press release

[Fulcrum of Evil]

Start tweaking or upgrading, it becomes more unstable by the click.

Pray tell, what sort of tweaks were you making?

Re:Boeing's Avionics press release

[Fulcrum of Evil]

Back on topic, when running a jet airplane that requires computers to keep it in the air you need 5 (or 6) nines of uptime. Anything else should be unacceptable.

And the article under discussion is talking about datacenters running websites. When being down is defined as being unreachable by a significat portion of the internet, you are dependent on several external entities and 5 nines is a pipe dream.

Re: Boeing's Avionics press release

[Black Parrot]

> We've also got an NT4 webserver running IIS, and it's been up for 3 months.

Most telling of all is the fact that you think 3 months of uptime is worth mentioning.

For some of us, once in three months is excessively frequent for logging out, to say nothing of rebooting.

Re: Boeing's Avionics press release

[Black Parrot]

> Didn't catch the part where I said this: "It would have been up longer except I had to shut the box down to move it." Didja?

Yes, I did catch it. And it's completely irrelevant to my observation about how revealing it is for someone to bother mentioning a 3 mo uptime as evidence for an operating system's robustness.

> I have no idea how long the uptime would be if we didn't geographically move it.

Indeed you don't. And per your .sig, one example isn't very useful anyway. A more interesting measure would be MTBF, the standard deviation on that, and perhaps some suggestion of the upper bound (e.g., what's the MTBF for the 5% of machines with the best MTBFs).

But so long as you're mentioning uptimes that are a small fraction of the time some of us leave a source file open in the editor, or less than the amount of CPU time a developing program consumes during a test run without crashing, you're not going to score much of a PR coup.

As I said before, the biggest problem with software reliability these days is the low expectations on the part of consumers.

> It sure beats the pants off of "herrr herr, Windows crashes every 10 minutes." duddn't it?

I don't doubt that recent offerings from Microsoft are more reliable than Windows 2.0. Of course, you can make anything look good if you use a low enough standard for comparison.

Re: Boeing's Avionics press release

[Black Parrot]

> Windows 2000 is certainly more reliable than Windows NT, but in different situations you can be rebooting daily. My opinion is that it depends on what you are doing, and it depends on what hardware you run. ... An example of a low-uptime Windows app is an application server or power-user workstation.

Alas, I happen to be particularly interested in stability for power-user workstations.

BTW, thanks for the balanced post on the topic.

Please reboot...

[Subcarrier]

Apparently, the reboot is only necessary after discharging ammunition. The hardware configuration wizard will pop up and instruct the pilot to reboot the system in order to activate the changes.

Re:Please reboot...

[Anonvmous Coward]

He missed his target anyway. The pilot didn't realize he had to be logged in as Administrator to fire the guns in the first place.

Re:Please reboot...

[DavidBrown]

Actually the system requires a reboot only when a sprite enters a game cube...

Duh..

[Malduin]

If it requires an inflight reboot, there's no doubt what OS it's running. Gotta be Win98. I can see the MS tech support call now..

MS Support: "Thank you for calling Microsoft Customer support. How may I help you?"
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'General Protection Fault' in white text on a blue background."
MS Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
MS Support: "Oh yes, there are known issues that we will not admit to with that particular system. To temporarily fix the problem, simply reboot. Or, if the 5 minute boot time is too long, may I personally recommend that you eject. However, you will have to purchase another license of Windows 98 for $1000 since jet fighter crashes are not a valid reason to receive a new license."
Pilot: "@#$*(! Microsoft!"
MS Support: "Thank you and have a nice day!"

Re:Duh..

[sql*kitten]

If it requires an inflight reboot, there's no doubt what OS it's running.

RH support: Thanks for calling Red Hat! How may we help you?
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'kernel panic' in white text on a black background."
RH Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
RH support: If you read linux-kernel-bugtraq, you will see that you should have patched your kernel to 2.4.19-pre-alpha-revision-d before takeoff. But no problem, this is Linux after all. Do you have another F22 on your LAN? Just telnet in from there, su to root and restart sendmail.
Pilot: @#$*! Redhat! I'm switching to Debian if I survive!
RH support: Can I interest you in any RHAT?

Re:Duh..

[Bartmoss]

telnet? on a wlan? better use ipsec, or the enemy will have your f-22's passwords in no time.

F-22 HUD Display: "Your System has been 0wned."

Oops.

Re:Duh..

[Grey Brick]

If it requires an inflight reboot, there's no doubt what OS it's running.

FreeBSD support: Thanks for calling FreeBSD! How may we help you?
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'Fatal trap 12: page fault while in kernel mode' in white text on a black background."
FreeBSD Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
FreeBSD support: No worries, just send us a full backtrace... you _did_ enable debugging information in your kernel didn't you?!
Pilot: @#$*! FreeBSD! I'm switching to OpenBSD if I survive!
FreeBSD support: RTFM!

Re:Duh..

[GroovBird]

pilot@airoplane:~$ su -c "apt-get install ejection-seat"
Password:
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package ejection-seat

Damn!

Re:Duh..

[Rogerborg]

• If it requires an inflight reboot, there's no doubt what OS it's running.

Apple support: Thanks for calling Apple! How may we help you?
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'unresolved kernel trap' in white text on a black background, admittedly overlaid on very a friendly GUI. Before that, there was a three second delay accompanied by a busy icon whenever I tried anything."
Apple Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
Apple support: Oh, sorry, we don't plan to support that hardware until version 10.3. Can you use 10.2 Jaguar until then?
Pilot: @#$*! Mac! I'm switching to BeOS if I survive!
Apple support: Can I interest you in a .Mac subscription?

Re:Duh..

[gilroy]

Almost. But of course, if they don't admit the problem, it's not a "known issue". The conversation would be more like:

Microsoft: Oh yes, there are known issues with that system. We should have a hot update in, say, two to six months. Until then, we suggest the workaround of never leaving the ground.
Pilot: But it's a fratzing PLANE!
Microsoft: If you care to read your End User License Agreement, you will see that Microsoft makes no warranty as to the usefulness of the software for any given task, including that for which it was purchased.
Pilot: This is a $500M plane you're responsible for.
Microsoft: Actually, if you read the EULA, Microsoft is not responsible for any damages caused by failure of the software, whether or not those failures were known, or avoidable, or intentional.
Pilot: That's it. I'm ejecting.
Microsoft: Actually, sir, the maker of the ejection seats chose not to use WindowsXP embedded. To preserve the integrity of the Windows experience, your on-board avionics have been instructed not to interoperate with the rogue OS on the ejection seat. But WindowsEJ will be out in first quarter 2003 for your ejection seat pleasure.

Bresenham's

[EnglishTim]

Please tell me you told her about Bresenham's integer circle drawing algorithmn...

Lockheed's Avionics Press Release

[Perdo]

The requirements for the F-22's avionics system are derived from the F-22 Weapon System Concept, the guiding design principles for the aircraft's overall design. The integrated avionics system is one of the essential elements, along with stealth, maneuverability and supercruise, which will give the F-22 the tactical advantage against the threats of the future.

The F-22's avionics suite features extensive use of very high-speed integrated circuit technology, common modules and high-speed data buses. The avionics suite is an advanced integrated system that allows the pilot to concentrate fully on the mission, rather than on managing the sensors.

The avionics system is now flying on the F-22, and the advanced Block 3.0 software, which provides nearly full sensor and avionics functionality, began testing on the Raptor in early 2001.

Technologies incorporated in the F-22 include:

A common integrated processor (CIP), a central "brain" with the equivalent computing throughput of two Cray supercomputers

Shared low-observable antennas

Ada software

Expert systems

Advanced data fusion cockpit displays

Integrated electronic warfare system (INEWS) technology

Integrated communications, navigation and identification (CNI) avionics technology

Fiber optic data transmission.

Re:Lockheed's Avionics Press Release

[Perdo]

"A common integrated processor (CIP), a central "brain" with the equivalent computing throughput of two Cray supercomputers"

Um.. No:

ftp://download.intel.com/design/i960/perform/272 95 003.pdf

(Intel's i860 performance brief)

Re:Lockheed's Avionics Press Release

[KILNA]

They didn't say which two Crays. Perhpas a couple of 'em while powered-off?

Re:Lockheed's Avionics Press Release

[Asprin]

Technologies incorporated in the F-22 include:

A common integrated processor (CIP), a central "brain" with the equivalent computing throughput of two Cray supercomputers.


THHPBPBPBPT!!!

*That* shows you how old this 'hi-tech' design really is -- they're still using the old Standard Cray Equivalence Benchmark (SCEB) for performance comparision.

How 1988!

What *I* want to know is how many FPS does Q3A pull in 1600x1200 32bit with FSAA enabled!

F-22 "avionics"

[sluggie]

Sorry, but if you have to reboot the ENTIRE avionics system of a F-22 you're fucked to say mildly.

This plane is always in a controlled stall, the movements of the rudder to prevent it from crashing are calculated every second this bird flys, the pilot just decides in which directions the plane goes, but the task of keeping it up is left to the CPU.

So, if you just "reboot" this sucker for a second the plane would plummet like a stone, no matter how strong it's pushed forward by the engine or what the pilot does.

What I can imagine that the pilot would have to restart some none vital components of the main computer.
Such as the timing of the green/red flashlights or his seat heating. ;)
Even restarting the RADAR/TARGETING unit would be ok, BUT DO NOT SWITCH OF THE AVIONICS ON THIS BIRDY!

Re:F-22 "avionics"

[Moofie]

The flight controls are run by totally different hardware. It's the sensor and weapons systems that are at issue here.

Typically, when aero geeks talk about avionics, we're not talking about the flight control systems, even though those systems are now "aviation electronics".

Is this bad? Yes. Does it need to be fixed? You betcha. But don't worry about the planes not being able to keep the pointy end into the wind. That part seems to be working fine.

As an aside, the little anecdote about the test pilot intentionally making RADICAL configuration changes in-flight (moving fuel around, opening weapon bay doors, and wacky control inputs) producing only an easily-recoverable spin is a testament to the airplane's superb design. I mean, you do stupid things in ANY airplane and it'll bite you. The sign of a really GOOD airplane is that it then forgives you and doesn't splatter you all over the terrain.

Re:F-22 "avionics"

[PD]

You sure about that? A stall is a condition in which the airflow over the wing becomes turbulent and separates from the upper surface of the wing. That destroys lift until the smooth airflow is restored.

To say that the F-22 is in a controlled stall is just ridiculous. The proper way to state things is that the F-22 has relaxed static stability, which has nothing to do with a stall.

Re:F-22 "avionics"

[sluggie]

Alright I'm sorry, since english is not my native language I ceased to get the right definition of stall.

What I meant to say was that the CPU always has to do litle rudder movements to prevent it from falling down, or the other way round: the pilot wouldn't be able to keep the plane up with his stick alone.

And yeah, I know there's some subliminal punchline in "keep the plane up with his stick" ;)

Re:F-22 "avionics"

[Grab]

Not a "stall". A stall is where the plane flies too slow, the wings no longer produce enough lift to keep it in the air, and the thing basically just drops out of the sky.

The processor doing its little movements just means that it's an unstable system. Nothing new there, the SR-71 also requires an active control system to keep it going in a straight line, and that was designed 20-some years ago.

Grab.

Re:F-22 "avionics"

[Kysh]

> Sorry, but if you have to reboot the ENTIRE
> avionics system of a F-22 you're fucked to say
> mildly.

Avionics and flight control systems are separate
and extremely disparate.

> This plane is always in a controlled stall,

That is extremely unlikely. A stall is defined as
a condition when the wing exceeds the critical
angle of attack (Which is in turn defined as the
angle of attack where the airfoil is no longer
producing lift, but is instead experiencing
separated and turbulent airflow).

| .--.
| / \
Cl | /
1| /
| /
| /
| /
|/
+--------------
0 5 10 15 20
AOA (Degrees)

Is a typical graph depicting Cl (Coefficient of
Lift) and its relation to Angle of Attack. Lift
(And induced drag) increases with an increase of
angle of attack or an increase in speed.

Angle of Attack, for your reference, is defined as
the angle between the chord line and the relative
wind. The chord line of an airfoil is an imaginary
line connecting its leading edge with its trailing
edge.
The 'Relative wind' is defined as the flight path
of the aircraft.

Therefore, for an airplane to be flown perpetually
in a state of controlled stall, its airfoil would
always be pitched up at approximately 17 degrees
relative to the flight path of the airplane.

Would be quite funny to watch, actually. :>

There's a lot of misunderstanding about 'stalls'
out there. What the F-22 may be able to do better
than more 'conventional' airplanes, and perhaps
that to which you refer, is ride the edge of an
impending stall (In a high speed, hard banked,
high-G turn, for example) without diverging from
controlled flight.

I for one don't care for fly-by-wire. Perhaps I'm
old fashioned. :>

I'd rather the airplane do what I told it to do
than what it thinks I should have told it to do.
Same reason I like Unix- I don't want my airplane,
or my computer, doing what it thinks I meant
rather than what I told it. :>

-Kysh

Re:F-22 "avionics"

[Dun Malg]

20? try 40. It was first fielded during the johnson administration.

Re:F-22 "avionics"

[fferreres]

The sign of a really GOOD airplane is that it then forgives you and doesn't splatter you all over the terrain.

Good! Now MSCEs can defend the US in the IT and military fieldsby simply attending a 3 day intensive training seminar. As an expected bonus I can mention the HUGE savings in TOD. Oh god, the gift that keeps giving! :)

(TOD = Total Cost of Defense)

Re:F-22 "avionics"

[Zathrus]

I for one don't care for fly-by-wire. Perhaps I'm old fashioned

Well, sure... except that for modern fighter aircraft that's simply not viable. What the original poster was trying to say was that the F-22 is not inherently stable in flight (the AE's out there will now point out how minutely incorrect that statement is). If the flight control software goes wacky, you will be unable to fly the plane -- even if it was good ol hydralics and pneumatics.

The F-22, like a lot of newer jets, has totally integrated flight systems. The ailerons do not work seperately from other control surfaces, particularly the directed thrust system. A human trying to control all of this at once would be overwhelmed, and have considerably lower flight capabilities than a fly-by-wire system.

Another poster pointed out the pilot intenionally doing bad things to the aircraft - shifting all the fuel to one side, opening the weapon bay doors on that side, etc. which threw the jet into cartwheels at 45k feet. Once the pilot released the controls the jet self-stabilized. That's pretty damn impressive. Ok, sure, with fly-by-wire you're pretty well hosed if it doesn't do this because you don't have a "real" concept of what the plane is doing and reacting.

Fly-by-wire is becoming standard on large commercial jets too. I suspect it'll be a long time before it's common place on your small, private plane though -- especially since I can't imagine a single engine prop ever being designed to be "inherently unstable" in the air :)

One of the most impressive things I've seen a Raptor do so far (on Discovery Wings, of course, heh) is fly backwards... jet is flying straight and level, pilot pulls the throttle all the way up and the jet actually goes into a "controlled stall" and moves backwards (or so it appears visually) for a short distance. Hell if I know if it's useful in combat -- but nifty to the layperson.

Re:F-22 "avionics"

[Jeppe Salvesen]

I for one don't care for fly-by-wire. Perhaps I'm
old fashioned. I'm not sure. Automation sometimes enable us to do things we could not otherwise do. You could not fly the F22 without the computers - it's much too unstable. However, if the F22 was more stable, it would not have the required flight characteristics in order to win the dogfight as often as it could.

On the flipside, it's always good to be able to do as much as possible manually. When machines fail, we're fucked if we don't have any backup. I wouldn't be surprised if the terrorists at some point would attempt to teach us that.

The need to understand the basics first may be why they still teach students how to fly in small, primitive single-engine planes.

One last thing. Automation also levels the playing field a bit between the truly talented and the skilled. You like Unix because it gives you control. Most people dislike Unix because it gives them too much control - too few things are automated and beginner-friendly, and they don't know how to use their freedom. Hrmph. I sometimes wish the world was black and white, but it's much more challenging when it's all greys.

Re:F-22 "avionics"

[Shanep]

the CPU always has to do litle rudder movements

Is it doing it just with the rudder? What about at cruise speeds?

I would have thought it would intelligently be doing it with ailerons, elevators and rudder, depending on air speed and conditions.

How effective is the rudder in the F-22 at cruise speeds?

Re:F-22 "avionics"

[ebbe11]

and the jet actually goes into a "controlled stall" and moves backwards (or so it appears visually) for a short distance. Hell if I know if it's useful in combat

It is if the opponent cannot do the same. The opponent will overshoot and is now a very nice and easy target - as Argentine pilots found out the hard way during the Falklands war when flying against British Sea Harriers.

Re:F-22 "avionics"

[Shanep]

doing an estimation with opamps.

And there's nothing wrong with that! When I left the Navy in the early 90's, some ships were still using Valve based analog amplifiers to point guns.

Analog computers are fantastic since they don't require rebooting (they're much simpler), are able to work directly with analog values, are continuously correcting their positions and with extremely high resolution. I won't say infinitely small due to noise constraints throughout input and output transducers, amplifiers themselves and sometimes even gear backlash (not all analog computers are electronic, some merely use gearboxes).

Analog had its place and now to a lesser extent still does. Balanced signals with UTP ethernet that give great noise immunity are built on a great analog technology.

Re:F-22 "avionics"

[Shanep]

Actually, I'm not seriously asking those questions. That's my way of very nicely doubting that the rudder is the usual tool for avoiding stall.

Re:F-22 "avionics"

[Myrv]

You almost make it sound like FBW has 'a mind of its own' and fails to obey your physical feedback, which is not true.

Not quite. While true that in the strictest definition of FBW it does not have a 'mind of its own', by its very nature a 3rd party (usually another computer) can be interposed between the pilot and the FBW system. Just look at the Airbus A320 and family. The onboard computer on the Airbus has been shown on several occasions to override the pilots input. Some have claimed this disconnection between pilot and plane to has lead to several accidents involving the plane. On the other hand, I'm sure the system has also saved planes from pilot error.

Personally I feel any computer enchanced FBW system should have an override switch that causes it to accept direct control inputs in an emergency.

Now, whether the F22 has such a backseat driving computer system I don't know.

Re:F-22 "avionics"

[Zathrus]

Not a single SR-71 blackbird has been shot down. It flies too high up, and too quickly.

Well, certainly true for when it was flying. Modern missiles may be another issue entirely. But, yes, there are several stories floating around of SR-71 pilots flying around MiG's knowing full well that the MiG couldn't touch them.

With the extreme performance of the F22, wouldn't it be easier to dodge missiles? And harder for the opposition to lock and fire their missiles, because of the stealth?

In theory, yes... particularly the lock bit. In reality? Well, the Air Force will be testing that shortly, as the article mentions.

But assume that your missiles are rendered useless, either due to lack of target lock or acrobatics. So you're going to engage me with air-to-air cannon fire? When I'm more manueverable, faster, and harder to see (in both a radar and eye-to-eye sense)? It's a pretty safe guess that the F-22 will be capable of Mach 3 or greater -- since it can supercruise at Mach 1.6 without full power, much less afterburners. This is back up to where the SR-71 was... with a smaller radar and IR profile and missiles.

Although I'm sure a good bit of it is hype, I'd still hate to be going up against a Raptor without some radically new designs in radar and weaponry.

Re:F-22 "avionics"

[sysadmn]

Sorry, any pilot who opens the weapons-bay doors to release while the aircraft is UPSIDE-DOWN deserves it...

Re:F-22 "avionics"

[markmoss]

the center of gravity is positioned to the rear of the center of pressure. Doesn't that mean that in a stall, the nose will tend to go up and the stall become worse?

It's a safety feature.

[Black Parrot]

Everyone knows that frequent reboots prevents crashes.

Re:It's a safety feature.

[sql*kitten]

Everyone knows that frequent reboots prevents crashes.

The value of a reboot is that it restores the system to a known state. If you're depending on that system, you really don't want it to get into a state the designers never anticipated, because its behavior might be unpredictable. So in a sense, you are correct.

Similar to Mars Pathfinder

[Deton8]

In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion. Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't. I don't know anything about the F22, but it's easy to imagine that it has hundreds of input sources with all sorts of latency requirements. AFAIK, it all comes down to some humans trying to balance these conflicting needs. Clearly they don't always get it right.

Re:Similar to Mars Pathfinder

[ebbe11]

In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion.

Priority inversion is never caused by the OS, only by the interrupt/task priority design. So VxWorks shouldn't be blamed here.

There are RTOS'es that try to avoid priority inversion by temporarily raising the priority of the blocking task to the same priority as the task being blocked. This may at first look like a good solution but if the priority bumping happens too often, "medium priority" tasks may get starved because the low priority task is really running at high priority.

Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't.

Blocking interrupts may mean missing interrupts. This is a very dangerous thing to do in hard realtime systems, because what you don't know may not only hurt you but may actually kill you. If it is necessary to disable interrupts to get the system running, the system design is horribly flawed.

Re:Similar to Mars Pathfinder

[benhaha]

There is an interesting account of that here: What Happened on Mars?

Re:Similar to Mars Pathfinder

[slickwillie]

Maybe they should install a priority inversion indicator light. Then the pilot could fly upside down until it fixes itself.

Oh, never mind.

Re:Similar to Mars Pathfinder

[BigRedZX]

Priority inversion is never caused by the OS, only by the interrupt/task priority design. So VxWorks shouldn't be blamed here.

Yes, but it is WindRiver's fault.

The default configuration of all semaphores within 5.x VxWorks modules is to be 'simple'. In order to change these initialization values, you had either hunt through symbol tables and assembly code dumps or put a gun to the head of some poor slob in Windriver tech support.

To have a non-inversion safe objects inside a network stack is simply stupid design.

Re:Similar to Mars Pathfinder

[cheezedawg]

Whoa- I think you missed the point of this article. They didnt actually want a serious answer- they were only giving some nerds a chance to make some irrelevant Microsoft jokes.

Re:Similar to Mars Pathfinder

[X]

I thought it was possible to avoid significant problems with priority inversion by using a probabilistic scheduler... like BeOS?

Re:Similar to Mars Pathfinder

[ebbe11]

Yes, but it is WindRiver's fault.

The default configuration of all semaphores within 5.x VxWorks modules is to be 'simple'. In order to change these initialization values, you had either hunt through symbol tables and assembly code dumps or put a gun to the head of some poor slob in Windriver tech support.

I haven't used VxWorks and therefore I don't know the level of their documentation. But if the way a semaphore works can be changed, surely there must be a documented public interface for this. Otherwise it gives no meaning to have that flag in the semaphore at all.

The problem with the Pathfinder was that the developers had to apply the patch at run-time and therefore they had to pore over symboltables and whatnot. If they had been aware of the problem during debugging before launch, it could probably have been solved by adding a simple function call.

To have a non-inversion safe objects inside a network stack is simply stupid design.

No. To need priority inheritance because the design is not priority inversion safe is simply stupid design. The question one needs to ask oneself is:
Is it really necessary for the low priority task to have direct access to this resource and thereby running the risk of blocking the high priority task that uses the same resource?

There are ways to avoid priority inversion such as serializing access to the resource through the high priority task. Yes, at first this looks like priority inheritance but the big difference is that the high priority task is in control and can thus decide which request to process. Solving the problem with priority inheritance simply means that the high priority won't have to wait so long before the low priority task finishes.

Priority inheritance is the duct tape of real-time programming: It holds the program together but God knows for how long.

Re:Similar to Mars Pathfinder

[ebbe11]

I thought it was possible to avoid significant problems with priority inversion by using a probabilistic scheduler... like BeOS?

Probalistic scheduler? Had to look that one up :-)

No, because BeOS uses probalistic scheduling only for its timesliced tasks. In hard real-time systems, timeslicing is almost never used because it makes it a lot harder to guarantee that the system responds within the time limit - and getting that part right is hard enough as it is. Probablistic scheduling may help a little but it is not a cure-all. If it was, BeOS wouldn't need a Real-time class for tasks.

Re: Why do you need the inflight reboot?

[back@slash]

It's so todays pilots feel more at home with their fighter jets computer of course, having grown up with 90's software. You haven't seen the changes to communication protocal yet have you?

typical conversation between pilots
pilot1: u missed ur target fag u suck
pilot2: stfu idiot i'll kik ur ass
pilot1: lol ill show u how to shoot missles loser... im gonna get that camper anti-aircraft fag
pilot2: haha u missed 2... u couldnt even hit ur fat momma

and so forth....

Redundant

[Perdo]

The flight control computers are 7x redundant and distributed throughout the airframe. It's the new radar and v3.0 combat avionics that need "rebooting"

Re:Redundant

[duffbeer703]

MTBF is however long it takes to pump 7 shells into the various parts of the airframe where the computers are housed.

Re: F-22 Display Units

[Cardhore]

Thanks for the heads up. My mistake. :)

Re: Drivers?

[Black Parrot]

> Stonent Imagine a Beowulf cluster of whatever this story is about!

They already thought of that. You see, while they rarely mention it at air shows, the realy reason airplanes fly in formation is because those "formations" are actually high-availability clusters for their avionics software.

How I solved this for a heads up display - 15 ya

[jerryasher]

Sine, cosine? Assuming you have a line draw routine and a raster display, none of that is needed.

About fifteen years ago for a prototype heads up display I had the same exact problem: draw the tick marks for a compass rose with no memory and no time. There was no scaling of the circle, only rotation about a fixed center.

After some though, what I did was to store in a table the tickmark endpoints for 45 degrees of arc (I recall it being 22.5 and not 90 degrees) for all the displayable rotations of that arc. Then at runtime, my compass rose routine would exploit the symmetry of the situation to determine the endpoints of all the other displayable tickmarks.

It used very little memory since at any point in time we only displayed tick marks at 5 degree intervals. Therefore 45 degrees of those would be 9 tick marks, or 18 ints (two ints per tickmark). At 5 degree intervals with a resolution of 1 degree, you only need a table of 5 x those 18 ints, or 90 ints all told.

I always loved the 3am epiphany!

Contractor Breakdown for F-22

[gmanske]

For a good breakdown of who (LM, Boeing, others) supply what, have a look here.

Also, can anyone confirm if OSA is the name of the referenced ADA software project (1.7 million lines etc...)

Gmanske.

Re:How I solved this for a heads up display - 15 y

[jerryasher]

Ah, 3am then, but now I'm all done by midnight.

I needed four ints per tickmark then or most likely 180 ints all told. Of course you should be able to make these shorts as store not actual points, but vertical and horizontal offsets from the center of the rose.

imagine this

[drDugan]

MAVERICK
I've lost him -- where is he?

GOOSE
On your six -- coming hard. Four
hundred. Losing airspeed! He's on
your six and closing fast!
Hard left! HARD LEFT!

Maverick jerks the stick left, and the F-14 takes an
astonishing turn. Jester ROARS past into a wide arc.

GOOSE
Great move. Great

MAVERICK
He should've had me.

GOOSE
Take it down. Let's bug out of
here. Call for a draw.

MAVERICK
No way. Let's reboot. I'll nail him this time.
Going vertical.
...

There Is Something Rotten in Software Engineering

[Louis Savain]

Why do you need the inflight reboot?

Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature. Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage. It is the fundamental reason why dependable software systems are so hard to produce.

There is something rotten at the core of software engineering. Software functionality should not be fundamentally different from hardware functionality. Software should emulate hardware and serve as an extension to it. It should only provide the two things that are lacking in hardware: flexibility and ease of modification. The only way to solve the reliability crisis is to abandon the bad practice of using algorithms as the basis of software construction and to adopt a pure signal-based paradigm. More details can be found at the links below:

Project COSA

i960 in PC's

[Ratso Baggins]

More than 10 years ago I first saw a i960 dev board, and I thought "YUM! I can't wait for PC's to use them..." But they haven't. Anyone have any valid conjecture as to why?

Re:i960 in PC's

[OrangeSpyderMan]

A good number of RAID controller cards used them, and have done for a while now. They are in PCs all over the world as we speak.

Re:i960 in PC's

[John Miles]

If I remember right, some of the first commercial RAID boards ("Dell Drive Array") used the i960.

Can't think of anything else, though. The i860 and i960 were supposed to take over the planet at one point, but it never seemed to happen.

Re:i960 in PC's

[sql*kitten]

The i860 and i960 were supposed to take over the planet at one point, but it never seemed to happen.

The earliest version of Windows NT was written on the i860. The i860 machine was called the N-10, that's where the NT in NT comes from (other theories are "New Technology" and "Northern Telecom", but the NT product manager says it's from N-10 and I believe him). I expect the decision to mainly target x86 was just due to the sheer installed base, there was never a compelling enough reason for Intel, IBM, MS et al to move away from it. These days the i960 is used for Raster Image Processing (RIPing) in laser printers.

Re:i960 in PC's

[Shanep]

A number of printers have used the i960 for Postscript interpretation.

Re:i960 in PC's

[Sloppy]

Because if Intel had promoted processor heterogeneity and encouraged people to pick the best processor for the job, then Intel would be out of business by now. It doesn't matter that both (x86 amd 960) were from them; once people had gotten the idea that they should have portable code instead of relying on a single binary "standard", then they would have also had versions of their software for 68k, MIPS, etc. Adios, Wintel.

Re:I had to say it...

[Anonvmous Coward]

Not to be cliche or anything, and I'm sure you could see this one coming a million miles away,

but what happens when it crashes?

Hahahahaha!!!

This reminds me of some trouble I got into in high-school once: Anybody remember Channel 1? It started around 1990-1, and it was a news channel that some schools got. Each episode had a trivia question just before a commercial break.

One day, they asked "What is the most common cause of plane crashes?". I hastily and enthusiastically responded "gravity!!" I got in real serious trouble that day, I forgot that the teacher was also a pilot. The real answer was 'human error', which I had illustrated that day when my teacher shot me down to the principal's office.

Drivers?

[zentu]

So, uh when do they update the drivers for the displays, and when do they know that there was a problem with them? Pilot: Air traffic contol, come in. Air Triaffic contoler: We read you Pilot. What's your problem. P: The heads up display is going fuzzy, any clue what may be wrong?. ATC: Let me see, what version of the Windows F22 are you running? P: The version my machanic put in. ATC: So do you see the blinky red light in the left corner? P: No, I see a green one on the upper right. ATC: Well, you need to come back to base then, you have the old drivers. P: O.K. I will turn around now. ATC: Oh, by the way, the problem with your version is that the ground is actually off by six feet, becareful. P:WTF? Is it up or down? ATC: it varyies, by the driver version....

Re: Why do you need the inflight reboot?

[Anonvmous Coward]

They're having trouble recruiting new pilots today because they're sick of campers sitting there using their anti-aircraft guns.

Re:IMHO the USAF has more acronyms than M$

[Perdo]

Microsoft Acronyms:

http://www.microsoft.com/hwdev/resources/glossar y. asp

Government and Military acronyms:

http://www.ulib.iupui.edu/subjectareas/gov/docs_ ab brev.html

And the Winner is:

Not us.

Re:F-22 BSOD...

[Anonymous Coward]

I wonder if there are Ctrl, Alt, and Del buttons on the F-22 cockpit console?

Sure, Ctrl is on the right control panel, Alt on the left, and Delete on the stick. :-)

grrr

[yatest5]

If so, why do you need the inflight reboot?

Is this how low slashdot has sunk? Someone can't be assed to research themselves the answer to a question so they post it to our x million readership?

Or maybe it's just another shameless editor troll for reams and reams of the same tired old offtopic MS / Windows 98 / BSOD jokes?

Jesus, is there any chance of getting any intelligent replies? I checked out kuro5shin recently and was surprised at how intelligent most of the posts are.

Anyway, mod me down because I haven't slagged MS, whatever.

Unfortunately, they are using Ada

[Florian Weimer]

Since they use Ada, this war machine will actually work, despite more 1.5 million lines of source code running it. That's sad, why couldn't they use C, C++ or even Java for such projects, where failure might actually benefit mankind?

Re:Unfortunately, they are using Ada

[Mr_Silver]

That's sad, why couldn't they use C, C++ or even Java for such projects

Because for mission critical applications the US Department of Defence consider C, C++ and Java to suck.

See here for a brief history about why the US Department of Defence found that they were using 450 odd languages and needed to standardise on one common one that did everything right.

They produced a specification of what the language should do and found that nothing out there did what was required well enough. So a competition was born and ADA was the language that won it.

Re:Unfortunately, they are using Ada

[jred]

For some reason the thought of having jet fighters and missiles running VB doesn't make me feel safe. Quite the opposite...

Re:Unfortunately, they are using Ada

[Stultsinator]

Why Ada?

Because quite a few years ago when all source code was Assembly, the US sponsored a Compile-off between high-level languages. The idea was that they'd adopt a single language and build compilers for it suitable for the thousands of different processors we use in all of the various systems around the world.

So Ada won, even though it was developed by a French consulting firm. Even now we maintain an Ada compiler for every single CPU type in existence. In fact, this is why Oracle's PL/SQL code looks so much like Ada. When Oracle was looking to make a PL for their database, a few gov't guys said: "Hey, why don't you make it like Ada. We'll buy it and our programmers won't have a high learning curve to tackle."

Re:Unfortunately, they are using Ada

[Florian Weimer]

People tried to get a custom contract for Microsoft Visual Studio (or some other development product). They failed.

I can image that the situation with Sun is better in gernal (maybe not in the Java area).

Re:Unfortunately, they are using Ada

[Florian Weimer]

Without even considering the lives that would be lost due to the software failing...

Projects of this size which are not carefully planned (which involves the choice of proper tools) tend to fail during development, not in the field.

Re:Unfortunately, they are using Ada

[Stultsinator]

That's interesting - thanks for clarifying that for me.

I think the reason the story stuck in my mind was that it made sense (the reason for sponsoring the competition, ie. too many dialects of Assembly for too many processors.) What confuses me now is: If they already had high-level languages in common use, why not enhance them rather than start from scratch?

Entropy?

[Bastian]

I seem to remember hearing somewhere that the avionics system on the F-22 uses a neural net of some sort. In my experience, some kinds of neural networks can develop this creeping flakiness as a result of a sort of entropy in the weightings on each neuron. Since neural nets are subtle enough that it would be nigh-impossible to get rid of this cruft on the fly, the best way I can think of to fix problems is to simply reset all of the weights to a default value.

The best analogy of this that I can think of is to say that it's similar to a reboot, even though it doesn't necessarily require shutting the entire system down for a period of time.

Of course, like all hearsay, this doesn't make a whole lot of sense when you think of it. . . I'm not aware of any reason why they would put a neural net that continues to learn while it is being used in control of the avionics system, but then again a lot of technologies I see make no sense to me. . .

Yanno...

[Greyfox]

This is the only application I can think of where you reboot BEFORE you crash...

Moderation Funny(+1)?

[Cryptnotic]

This isn't a joke. Read the linked pages, moderators. There is a rather large amount of thought and theory behind the ideas presented.

Of course, any computer can be thought of as a signal processing device. It has input (the sequence of bits in the program code and data storage and external input (e.g., keyboard, mouse, network, etc)), state (memory, registers, etc), and output (display, sound card, printer ports, disk, network, etc).

Re:Moderation Funny(+1)?

[flatrock]

Here's the funny part.

Software should emulate hardware and serve as an extension to it. It should only provide the two things that are lacking in hardware: flexibility and ease of modification.

If you've ever worked on a device driver for a relatively complicated piece of hardware you'll quickly figure out that this already is how it works. The problem is that the hardware designs are also buggy, and your driver often ends up 10 times more complicated because you need to fix hardware bugs in the driver. This is because hardware is infleximle and hard to modify. The post is funny because it assumes that the hardware is solid and stable, and that the software is to blame. While the software may be to blame, the hardware almost invariably has a variety of bugs that are being worked around in software. Such is the nature of product development.

Re:F-22 BSOD...

[revbob]

Ever hear of a CB (circuit breaker)? Works like a charm.

somewhere up in blue skies...

[tanveer1979]

Alert, i have crashed please reboot

__reboot__

Last time you rebooted it was due to a crash ..

• 1.reboot in safe mode(no missiles)
• 2.reboot electronics only
• 3.Reboot in parachute mode

__parachute mode__

Illegal instruction at address FFCFFFCC

• 1. Start praying
• 2. SEnd email to mom
• 3. Wait

__2__

ould not connect to mail server

• 1. retry
• 2.Abort
• __2__

• Illegal instruction at address blah blah So you want to die:

  • 1. With fireworks on ground
  • 2. In ocean
  __2__

  I wont listen to you i a going to crahs now.. 4 5 3 2 1 . . . Failed to crash :-(

  and so the pilot walks home safely :-)

Re:There Is Something Rotten in Software Engineeri

[plaa]

Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature. Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage. It is the fundamental reason why dependable software systems are so hard to produce.

This reminds me of a story on Slashdot a few years ago about the process of writing the software that contols space shuttles. Still an interesting read.

(As timothy writes: These guys are "pretty thorough" the way Vlad the Impaler was "a little unbalanced." I could have certainly sometimes saved a lot of time using similar bug-documenting stuff.)

vortex-induced lift

[bob@dB.org]

have a look at this. i'm not saying the f22 does this, but the concept is not ridiculous!

Re:vortex-induced lift

[PD]

Actually, that's the opposite. A vortex is not exactly turbulent flow.

Also, a vortex generated above the wing can delay separation of the flow from the upper surface of the wing. As I said before, the separation of flow from the upper surface of the wing is a stall. So, a vortex is NOT a stall.

Re:F-22 BSOD...

[DragonTHC]

no no, you see ctrl-alt-del is on the stick, though you have to press them at exactly the same time or you'll launch a missile :

Re:There Is Something Rotten in Software Engineeri

[Black Parrot]

> Software functionality should not be fundamentally different from hardware functionality.

Am I to understand that you are saying that software, like hardware, should only fail when it fails?

Granted, we have a software reliability crisis on our hands. But hardware isn't generally fault-free either. I've had a lot more Zip drives die on me than I've had kernel panics. And arguably a kernel is much more complex than the design of a removable disk drive.

> An algorithmic system is temporally inconsistent and unstable by nature.

That's an absurd claim. It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.

The biggest engineering difference between software and hardware is that people find software errors acceptable, or even normal, whereas they have never reconciled themselves to, say, collapsing bridges or wings falling off of airplanes. When that attitude changes we'll start seeing software that rivals hardware in reliability, not before. Most of the engineering concepts required for producing good software have been around for quite a while.

Re:Ada ?

[Kysh]

> This means the developers were forced to use
> Ada, but why ? To me, it seems some suits think
> it's especially "safe" for some reason, does
> anyone know more about that ?

Ada is especially safe. It is, in fact, one of the
VERY few safety critical environments you will
find. It's very simple- A safety critical program
must never exit and give up control functionality
entirely, no matter what happens. There are many
things that you can do with C/C++/Java that will
cause a crash unrecoverable by the system.

Ada is designed to inherantly prevent a programmer
who follows the appropriate standards from writing
a program that can just crash and exit. As long as
every possible exception has a handler, an Ada
program can be written that will not crash.

> But I think you can try to make a programming
> language as "safe" as you want, it won't prevent
> you from implementing bugs, it just causes a
> false sense of safety instead which can be even
> more dangerous, IMHO.

Bugs are universal. But bugs in a C program can
cause the controlling system to shut it down with
prejudice (Sig 11 and others), and it doesn't
offer the automatic safety nets Ada does. Can you
write safety critical software in C/C++/Java?
Certainly. It's all a matter of methodology. Ada
enforces the methodology, which is why people hate
it. They can't do cute, horrible hacks like they
can in C/C++, and Ada requires explicit
specification.. Ada has specific standards of
implementation for software, and a good inherant
design. It is designed, from the ground up, as a
'safety critical' language, and for the most part
succeeds on its own merit.

I do understand the widespread animosity towards
Ada. People don't like the verbose, very specific
code. Progammers often want to bend the langauge
over their knees and perform horrid hacks that
make reasonable people blanch in fear, but Ada
doesn't really allow that. Programmers are often
forced to learn Ada in structured learning
courses, and forced to read the Ada RM. They end
up hating it because of the language and
terminology used, because of the verbosity of the
language, because of some of the difficult
concepts of Ada, etc..

But it really is a fine language. (I'm sure many
people will disagree with me without really having
an objective or informed viewpoint, but that's
just how it goes)

-Kysh

Pictures of F-22

[LippyTheLip]

Perhaps I am not the only slashdotter left who does not know what this thing looks like.

You can find a selection of pictures here. The fourth and fifth rows from the botttom of the page have photos of the F-22. The best one is here.

In my past experiences...

[TrAvELAr]

I used to be an avionics tech/computer system specialist for the US Navy. I specialized on the AYK-10 mission computer. During the years, I worked on/flew in the S-3B Viking. Due to the ancient technology of the AYK-10, we often did not even boot it until we were in flight. The magnetic drum did not like the carrier take-offs and often dumped if booted before flight. Rarely, did we have to reboot after the initial boot. Flight control was not affected by this. Neither was basic NAV/Weather radar or comms. As for ada, DoD is big on it. When I asked about it in the AYK-10 school, they told me it was because it was small and clean. I'm not sure that I agree with them, but since I don't know ada, I'll have to take their word. I'm guessing that the mission computer is based off of 80's technology as that would be par for DoD standards. At least it's pre-windows era. :)

Re:In my past experiences...

[shaldannon]

I'm not sure Ada is small and clean either, and I had 4 years of it at Auburn University since that was the required language for data structures and algorithms classes. They alleged that Ada was bullet proof as a language...that it never crashed, dumped core, etc., so made perfect sense for use in avionics. Mind, we were getting government contracts, so it's entirely possible that they were spouting the party line.

At any rate, my observations are as follow: First, the Ada syntax was based on the Pascal syntax (they state this in the textbooks). Second, it is almost as anal as Java. Third, you may write a program in Ada but if you use Gnat to generate your code, it's getting translated to C anyway, so theoretically your bullet proof code just developed some vulnerabilities.

I guess Ada has its uses, but I heard recently that even the DoD has stopped requiring its use.

Re:In my past experiences...

[Amazing Quantum Man]

At any rate, my observations are as follow: First, the Ada syntax was based on the Pascal syntax (they state this in the textbooks). Second, it is almost as anal as Java. Third, you may write a program in Ada but if you use Gnat to generate your code, it's getting translated to C anyway, so theoretically your bullet proof code just developed some vulnerabilities.

1. What do you mean *ALMOST* as anal? It's more anal.

2. You won't be using GNAT in an avionics systems. You'd be using a Validated platform. That means that the compiler, OS, *AND* target platform have been validated together. It costs a bundle.

3. DoD has removed the mandate that ALL new software be written in Ada, but most avionics are written that way for safety reasons (editorial: Ada83 sucked, but Ada95 is a fairly decent language).

Re:In my past experiences...

[shaldannon]

yeah, I heard a rumor that Ada83 sucked, but having only played with Ada95 I can't confirm or deny that rumor. Note, too that all of my experience was writing assignments for class, so we're talking about trivial things here (although there was the infamous bank system project that when completed had a good 30 files associated with it...'course I got so lost trying to figure out what I was supposed to be doing, let alone how to do it, all along with my other homework, that I failed the class). If I had that bad of an experience with contrived Ada programs....what's the real world like? *shudder* No wonder they pay mid-to-high 6 figure salaries to program Ada....

I'll stick with Perl, thanks...

Re:In my past experiences...

[gorilla]

I'm not sure Ada is small and clean either

Ada wasn't designed to be small and clean. It was designed as a 'catchall' language, able to do everything from low level system programming - replacing assembler & C to the highest possible level application program. You can't really make a small & clean language, and hit both ends of this spectrum. On top of that, it was realized that a lot of the 'bugs' in programs are preventable, because they are caused by the programmer not properly handling error conditions. So they added in features which make it harder for the programmer to screw up. Together, this means that Ada is a very large language compared to other languages of the 70's, however you don't have to know all of Ada to write a program, especially if you're only working in one problem domain.

As for the requirement, as of 1994, is that Commerical off the Shelf (COTS) is the prefered choice, whenever it meets their needs. Failing that, Ada is required, but waviers can be granted if they are cost effictive, and that the proposed alternative does not compromise the goals of the project - in particular the safe programming practices that Ada requires.

Re: In my past experiences...

[Black Parrot]

> Second, it is almost as anal as Java.

FYI, engineering of any kind is an anal retentive profession. It's the underlying concept of getting things right that's anal, and the anality is inherited by any procedure or tool that supports that goal.

That's as true for a mechanical engineer as it is for a software engineer.

Re: In my past experiences...

[shaldannon]

I wasn't thinking about proper software design when I made that statement. I was thinking about the relative ease of use with respect to different programming languages. Perl is like a surgeon's kit. You can do all sorts of neat and clever things with it, but if you mess up even a little bit, you got a big mess. Ada is more like a construction worker's toolbelt. You have lots of little safety devices attached to keep you from maiming yourself, but it also precludes you from doing create or clever work. When even simple typecasting is a chore, then a language qualifies as anal.

Re:In my past experiences...

[dvdeug]

Third, you may write a program in Ada but if you use Gnat to generate your code, it's getting translated to C anyway

First place, GNAT does not compile to C - it compiles to GCC trees and then to assembly, just like the C compiler in GCC does.

Secondly, there's no reason why translating to C would change anything. The reason Ada has less problems than C is that it checks all arrays, it's more restrictive on pointer use, it prevents mixing of unrlated types; all of that is preserved when translating to C, and could be written in C by a very careful programmer.

Re: In my past experiences...

[aebrain]

Perl is like a surgeon's kit. You can do all sorts of neat and clever things with it, but if you mess up even a little bit, you got a big mess. Ada is more like a construction worker's toolbelt. You have lots of little safety devices attached to keep you from maiming yourself, but it also precludes you from doing create or clever work. When even simple typecasting is a chore, then a language qualifies as anal.

Can't agree with the last two phrases. There's nothing to stop you making everything numeric FLOATs if you want. Then you can cast away to your heart's content. You won't be worse off than with Java or C++. You want seat belts, you pay the price, but they're optional. Highly recommended though.

As for not being able to do creative or clever work... Last year I had to do the programming for the mass memory of a scientific satellite. Memory-mapped IO. BUT it used a different memory-map from the rest of the hardware, different endianism, addresses 0 and 1 were valid, 2 and 3 weren't, 4 and 5 were valid, 6 and 7 weren't etc etc. It was bank-switched, with multiple threads of execution trying to access it simultaneously - so all request had to be queued. Oh yes, in a high-radiation environment, so everything had to be tell-me-thrice with error-correction for soft failures, self testing in an embedded thread of its own. etc. On an old CPU running at the glacial pace of 8 Mhz.

It was done in Ada - of course. I'm not a genius, I don't think I could have done it in the time available if I had to use C. And certainly not ar reliably, regardless of the time available. Just used representation clauses and a huge array of records, each of which was a word with only the top 2 bytes defined, the rest being don't-care. So it was 2 orders of magnitude faster than the original address-computing method. Impossible to address a byte that wasn't there, impossible to underflow or overflow, impossible to deadlock or miss a request due to Ada-95's protected objects.

Clever, creative - others can judge that. It was my code, so of course it was brilliant he says sarcastically.

Re: In my past experiences...

[Black Parrot]

> Ada is more like a construction worker's toolbelt. You have lots of little safety devices attached to keep you from maiming yourself, but it also precludes you from doing create or clever work.

Good analogy.

Thing is, we expect creativity and cleverness from architects, but not from construction workers. Construction workers are supposed to follow well established procedures that contribute to cost-effective construction of a correctly built structure. When a construction worker decides to express his creativity by welding a joint that is spec'd out to be bolted, or leave out a few bolts in the name of speed or weight reduction, then he's off the job.

And even the architects have a lot of constraints placed on how they can express their creativity and cleverness.

> When even simple typecasting is a chore, then a language qualifies as anal.

I'm not denying that it helps to be anal if you program in Ada. What I'm arguing is that our profession needs to be more anal about things than we traditionally have been.

As for typecasting, I like to think of it as a way of telling the compiler, "Yes, I know what I'm doing, and yes, I really did intend to do it."

The goal, for some of us, is to minimize bugs rather than minimizing keystrokes.

Re: In my past experiences...

[shaldannon]

I place less value on minimizing keystrokes than I do on being able to do something without having to figure out all the conversions necessary to get it done. Call it a weakness or whatever, but I find I like a weakly typed language like Perl for this reason.

Of course, it may very well be that using Perl is like going over to the dark side...I don't know. I do know that after a year and a half programming nothing but Perl that it was really tough to do C, let alone sit down with Java or Ada.

And it isn't so much a cry of "why can't ____ be more like Perl." As I said before, I understand the reason for many of the methods used in Ada programming, even if a little verbose. It certainly makes the code more readable, and I like the ability to create procedures within procedures. However, my two biggest gripes with Ada are its typecasting and its I/O routines because you can't mix types.

The argument one of my profs used about the I/O was that no language let you do multiple types in a print statement except for C, which he said was a special case. He said C++'s cout was really a series of different output streams depending on type. That's fine to say, but C, C++, and Perl all let you specify multiple types for output at least in the same command, even if they handle it behind the scenes for you.

Perhaps I'm settling for the 'Laziness' virtue here, but I wonder if it's unreasonable to expect that sort of ease of use in other languages.

Re: In my past experiences...

[Black Parrot]

> I place less value on minimizing keystrokes than I do on being able to do something without having to figure out all the conversions necessary to get it done. Call it a weakness or whatever, but I find I like a weakly typed language like Perl for this reason.

I'm less of a hard-liner than I may sound sometimes. E.g., for quick hacks I almost always use Scheme. (I wouldn't call it "weakly typed", but it is declaration-free.)

> Of course, it may very well be that using Perl is like going over to the dark side...I don't know. I do know that after a year and a half programming nothing but Perl that it was really tough to do C, let alone sit down with Java or Ada.

I think any language can have that effect. After a year when I used an extra lot of Scheme, I found myself asking "Where's the $CENSORED in-line 'if' function?!?!?" when I went back to my my work-a-day habits.

> However, my two biggest gripes with Ada are its typecasting and its I/O routines because you can't mix types.

There's a pretty easy workaround for mixed I/O in Ada; you just append all the garbage together into a single string argument. It will still have something rather like the typecasting where you convert all the numerics/whatevers to their string images, but at least you don't have to do a separate Put for each item.

> Perhaps I'm settling for the 'Laziness' virtue here, but I wonder if it's unreasonable to expect that sort of ease of use in other languages.

"Ease of use" is always a problematic concept. While Ada is too syntax-heavy for many people's tastes, I find that after suitable declarations I can often program at a very high level of abstraction. (Though perhaps that's true of any language?)

At any rate, in line with what another poster said yesterday, I shudder to imagine doing some of the stuff I have done recently if working in some of the other languages I've used in the past. For me, "ease of use" has to be a big-picture evaluation. Which is, I suppose, why I use Scheme for a quick math problem and Ada for 10,000 line program.

Re: In my past experiences...

[shaldannon]

I guess that makes sense....

If I currently had a use for Ada I'd ask for some sample code...unless you can think of one for the average programmer who has lost the hacking bug...

Re:There Is Something Rotten in Software Engineeri

[joib]

When that attitude changes we'll start seeing software that rivals hardware in reliability..

Or will we start seeing bridges collapse as an everyday occurance? :) Well, hopefully not.

Re:There Is Something Rotten in Software Engineeri

[RobinH]

There is something rotten at the core of software engineering.

Careful. If anything is rotten, it's the practice of trying to apply pure computer SCIENCE to practical machine control problems. Real engineers (who have a degree in engineering) tend to be much more pessimistic, self critical, and more driven to design the system before sitting down to write software. Reliable machine control software does get written on a regular basis, and much of it gets written in an algorithmic paradigm.

Engineers who write good machine control software do several things to better their odds:
1) KISS
2) Stay away from dynamic memory structures when you can, otherwise use a language or environment that helps check for memory leaks, etc.
3) Use a proven platform (i.e. a PLC, VLC, or a good RTOS like QNX).
4) Design, write spike solutions, design, discuss, redesign, discuss, design again, write, test.

Real software engineering may not be an edge of your seat, nailbiting, all night hacking experience, but it does tend to produce reliable, working results.

Re:Ada ?

[Jamie Zawinski]

Ada is especially safe. It is, in fact, one of the VERY few safety critical environments you will find. It's very simple- A safety critical program must never exit and give up control functionality entirely, no matter what happens. There are many things that you can do with C/C++/Java that will cause a crash unrecoverable by the system.

Ada is designed to inherantly prevent a programmer who follows the appropriate standards from writing a program that can just crash and exit. As long as every possible exception has a handler, an Ada program can be written that will not crash.

In what way is Ada better than Java in this respect? I only know a little about Ada, so this is a serious question. My understanding is that Ada and Java have very similar safety goals (especially with respect to exceptions) so I'm curious about what you think Ada gets right and Java gets wrong.

It should be the case that the only way for a Java program to "crash" is if there is a bug in the runtime library or hardware interface: the same kinds of problems can of course affect Ada.

(I've got a lot of problems with Java, mind you, but I'd never say it was "too lenient"...)

Re:Ada ?

[Kysh]

> In what way is Ada better than Java in this
> respect? I only know a little about Ada, so this
> is a serious question. My understanding is that
> Ada and Java have very similar safety goals
> (especially with respect to exceptions) so I'm
> curious about what you think Ada gets right and
> Java gets wrong.

Let me be fair.. as a language, I'm not terribly
familiar with java. I have spent a great amount of
time supporting Java developers on the system
level, however. I have seen developers write java
code that crashes in very gnarly ways, and had to
support them. I've seen java interpreters just
spontaneously die. Now this could certainly be
buggy implementations, and not a bad language
specification. While that was not the impression I
was given by the developers in question, I don't
deny the possibility. I have, personally, never
seen an Ada program 'crash'. I have never seen an
Ada program exit in any way other than an
unhandled exception or a normal exit. I've seen
Java do a lot worse.

I will not say that java, as a specification, is
less 'safety critical' than Ada, only that I am
not aware that it is as much so. If the
implementation is the problem, as I mentioned that
it could be above, then pending better
implementations, I'll check back in with this
topic. :>

In closing, though, I have to say that, from the
information I have, an Ada program is about a
billion times more reliable than a Java program,
when you're talking about large (Or huge)
applications. Ada also has the benefit of a big
experience base, mathematical analysis, review,
etc.

I'm open to comments regarding Java
implementations, stability, and the
safety-critical methodologies present (Or lacking)
in Java from those more familiar with the
language.

Respectfully,

-Kysh

Reboot

[cybercuzco]

Yes, you do have to reboot the computer if one of them fails. However, the F-22 has 3 redundant computer systems, so that if one or two go down the remaining one(s) take over while the bad one is rebooted. If its a more permanent problem, say the computer is shot, well then you cant really reboot that. And if all of your computers go down? Reach between your legs and pull the ejection lever, because the plane is not only unflyable without computers, it wont even glide without a computer.

Re:There Is Something Rotten in Software Engineeri

[fferreres]

[sarcasm]
Ok, I buy it. Now show me some Cosa that can emulate my Linux Kernel, my Galeon browser and my Mplayer media player (or another tool/application at your choice) so that I can see which one's best.
[/sarcasm]

Algorithms do not make programs fail. Bad logic makes them crash and be unstable. The HIGHER the language level, the lower the failure rate and the faster/cheaper the implementation is. I'd love to see an OS developed as in a DSP fashion :)

Re:F22???

[shaldannon]

*sigh* I hope you're trying to be funny. If not,... Well the F22 is the US' next-generation fighter. It's supposed to have all the stealth technology of the F119 and B2 and all of the maneuverability of the F16. Basically it's a very droolable, expensive toy for the government to spend $$$ on...

Windows... better, but still not competitive

[DaveWood]

I will certainly grant that Win2k is a significant improvement, and perhaps an order of magnitude more reliable than NT4. I don't generally count Win98 in these comparisons; even very few slashdot trolls will stand up and try to make a go of claiming Win9x/Me exhibits reliability of any kind.

However, to put it in perspective, doing normal development with Java, VBScript, IIS, MS SQL Server, MySQL, Flash (I am deliberately excluding crashes that occured while coding C/C++ and other "non-safe" systems), I observe Win2k either bluescreening, spontaneously rebooting, or getting to a state where it needs to be power-cycled approximately 2-4 times a month. This seems like heaven compared to NT4, which I I used to crash daily while doing Java development and writing ASP pages for IIS. Most NT4 production servers I am aware of are rebooted regularly, often nightly, to prevent them from falling apart altogether. My experience with NT4 has been unequivocal. Don't use it in production unless you want to suffer.

That's not counting Win2k's constant explorer crashes, which are generally not disruptive but still a bit unsettling. The majority of the problem appears to come from Microsoft being unable or unwiling to sanitize the GUI code and protect failures to handle the GUI layer correctly from killing the entire system. That, and I still see the standard device-related problems. Burning CDs and attaching new mice have both proved catastrophic for Win2k, in the latter case requiring a complete reinstall of the operating system. No, I didn't build the mouse myself; it was a Logitech mouse.

I also note that, as with all other versions of Windows, Win2k still has a tendency to "decay;" that is, to continually develop small but uncorrectable problems until reinstall is eventually required. However, the decay rate also seems to have been slowed.

Compare this to Linux, which I also give daily and roughly equivalent use, and which _never_ crashes. _Ever_. In fact AFAIR the last time I had to deal with unexpected shutdowns on Linux was due to a foolish attempt to build a complicated high-speed SCSI chain a year or two ago. I am not aware of any problems on Linux which cannot be corrected without a reinstall of the OS, but perhaps there are exceptions in the crowd who can share experiences.

So... Win2k. Finally usable. But still not competitive.

To all knee-jerk anti-MS-criticism-on-slashdot and pro-MS trolls... if you're just skimming, now is the part where you hit reply and do your thing.

Re:Windows... better, but still not competitive

[be-fan]

I am not aware of any problems on Linux which cannot be corrected without a reinstall of the OS
>>>>>
Well, filesystem corruption bugs come to mind.

Re:Windows... better, but still not competitive

[ScuzzMonkey]

I've come to the conclusion that anyone who is still re-booting their NT4 servers every night for stability is pretty much incompetent, or relying on coders who are. There are just too many of us out there who are managing to keep the things up without doing anything of the sort, running rock-solid, for months and months on end--it's not a fluke. It's good management versus poor management, which I think you'll find is ALWAYS more of a factor than the OS when it comes to the stability of any box.

Similarly, as a relatively new Linux user, I'm plagued with niggling little problems that come up from time to time which seem to require a reboot to fix. I'm sure they don't; I'm sure I just haven't learned enough about what I'm doing to fix the problem properly. But I'm not going to lay it off on the OS just because I haven't done something properly.

It's not necessarily easy to get an NT box to run stably, and perhaps that's where there is an argument to be made against it (of course, I'm not finding it tremendously easy with Linux at the moment, either). But it's certainly possible. Any time I have had a server that's flaky, there has always been something that I can trace it back to that can be fixed--it might be an app that's running on it, it might be improper or incomplete patch installation, but there's always something. When you find that, and fix it, you can walk away and forget NT boxes as easily as any other.

Re:Windows... better, but still not competitive

[Anonvmous Coward]

"However, to put it in perspective, doing normal development with Java, VBScript, IIS, MS SQL Server, MySQL, Flash (I am deliberately excluding crashes that occured while coding C/C++ and other "non-safe" systems), I observe Win2k either bluescreening, spontaneously rebooting, or getting to a state where it needs to be power-cycled approximately 2-4 times a month."

Wow, I totally don't relate to your story heh. I have 3 engineers sitting around me, using Win2k, doing development, and not blue-screening. I've done .ASP programming and have never had a 'reboot the computer' problem, let alone a bsod. As a matter of fact, I've used everything you've mentioned except for MySQL and Java. Not a prob.

Without the chance to have a gander at your computer, I'd wager you've got yourself a hardware problem there. I'd be running Linux today if Win2k worked like that here. Come to think of it, the only auto-reboot or freezing that ever occured on my machine was caused by RealPlayer heh.

In any case, I think your situation is unusual. I assume you read about my experiences. I've worked with a ridiculous number of Win2k boxes and haven't had any problems worth mentioning. Hell, I've developed a nasty habit of not saving my files because I take my computer for granted. Stupid? Yes. But I'd rather be able to take my computer for granted and lose once in a while than have my environment teach me to be paranoid.

Re:Windows... better, but still not competitive

[DaveWood]

I don't assume such instability is an OS problem until I see it on a variety of hardware, which I have.

Nonetheless, I'm glad things are working out for you. The system is complex enough I'm sure rather subtle differences in usage patterns can be responsible for problems...

Re:Windows... better, but still not competitive

[DaveWood]

True, but this rather goes without saying.

Fortunately, on both NT4, 5, and Linux, I haven't seen unrecoverable filesystem corruption absent a hardware failure of some kind.

Re:Ada ?

[shaldannon]

I had the (dis?)pleasure of learning Ada as the required language in 4 years at Auburn University's Computer Science department. While what you say is quite true (from my observation) my two biggest objections to it were verbosity and strong typing. It's really, really annoying to have to convert, say, and int to a float through a function call. I'm not even asking for a Perl-style eval{} here...I just want the ability to declare something as an int with value 3, divide it in half, and reassign the value back so it is now a float 1.5....I also want the ability to get a newline without having to type in 'Newline;' or 'Ada.Text_IO.Newline;'. For what it's worth.

Until that time...I write Perl code all day long in web apps (nobody dies if your web app goes kaput).

Not unusual

[YrWrstNtmr]

As a former F-106, -4, -15 and -16 ground crew (Weapons) person, I can say this is not an unusual occurance. The F-16, for example, occasionally requires a reboot to some of the ancillary systems inflight. The SMS (Stores Management System) being probably the most needed.

Jet fighters operate in an unbelievably harsh environment. High and low temps, high G forces, vibration, etc, etc. It's a wonder they get it to work at all.

Slashdot fodder:
For maintenance, diagnostics, and troubleshooting, the groundcrew uses laptops. Armored, waterproof, etc. Plug it in, and the jet tells you more or less what is wrong. The maintenance manuals are all on CD. These laptops are running on...wait for it....NT.

Why not Linux? Because even if it is demonstrably more stable, the specs for the F-22 were laid down several years ago, when Linux was but a wet dream. Too late to change now.

This is nothing new, or overly scary

[sunking2]

Any plane flying that has a computer system on it has the ability to do a hard boot of its systems. Often these happen automatically with watchdog timers, but most have a manual reboot. Keep in mind that for hte most part this is solid state stuff, so system reboots are a couple of seconds tops. Also, just about every system has at least a temporay backup to keep things running while the main system is rebooting.

An example is the F18 Super Hornet. Correctly we're working on have the ability to drive the HUD display from the fuel control computer. It needs to be able to drive it for 7 seconds, which is the amount of time it takes for the primary and secondary HUD systems to reboot.

Say what you want about the military, one thing they do when it comes to their planes is provide backup systems. You can fly a C130 using hand cranks in the fuselage to control the avionics (couple hundred cranks to fully elevate the flaps).

Re:Reboot - a true story

[mborland]

We had zi small problem witz one of our computerz. But now we've rezetet it and everything seemz to be OK.

Heh, this happened to a friend of mine. He said that Airbus is more reliant on computers for some functions than other manufacturers...in his case they could not start the engine until they rebooted the computer. Needless to say, he didn't feel entirely assured about the safety of his flight.

That all said, I'm not aware of any reboots being responsible for aviation disasters.

Re:Ada ?

[SuiteSisterMary]

I just want the ability to declare something as an int with value 3, divide it in half, and reassign the value back so it is now a float 1.5

Holy CRAP.

Avionic OS's and Reboots.

[DracoPyre]

I haven't worked on the F-22, but I coded the Korean T50's OS and a new Navy IRaD FADEC.

At anyrate, the OS's aren't OTS, but designed and coded for each plane (Ada for all the military boxes). As for reboot, if the system becomes hosed, for any number of reasons, the Avionics will reboot. This is true in all aircraft, even your passenger planes.

They key thing to remember is that all of these systems are atleast dual redundant, meaning that the entire system doesn't reboot, just one channel. When that channel does reboot, the reboot is done in less than 200ms. (Usually faster).

This isn't like Windows where a reboot can take minutes, and you'll blue screen when it's finally running anyway. These are unique, tried and tested OS's, which operates with a Probability of Loss of Control around 0.3%

The risks of fly-by-wire: Crash Video

[LunarFox]

In 1988, a brand-new Air France Airbus A320 crashed into trees during maneuver at an airshow in France. The aircraft failed to gain height during a low-altitude pass with the landing gear extended. Three of the 136 passengers were killed.

The A320 was the first civilian aircraft to use fly-by-wire, which replaces conventional stick and rudder control with 3 computers and miles of electronic cables. The pilot uses a game-like joystick to his side.

Some good video of this accident is available here, among other places.

Ultimately, the pilot was blamed (when in doubt, claim human error). But you have to wonder what role the computer played in this crash, even if it simply confused the pilots or acted differently than they expected. Apparently, this wasn't the only A320 crash where its flight control system was suspected, either.

It's interesting to note that Airbus has a different design philosophy vis-à-vis fly-by-wire: they believe the computer should restrict the pilots from putting any undue stresses on the airframe, or doing anything that the system thinks is "unsafe". This is contrary to Boeing, who program their computers to allow even the most dangerous manuever, with the intention of giving the pilots ultimate control over the aircraft.

Re:The risks of fly-by-wire: Crash Video

[geekoid]

and that is exactly why the airbus crashed.

There was a DC-10 pilot who was in a situation where the only way to save the plane was to barrel roll it. The DC-10 is NOT designed to handle those stress, but it did, and the pilots quick thinking sved a plane full of people.
What would have happened if the computer say that it wasn't designed for that and stopped the manuever?

Now what happens to an airbus if the plane is already doing something it wasn't design for because od some outside force? it crashes.

Growth in complexity a problem?

[mikewas]

Embedded systems (70s) used to be a big loop with a goto at the end. A couple of libraries provided hardware interface. I've worked on projects (still flying) where the processor, instruction set, assembler, compiler, linker were an in-house design, so every detail was well understood.

Now we start with an OS that's many times larger & more complex than the entire application used to be. Often it's a proprietary OS that is executable only, but even if you get the source nobody has time to really develop an understanding.

Is this additional complexity making it easier to field an application but at the cost of reliability & usability? Have we gone too far?

BTW: I'm no longer in Aerospace, but still working on high availability embedded systems.

Nope, more like this...

[sterno]

MS Support: Thank you for calling Microsoft. Your call is very important to us. Your call will be answered in the order it was recieved.

F-22 Pilot: #$@@#%%(@!!

MS Support: o/~ The girl from iponimia dah dum dee dee. Duh dum dum dum da dee dee dee dee... o/~

BOOM

If it was Linux, it wouldn't crash but the pilots would constantly complain about how ugly the fonts were on the display.

Updating Star Wars (again).

[Treeluvinhippy]

Right before Luke blows up the Death Star.

"Luke, you've turned off your targeting computer. What's wrong?"

"Fucking Windows, that's what's wrong! Now I gotta use the force!"

Re:F-22 BSOD...

[stilwebm]

You have to find a paperclip, the straighten one end to fit it in the small "reset" hole on the side of the console.

Embedded World

[drxenos]

You can tell from the comments the number of people who never worked in the embedded world. You can not apply PC design methodologies to an embedded system. In the embedded world, the software must be fault tolerant. If must not lock-up; if must always reboot. Embedded Engineers know and except that ALL software has bugs and ALL software will eventually crash. In the event of a crash, the computer must never lockup; it must recover. And while its recovering, a backup computer must take over until the primary computer is up and running again. As for Ada, you write just as crappy code as you can in any other language. As strongly typed as Ada is, it will not save you from yourself. A bad programmer is just as bad in Ada, as he would be in C. Worse, when that bad programmer forces Ada to use "pointers," they will always be functionally equivilent to void* and contain no type information at all. Why would he do this? For the same reason his code is littered with "use at," he is a bad programmer.

Re:Why C?

[Erich]

People act as though C and C++ are the top of the language evolutionary scale--sheer nonsense. C and all of the "C-alikes" have held back decent software engineering now for decades...we get to enjoy buffer and stack overflows, pointers wandering through address space and other idiocies.

You act as though C is responsible for a stack overflow or pointer pointing problems.

You wanna know something: IT'S THE PROGRAMMER.

You can write huge applicatations in plain ANSI C. They can run flawlessly. As long as you use good programming practices and have good programmers.

Excepting buggy compilers or libraries (very rare in my experience), when you write something in C and it doesn't work, it's your fault. C is very simple, elegant, and deterministic. For examples of C programs that work very well, see UNIX OS kernels, most of the system tools on UNIX, and especially TeX.

You can write perfect programs in some "more modern" languages ("safe" languages like Java) that will crash, because the environment is so complex that many environments are buggy. This is unacceptable. Not only that, most of these languages aren't any better than C as far as memory management (That's why all the Java programs I see crash with "NullPointerException").

These new languages, however, do increase the overhead of a program running, to make things slower. As a computer engineer, I do like that feature, as it means that people will go out to buy more complex hardware.

There are some programming languages that really do have features that help write very very stable, unbuggy code. I would say ADA, ML, and LISP fall in these catagories. But even in these languages, the language can only do so much. In the end, your program will only be as good as your programmer.

We STILL live in the dungeon of ancient functional thought. And sadly, attitudes like yours ("why not just use C?") help promote this.

Actually, we have gotten out of the use of functional languages like LISP and replaced them with procedural languages like C. Which is good! That's what your computer does anyway. Though most functional languages do a very good job of implementing themselves in a procedural system... stacks are pretty simple things.

But I bet you're one of those OO people. You think that OO is the greatest thing and that if everyone used it to write their programs, the world would be a fantastic place.

There's a place for OO languages. They do some things well. Some things they do very badly. And in the end, OO languages are still only as good as the programmer. And they have enough problems and complexities that for things like flight control, they aren't always appropriate.

Let me tell you a little story. There was once a class that was trying to make a robot arm play ping-pong. There was a camera that could see the ball, and then the software computed where the paddle should be, then was supposed to move there so that the ball would return to the other side. The software was written in a "safe" language.

When they went to test the robot arm, the ball flew straight past it. The arm didn't budge. They looked at each other, wondering what the bug was, until a few seconds later the arm moved to where it should have gone.

The problem was the environment. After doing the complex computations, the garbage collector decided it needed to clean up all the memory used for the calculations. Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.

And to finish off, let me tell you the one thing that bugs me about most languages: THEY DON'T HAVE BUILTIN MACRO PROCESSORS. Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.

Pilot bordom

[GMontag]

Actually, this feature was added when the pilots complained that all of the fly-by-wire crap, and other workload reducing measures, left the pilot with nothing to do but sleep and shoot.

Nothing better to keep a body alert than the dark cloud of a fiery death ;-)

Re:Ada ?

[foobar104]

First, read Kysh's comment. It's better than mine.

But the short answer is that it's possible to compile a Java program that will exit due to an uncaught exception. For many exceptions, Java forces you to have an exception handler, otherwise the code won't compile. But not for all. Runtime exceptions can send your code straight out the window.

The idea behind Ada-- I've never done much Ada programming myself-- is that it's not supposed to be possible to compile code that can throw an uncaught exception. The compiler is supposed to prevent you from doing such a thing.

This doesn't mean that Ada code is always perfect, but it does give you a degree of freedom that you don't get with other languages.

I did some work about four years ago on a flight simulator project for the DoD. The first stage in the project was to build an unclassified demonstration version of the new sim. Some code related to weapons-- in this case, the AIM-120 missile-- is classified, and can't be demonstrated in an unclassified environment. So what did we do? We just didn't link in that code. (I may have my terminology wrong; I was doing HSI, not code, so I'm just going by what my friend on the other side of the hall told me.)

With any other environment, C or Java or whatever, that would have resulted in a fatal runtime error. But Ada doesn't let you have runtime error situations without exception handlers, so when it encountered the missing chunk if AIM-120 code, the sim just dropped into the exception handler-- which basically said, ``never mind, everything's fine''-- and kept right on going. The sim dropped a couple of frames every time you fired a missile, but other than that, no problem.

I've gotta say that I found that pretty cool. I mean, the sim just kept on going, after it found that a huge chunk of important code was simply missing! Neato!

Slight difference - These reboots are much faster

[deranged unix nut]

I went to a talk recently where a researcher was explaining human factors applied to military jet aircraft. The explanation that he gave of reboots in these systems was a 1/10th of a second or less pause - the pilot pushes a button to say "No, the computer has it wrong, it is giving me a different display than I need, reboot and give me the default display again."

A "personal" computer reboot takes > 30 seconds nd would be unacceptable. These reboots are near instantanious.

(I could be wrong, maybe this is a different aircraft and a different type of reboot than the researcher was talking about.)

On Debian? Probably more like:

[Just Some Guy]

pilot@airplane:~$ su -c "apt-get install ejection-seat"
Reading Package Lists... Done
Building Dependency Tree... Done
Package ejection seat is a virtual package provided by:
ejection-seat-gnome
ejection-seat-gnome2
kseat
gtk-seat++
qteject-o-matic
ncurses-eject
ejection-svga

...all requiring about 31MB of dependency downloads (or 187MB for ejection-seat-gnome2, which may break 'parachute-gnome') over your 9600bps link.

Re:There Is Something Rotten in Software Engineeri

[alienmole]

Pure computer *science* programs are more commonly associated with pure math departments than with engineering colleges. The typical computer science curriculum deals with many topics that have little or no current application in real-world engineering, including things like quantum computing, computability theory, and even things like lambda calculus and type theory, which may arguably be applicable in the real world, but in practice often tend not to be, today (since almost no real world code is written in languages with theoretically sound type systems, and applying theoretic type system analyses to commercial languages can be a relatively futile exercise).

Engineers build real systems, and as such have to deal with all sort of outside constraints which are usually not considered in pure computer science curricula: the compromises introduced by tight schedules and limited budgets, unreasonable feature requests from marketing departments, etc. In general, having dealt with both camps, I've found that the "scientists" often dismiss real-world concerns on one of two grounds: either they're not theoretically interesting, or they're too theoretically complex to be realistically addressable. Engineers, OTOH, don't usually have the luxury of picking and choosing their battles like this. Engineers often dismiss pure theory on the grounds that it is insufficiently applicable. I have seen a number of cases where I don't think they were correct.

Last time I checked, the only difference between computer science and computer engineering was that the engineers are more geared towards building processors and integrated circuits whereas scientists are preped for software design.

"Engineers geared towards building processors and [ICs]" are hardware engineers. People "preped for software design" could be either software engineers or computer scientists. In fact, software design at the level of UML diagrams and the like is more likely to be covered in a software engineering-oriented course than in a pure computer science course - since it's not really a topic of interest in the pure computer sciences, having more to do with human factors and communication than what is mathematically provable or computable.

Of course, many curricula involve some (not always rational) mixture of both science and engineering, which in part reflects how new the entire discipline is - it will probably stratify even further in future.

Re:There Is Something Rotten in Software Engineeri

[RobinH]

only one person should be writing it

Which works well, unless you subscribe to the extreme programming paradigm. In that case, you're never supposed to have a single programmer working on the code - always two there are...

Re:Ada ?

[arrow]

Dosen't Javas licence agreement specificly forbid its use in nuclear power plants, dams, weapon control systems, etc.?

I can't find good linkage to the discussion I remember, but heres something close: The Java2 Plugin licence (http://java.sun.com/getjava/license.html) states "You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.".

A skeleton from the closet

[leonbrooks]

Never believe anything that starts with `of course'.

nobody would credibly assert that any of these 'interactive user-oriented' OSes are suited for that kind of high speed real time operation.

You wish.

That's what embedded controllers are in the mix for. Often tightly interfaced to a slower responding system that supervises everything.

Consider the USS Yorktown. I doubt the turbines were supposed to be running at jet speeds (frankly, the tip velocity of a ship-sized turbine cranking to those RPM is a frightening concept) but since the boat was sail-by-wire, when the Windows supervisory machines (and maybe `embedded' systems, we've all seen WinModems, we've all heard MS touting XP as embeddable, sorta) went down, it really didn't make any difference how close to the metal the failure was, that baby was a sitting duck for hours.

Now, if my F-22's display and controls go dead because of a display manager failure, am I any happier than if they go dead because of an engine failure or system-wide failure?

I guess I'm marginally happier than if the wings had simply fallen off, but only for a few more seconds. High in a clear sky, probably not a life-threatening issue provided that reboot is fast.

In combat, takeoff or hedge-hopping situations, not so good.

Very good reason not to use Java:

[marhar]

From the Java License:

"Software is not designed or licensed for use in on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility. You warrant that you will not use Software for these purposes."

wrong definition of stall

[Preposterous Coward]

A stall is where the plane flies too slow, the wings no longer produce enough lift to keep it in the air, and the thing basically just drops out of the sky.

Well, no. A stall occurs when the wing exceeds the critical angle of attack. It can occur in any configuration (nose up, nose down, etc.) and at any speed. The problem is not lack of speed, it's the fact that the excessive angle of attack causes airflow separation across the top of the wing, which results in loss of lift.

As for the thing basically just dropping out of the sky: Also incorrect. In most planes recovering from a stall is a straightforward maneuver, and stall execution and recovery is part of basic flight training. Of course, if you're only a couple of hundred feet above the ground when you stall, you might not have time to recover. The other potential danger with a stall is that if you're flying uncoordinated at the time, you can get into a spin, though in most aircraft spins are also recoverable given sufficient altitude. Flat spins, such as the one depicted in "Top Gun", can indeed be a problem because the aircract lacks rudder authority in that situation, and rudder is important to stall recovery.

Re:wrong definition of stall

[Grab]

OK, OK. I'm a hang-glider pilot myself, so I do know the specifics. But I'm not about to post all that in reply to someone who's first language isn't English. :-)

You're right, stall recovery is straightforward, but it does require the room in which to do it. Dropping out of the sky is only the start; on my hang-glider, once it's started dropping, the nose goes down and the speed goes up, and it starts flying again; on more serious aircraft the pilot hits extra power and/or controls the pitch to recover; but you need a certain amount of space below you for this to take effect. Hence stalls at low level (eg. that DC-10 accident on takeoff) usually make a bit of a mess.

Grab.

Why java cannot be used in a realtime environment

[rebelcool]

2 words: Garbage collector.

The garbage collector in java is an asynchronous type. This means while it is running its collection procedures (which can begin at any time, there is no way for the programmer to control this), processing of the program code halts.

I had a professor which demonstrated the problem of this in a simple example. Suppose you are designing a robot which can climb and descend stairs. It must monitor sensors and adjust angles of its joints appropriately to go down (quite difficult, really). Now suppose the GC runs halfway through the middle of a step. All processing stops, gravity takes over, robot falls down.

Same goes for avionics systems, if you're landing a plane, you don't want your HUD display to suddenly freeze as you're descending at several meters per second. You'll descend straight into the ground.

Hence the reason java puts a clause in its license about no use in safety-critical applications.

Re:Ada ?

[_xeno_]

It is possible to let an Exception cause a Java application to "crash", although it usually exits fairly cleanly, or, if the exception occured as the result of an event in a GUI, just continue on it's merry way, with the given function having been aborted.

The Java compiler forces people to catch any Throwable that does not extend either Error or RuntimeException - assuming that the given exception is noted in the throws clause of the method it's looking at. However, as far as the Java runtime is concerned, any exception can be ignored. (So if you managed to compile against classes that claimed not to throw a given exception and link at runtime against code that does, an uncaught exception can wind up "crashing" the program.) An ignored excpetion just propagates up the stack (well, the stack of called methods), until eventually it gets caught by the root exception handler in java.lang.Thread.run(), which simply dumps the stack trace and then destroys the current thread - in essence, causing the application to "crash", although it's really just an uncaught exception.

To prevent that, just

try {
// your code
} catch (Exception e) {
// Either fix it, or restart, or something
}

Generally speaking, Errors should not be caught because they're basically signs of the underlying system getting ready to go out the window. (Except for StackOverflowException which is usually a sign of unchecked recurrsion...)

Oh, and you should add something to your list of problems - the completely inconsistant and confusing versioning numbers that Sun uses.

Since as you do complain about the fact that Sun uses Java to mean both the language, virtual machine, and class library, the Java version number is just plain confusing since it applies to all three.

As an example, when Java went from version 1.0 to 1.1, there were several changes to the language (the addition of inner classes), several changes to the API (a new AWT event model), and changes to the JIT technology backing the virtual machine. This pales in comparison to the absolutely stunning Java 2 release.

See, when Java 1.2 was released, half the documentation called it "Java 2" - which is understandable, since there were many additions to the default class library (Graphics2D, Collections, Arrays (which adds the qsort that was missing, BTW - it's java.util.Arrays.sort(java.lang.Object[]) - oh, and because Object[] isn't the same as int[] etc, they have special copies of the method for byte[], char[], double[], float[], int[], long[], short[], and of course, Object[].)

Java 2 - or Java 1.2 - also saw the default JIT be changed to the HotSpot JIT. I think Java 1.3 changed the compiler, as well as adding new classes, and 1.4 changed the language to add an assert feature - involving another change to the compiler...

Anyway, I still do write Java as my day job, and it's nice to get that off my chest... ahhhhh...

Re:VxWorks reboots VERY fast

[mikewas]

The fact that delays are deterministic is what makes an OS real-time. It doesn't have to be fast.

Speed to reboot doesn't just depend on your particular RTOS, it depends what portions of the OS you've linked into your application, and your custom drivers, hardware to initialize, perhaps synchronization with other equipment. There can be tremendous additional delays before a system actually boots, but it's still real-time.

Finally, there's nothing that says the same OS is used everywhere. I worked on a board that was an upgrade to an existing system. It ran one OS, a daughtercard designed at another facility used a second OS. The shelf it plugged into used yet a third OS in its packs.

Blackbird confetti

[leonbrooks]

If you let the SR-71's engines get wildly out of sync (say, pop a nose cone) the time from hale and hearty airframe to very expensive and very small confetti is about twenty milliseconds.

It wouldn't surprise me to discover that the F22's case was similar, ie, control system death becomes unrecoverable situation or structural damage in tens of milliseconds. The thing basically looks like a large set of anti-turbulence vanes with a fuselage holding them together, and probably wouldn't take kindly to an actual stall.

Whatever

[DaveWood]

What if that app you're running is ISS? Or SQL Server? Or Exchange? Or another of the other Microsoft solutions, system services, patches, service packs, or other miscellany? But I suppose that's the "relying on coders who are [pretty much incompetent]" part you mentioned.

I'm very familiar with both sides. If you're open-minded enough to try, when you finish learning how to administer Linux, you will find it far more stable and maintainable, and the set of tools you'll use on it an order of magnitude more secure and reliable, than Win2k. _Let alone NT4._

I'm convinced the people who still run around touting NT4's reliability are either incompetent or not tasked with any particularly complex applications involving microsoft tools or both, not to mention not reading the news... Remember the hotmail disaster? And that was Microsoft's own team.

Re:Whatever

[ScuzzMonkey]

Eh, well, I guess that proves my point. I have no trouble maintaining stable production environments with Exchange, SQL Server, or IIS (not using ISS, myself--not sure if that's what you meant or just typoed). So the question is, what are other people doing wrong with them? I don't exempt Microsoft's coders from the incompetent category, but if I'm able to run these things out of the box without re-booting nightly, you should be able to as well. They have to be used in complex applications? Not a problem--some testing, a good dev crew, and a basic understanding of the software can see you through just about anything. Whether MS tools are the most efficient for a particular application may be debatable, but I don't consider it seriously in question that they are capable of accomplishing it when used properly. Anyone who does, I don't think really knows their stuff as well as they ought to. As I said, this is not about which is easier to use or better suited for a particular task--just whether or not it's possible.

I have no doubt that you're quite correct about Linux. One may be better than the other, but as I said, by far the greater factor is who is doing it, not what they are using. I'm totally disinterested in starting an NT/Linux debate--I don't have a side in it, personally. Tools are tools. But I consider the "NT is unreliable, ya' gotta reboot it every night" to be just another example of FUD in a debate that is replete with such.

Re:Whatever

[DaveWood]

I appreciate your civility and open-mindedness.

When you say "but if I'm able to run these things out of the box without re-booting nightly, you should be able to as well" I must respectfully disagree with you, simply because of all of the diverse things one does with each of those three products (I did mean IIS, apologies). My experience, as I said, has been unequivocal. Both firsthand and 2nd hand, watching some extremely bright people with excellent familiarity with the product suite, I have come to expect NT4 production environments to be tainted by disaster (often repetitive disaster), where I have observed and participated in complex Linux rollouts with a significantly superior track record. You must decide whether or not you think me honest or my judgment sound, but I am certain on the point.

To your comment about "ya' gotta reboot it every night" being FUD, I can only once again respectfully disagree; I have heard this exact statement from a number of (apparently) competent professionals responsible for major IT efforts in the fortune 500, and if I were able to name names, I'm sure you would be familiar with at least several of them. I, too, took it with a grain of salt until I observed its necessity on projects of my own using NT4, IIS and SQL Server, and more than once. Older versions of IIS and VBScript just leak like crazy and that's the beginning of their troubles. Fortunately, my experience with my Microsoft-or-death clients has improved under the Win2k regime.

I am not making this stuff up. It is not rhetoric, but actual repeated professional experience. I should perhaps add "painfully" repeated.

Are you not aware of Microsoft's spectacular failure while attempting to migrate hotmail from Solaris to NT4, IIS, and SQL Server? This is often my case-in-point when discussing building large applications with NT4. I understand that they did stick with it and eventually got it going with Win2k.

Re:Whatever

[ScuzzMonkey]

No, I believe you completely, and certainly would not dispute your personal experience. My point is rather that my experience, and many others with which I'm familiar, disproves the theory. For every story like the Hotmail transition (which did sound pretty ugly, but I'm not all that familiar with it) you can find another like Nucor or Verizon where everything worked fine, using the same products. When I worked as a consultant, many times I too would go into a business and find IT staff stating the same thing you have--they had to re-boot the servers every night to get any stability out of them. Invariably, with a bit of perspective and often some patching, we were able to address the root issue and remove those stability problems.

If that many complex projects can be undertaken successfully using those tools, I think that pretty squarely disproves the instability question--personal experience aside. As I said, I'm having lousy personal experience with Linux at the moment, but I hardly think it reflects on Linux. You seem to be drawing the conclusion that because people you know can't get a stable NT4 installation going without nightly reboots that NT4 is crap and requires such--but the fact that anyone else is able to make it happen without doing that should be enough to tell you there is something wrong with the implementation, not the software.

And again, I'm not trying to start an NT fan club here--it has pluses and minuses, and is not the ideal tool for every project, no question. I'm simply saying that if it's possible for a large number of people and businesses (even if not a majority, although I suspect they are a silent majority) to run complex apps on these products without scripting re-boots every night, then the people who ARE doing that are most likely doing something wrong. I'm sure they don't like hearing that... but it doesn't at all change the logical conclusion.

Re:Whatever

[DaveWood]

I thank you for continuing the discussion. However, I again respectfully cannot agree with your conclusion; no theories are proven or disproven by these anecdotes or assertions; in fact, in the face of anecdote, it is generally wiser to give more consideration to negative outcomes. Whether a system is poorly documented or organized and hence requires some magical patching and tuning (which in the case of many of the projects I observed, even Microsoft itself was not able to supply) in order not to require nightly rebooting or to scale as it has been advertised to, or whether it is simply irretrievably broken for certain tasks, that is not a system you want. If NT4's success is as we rhetorically suggest is 50/50 or 33/66, that's terrible. But of course such numbers are meaningless - this is only to attempt to illustrate my point about anecdotes.

The thing that really troubles me about this conclusion is that application platforms like IIS and SQL Server are not like Photoshop or Sendmail. They're not special-purpose; they will be used to do a wide variety of jobs, each potentially drawing on another relatively small set of a vast feature library. If some people get them to work and others don't, it is just as reasonable to conclude, not that because it works for some that the others are incompetent, but that the system is broken but that not everyone's applications are equally unlucky in how they encounter the bugs.

Really your implication seems to continue to be that if I have had these experiences, I and those I am referring to are simply not as good at running NT as you are. There I suppose we have little chance of discovering the truth. :) Fortunately, there is not much at stake in the NT4: good or bad? argument anymore. :) I have nonetheless appreciated your points, and agree there are certainly many problems on both platforms that are attributable to failures to use the system correctly, yet blamed on the system itself.

Re:Whatever

[ScuzzMonkey]

I suspect that we're going to have to agree to disagree. I can agree that these theories cannot be proven by anecdotes, but certainly believe they can be disproven by (documented) anecdotes. Stating that that NT4 has to be re-booted every night to get stability beneath a complex application is just patently untrue; even one exception disproves it.

I think you get more to the heart of the discussion when you address how difficult it may or may not be to make the system work as you expect. How easy it is to get a given product to do what you need it to do is highly relevant--and as I've said several times, I readily agree that NT is not the easiest or best platform for every job out there. In that sense, people who are trying to shoehorn it into these impossible projects that you are citing are perhaps not to be faulted for their skill with NT, but rather for their decision to use it in a place it's not best suited for--or working for numbskulls who insist on it in the face of advice to do otherwise. :)

It's also, as you say, difficult to compare apples and oranges, as we're not getting into the specifics of what these various projects require of the applications. But I will say that with technology, there is always more than one way to accomplish any given task, and if one route happens to be bugged to hell in NT, I don't doubt there's a different way of getting there. Again, that doesn't speak to the efficiency of doing so--just that it IS possible.

And because of that, I'm not trying to imply that I'm the uber-admin or anything--I just have an approach that has worked well for me so far, so that I have not had the experiences you have had--or rather, I have, but have been able to address them to my satisfaction at some point. I've been in this game far too long to have any conceit as to my own technical prowess. :) I do like to run stable systems, though, because I like to have time to sleep and surf Slashdot, and from my observations, it's that inherent laziness that drives me toward stable solutions, rather than cutting edge or shoestring solutions that seem to be popular in the rest of the industry.

At any rate--thank you for the conversation. It's rare to find someone to have a coherent one with around here these days, and I appreciate it.

kill -9

[leonbrooks]

Ah, so if I want my program to recover from a `kill -KILL' I need to write it in Ada? (-:

Ahem. Pascal!

[fm6]

Jeez. That page says that Packages "was not a feature of Pascal". OK, first of all, Pascal is not a past-tense language. It's alive and well. Second of all, every Pascal implementation I know about supports Packages.

Re:Ahem. Pascal!

[sysadmn]

Second of all, every Pascal implementation I know about supports Packages

That's the problem, mate. It wasn't (isn't?) in the language specification, but every implementation supports it. Slightly differently...

Re:Ahem. Pascal!

[dvdeug]

Packages "was not a feature of Pascal" at the study was done. Packages was not and is not part of ISO 7185 - Basic Pascal. ISO 10206 - Extended Pascal wasn't standardized until 1984, after the study was done and the military had picked a language. And honestly, to this day, Extended Pascal is not a commonly used language; various compiler-specific extension sets are used instead.

This reminds me of...

[fm6]

...an old joke. I once knew a guy who worked at Ford Aerospace. This was back when anti-lock brakes were still in their research phase. I asked him when they might go on the market. His response was that he had too little faith in software to rely on it to stop his car. His exact words: "It brings a whole new meaning to the halting problem!"

Re:There Is Something Rotten in Software Engineeri

[Gleef]

Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature.

What are you talking about? Algorithmic systems are by nature consistent and stable. Inconsistancy and instablity are not caused by the algorhithms, but rather by

• the fact that we have largely moved away from an algorithmic model to an event-driven one, which is inconsistant and unstable by nature.
• Program states used to be simplified representations modelling reality (or fantasy). They increasingly base their state on raw reality. It doesn't matter how predictable an algorhithm is if you can't predict the state getting fed to it.
• Due to a combination of both laziness and overwork, as well as a preponderance of reinventing the wheel, most algorhithmic software-based systems use too much code that's too poorly tested to even dream of reliability.

Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage.

Jaquard also used algorhitms for his software construction, before Lovelace and Babbage.

Just because something is old doesn't make it bad, using the wheel as the basis of long distance land transportation is an ancient practice pioneered by someone who lived so long ago she isn't even recorded in the history books, that doesn't make wheels obsolete.

It is the fundamental reason why dependable software systems are so hard to produce.

The problems in producing dependable software are far far more complex than "we still use algorhithms", although clearly one of the problems is "we use algorithms where they are inappropriate". Algorithms work best where the computer is interfacing with mathematics and other abstract concepts, they work worst where the computer interfaces with the real world.

There is something rotten at the core of software engineering.

How can something that barely exists be rotten already? Software engineering has reached the terrible two's, it can (usually) feed itself, but it still runs around knocking over lamps.

Software functionality should not be fundamentally different from hardware functionality.

Huh? Most software has just the most cursory relation to hardware, it makes no sense to model such software after hardware. What would the hardware model be for a hypertext browser, for example?

Software should emulate hardware and serve as an extension to it. It should only provide the two things that are lacking in hardware: flexibility and ease of modification.

This statement only makes sense if you define "flexibility" far beyond its typical semantic meaning, as in "we don't have hardware that's flexible enough to draw an arbitrary projection of an arbitrary eight-dimensional surface" or "we don't have hardware flexible enough to perform statistics on multimillion element databases".

Even stretching the statement to make some sense, it's still false, since it ignores many things that software has that hardware lacks: zero capital cost, ease of replication, ability to ignore or rewrite natural laws. Tell the people writing software for ASCI White that their work should be an extension of hardware and they'll look at you as if you've got pink elephants on your head, the whole point of that computer is to avoid using the real hardware.

The only way to solve the reliability crisis is to abandon the bad practice of using algorithms as the basis of software construction and to adopt a pure signal-based paradigm.

I dare you to write a GAAP-compliant accounts payable system for a typical mid-sized corporation using a pure signal-based paradigm. I'm not saying it can't be done, but you will quickly see the advantages in software reliabilty and development productivity in using an algorithmic model over a signal based model when the purpose of the program is to follow a set of number crunching algorhithms.

The only way to solve the reliability crisis is to abandon the bad practice of using algorithms as the basis of software construction and to adopt a pure signal-based paradigm.

Abandoning algorithms won't "solve the reliability crisis". One important step towards improving reliaibility is making sure to use the right tools for the job. If you are writing a program to crunch numbers, algorithms are the best tool that I know about. If you are writing a program to control hardware, signal-response systems often make much more sense.

Even using these two paradigms you won't always be using the best tool for the job. Another potent tool is one of Mother Nature's favorites, the paired analog response system, where you have two (or more) complimentary analog systems (for example: the insulin/glucagon system to control blood sugar levels, the force/friction system to control accelleration). Signal-based systems can simulate this, but it can't match the precision of the truly analog processes.

More details can be found at the links below: Project COSA

Very very interesting work, I just see it more as complementing algorhithmic systems rather than replacing them. I see your work as particularly relevant for embedded systems (eg avionics systems like the story is talking about).

Note that, while your COSA system does handle events (signals) more predictably than most other programming paradigms, and it encourages more relaible code in response to the signal, it does not completly eliminate the two reliabliltiy problems I listed at the top.

To use your terms:

• You can't predict in what order sensors will trigger, making it possible to have unexpected effects when sensors trigger in an unexpected fashion
• Digital data and comparison sensors will never allow for a perfect decision to be made regarding analog reality.

I can't see a digital signal-based system getting away from these fundamental problems, the best you can do is come up with tools and methods that minimizes their effect.

One other thing: You haven't gotten away from algorhithmic computing. I assume the algorithmic kernel is just expediency, it's cheaper to model COSA on an algorithmic computer than to custom design the right hardware. However, your descriptions of the operation of cells are all algorithmic, so the fundemental unit of your system is a handful of algorithms (granted, they're small reliabile-looking ones, but they're still algorithms).

RTFM?

[Hektor_Troy]

I've never really understood the sentiment of RTFM. I mean "Read The Fucking Manual"? I have read the Kama Sutra, and I fail to see its relevance in computing.

People still use ADA?

[ColGraff]

I thought it had been phased out, even in the military. Is there really any advantage to it, compared with C++?

Re:People still use Ada?

[dvdeug]

Is there really any advantage to it, compared with C++?

Feature-wise, Ada has fixed point numbers and multitasking built in. Style-wise, Ada has strong typing and tends to raise exceptions where C++ would crash or start working with garbage (i.e. bad pointer or buffer overrun.) It's also rarely requires the use of pointers, instead letting you pass arrays, or pass stuff by reference. Aesthetically, I find it a more enjoyable language to program in than C++.

Re: War Machine

[Embedded Geek]

The Swiss (whose military expenditure per capita match the US) have a saying:

Every country has an army in it. We just figure it might as well be ours here.

Re:There Is Something Rotten in Software Engineeri

[fizbin]

The problem is that you read the moderation system the wrong way. Think of a high score not as "this is something that is true" but "this is something worth discussing, if for no other reason than to refute it".

Of course, naming the moderation as "insightful", "interesting", etc. doesn't help things.

Re:Ada ?

[WinterSolstice]

Try doing things as a power of 10, then. (ie int x = 10 would be equiv to x = 1, but with the ability to do limited float.)

This way, you would declare x = 30, x = x/2, and bingo, x == 15. (or 1.5, you see.)

Also, you get to avoid some nasty traps that can occur with floats in double-digit precision systems. (Like financial, for example.) You don't have "loose change" floating around.

-WS

Re:Why a reboot - Osprey reboot...

[Locutus]

If I remember correctly, one of the last Osprey's to go down and kill a number of marines was due to an inflight reboot. IIRC, the pilot had a system error and rebooted but the system startup defaults were not designed to maintain flight. The in-flight reboot either was not designed for being in-flight or there was a serious hole in their QC process.

Either way, $billion flying machines which rely on so much software to fly, should have some low-level boot-kernel-like software to keep the bird flying when bad things happen. Or birds failing from the sky due to BSOD could get soo common they'll have a TV show about it...."When Bytes Attack"

Remember, a redundant system isn't much good if it too has the same software failure.

LoB

Re:I had to say it...

[Ian Wolf]

"sementation fault"

Dude, that is one hell of a freudian slip. Try Viagra.

Fly Ada!

[Anonymous Coward]

I'm one of the few software engineers to have flown in an aircraft that was using his/her own code in the flight control systems. The Shuttle Training Aircraft flight software was written in Ada (83). I had the pleasure of flying on the STA during a training flight.

Ada95 (it's not ADA, it's a name not an acronym) is a language that will never become popular to the average programmer because the compiler won't let them do a lot of the very (unsafe) things that they rely on in other languages. This is the stuff you always read about...

The tools that an Engineer use are very important! You could build the F22 using only slide rules but I wouldn't fly it! You could even write the flight control system in C but by the time the process made it as safe as the Ada program. it would be out of date. Good engineering can happen in any language, Ada helps the process, C,C++ hinder the process)

Writing the flight control software in a language (tool) like Ada makes the end product more reliable and predictable because of both the compile time and run-time checks. I can make just about any Ada code execute as fast as C if I get rid of the run-time checks. Even then Ada is much better then C/C++ because of the compile time checks that C/C++ lack.

Writing software is an art and a discipline. most programmers forget the discipline part.

Re:There Is Something Rotten in Software Engineeri

[gmarceau]

The biggest engineering difference between software and hardware is that people find software errors acceptable, or even normal, whereas they have never reconciled themselves to, say, collapsing bridges or wings falling off of airplanes.

Or more to the point, building bridges is hardly ever self-though as a hobby. In comparison, software engineering is possibly doomed at forever rewriting ideas which are short, simple and wrong.

Also, since most software cannot be returned for refund, even if ridiculously defective, hardware shops have that extra highly non-trivial financial motivation for double checking their work before pushing it out.

There is also a marketing problem.

It's all detailed in my report

Re:I had to say it...

[geekoid]

did you ask him if it would crash without gravity?

Re: Ada Programmer

[Black Parrot]

> Noway does Ada help avoid bugs by being a type cast unless your talking about the stupidest little bugs imaginable.

Unfortunately, stupid little bugs find their way into operational programs. But if you have a compiler that can catch them at compile time, they don't find their way into the operational program. End of story.

Also, notice that for a given programming team the number of stupid little bugs will be proportional to the size of the code base, and for 1.5MLOC that generally translates to a lot of stupid little bugs.

> ADA LACKS the debuggers and useability of C.

I used the VAX debugger with Ada [sic] over a decade ago. For OSS fans, there's GVD, the GNU Visual Debugger, with full Ada [sic] support. Don't let your prejudices lead you into making uninformed assertions.

(BTW, GVD supports C and C++ as well as Ada, and is designed to allow plug-ins to support additional languages, so give it a try if you're a C or C++ programmer and would like to have a visual debugger. I believe it's built on GDB, so its basic operations may already be familiar to many.)

> Its a hard painful language to use and learn and isnt as tried and true as C.

What is your unit of measure for "tried and true"?

> Also Im sure you can get 1.5 million lines into 1 million if you use C.

Are you sure about that? Ada [sic] does require rigorous type definitions, but once you've made them it often lets you program at a very high level of abstraction.

Please save the FUD for audiences that are unfamiliar with the subject matter.

Re: Ariane 5 was written in Ada

[Black Parrot]

> Consider the fact that the code for the Ariane 5 rocket which crashed [eiffel.com] because of a software problem, was written in Ada.

If you search the Web you should be able to find the official report on the cause of the crash. I read it on the Web a year or two ago, but didn't bookmark it.

Short version: it wasn't the choice of language, nor even a software bug at all.

Intermediate version: For economy, the A5 engineers decided to re-use a sensor/controller hardware unit from the A4, since it and its associated software had worked flawlessly. Unfortunately, they did not review that part's specs carefully enough, because the A5's more powerful engines generated a thrust/acceleration/velocity/displacement that was outside the part's design spec. During the flight the part determined, correctly, that whatever it measured was out of range, and started dumping debug data on the rocket's control bus - exactly as it had been designed to do, but with unfortunate results when it happened in the sky rather than on a workbench.

The software worked flawlessly. The design sux0red.

> I am not trying to dispute that Ada is a good language for critical safety related software... but it is only as good as the people and methodology/process being employed.

That is indeed true. However, my experience in using Ada is that it completely eliminates whole classes of bugs by catching them at compile time, so the only bugs I get are those related to the basic algorithmic design of my program.

In general, Ada will catch things at compile time that most languages will only catch at run time, and it will catch things at run time that in most languages will only be caught if someone notices that the output is incorrect. Think about that next time you're debugging a program.

Re: Ada ?

[Black Parrot]

> My biggest peeve about Ada, which I believe MAY have been corrected since, was that it didn't directly support variable-length character strings.

As poster "Ada95" has already said, that 'feature' of Ada83 has been modified in Ada95 by the addition of two more classes of strings, bounded and unbounded.

> That's something I also hates about what's called "Standard Pascal" which makes you use fixed-length character arrays. Are we still stuck in the days of Fortran? Did these language designers never consider that one might want to perform string manipulation that resulted in a length not predicted at development time?

I agree wholeheartedly. IMO it was clever to think of a string as an array of char, but the concept was fundamentally flawed. Strings should be conceived as a natural data type with their own natural set of operations, not as a funny kind of array.

Re:Ada ?

[shaldannon]

*sigh*

that doesn't work so good if you are trying to divide 1 by 3, for example. Besides which, that's a hack anyway. The whole point is that Ada makes the doable stuff hard and the hard stuff impossible (rather the opposite of Perl). I guess my whole philosophy of programming boils down to "do it the easiest, and most easily documentable way." I don't do hacks, understand, but I see nothing wrong with

• print (defined $_ ? "True" : "False") foreach (qw { 1 0 1 0 });

if you get my drift...

Re:Ada ?

[markmoss]

I just want the ability to declare something as an int with value 3, divide it in half, and reassign the value back so it is now a float 1.5
(wince)

int n=3;
float x;
x = n/2 /* A page of other code */
printf("%d",4*x)

Logically, (n/2) should be done in integer, since both the operands are integers. That is, 3/2 => 1, and then you convert that to float, so x = 1.0. But compilers _might_ do this differently, and it sure as hell is not obvious why somewhere on the next page x*4 came out as 4.0 instead of 6.0. If you expected x = 1.5, that's a bug you'll probably spend hours figuring out. What's worse, given a legal range for n of 0 through 4, the testers might just decide to try it at 0, 2, and 4, and the bug remain undetected until the airplane takes off and the ride gets bumpy...

Implicit type conversion seems to make programming easier, but it's a prolific bug generator. What I'd rather have is a compiler that would handle mismatched types by rewriting the source to insert casts as needed. That is, "x=n/2" comes back as "x=(float)(n/2), and you get to think about whether you meant that or "x=((float) n)/2.0.

Re: Ada ?

[markmoss]

Strings should be conceived as a natural data type with their own natural set of operations, not as a funny kind of array.

I agree in general, but this adds considerable complexity to the language. Either you reserve the maximum possible size for every string (wasting maybe 90% of the space since most strings are short), or you make string variables a sort of pointer, with the actual strings allocated and freed as needed. In 1983 or so the Ada spec was released, the first choice was probably unacceptable because a lot of the military hardware Ada was targeted for was limited in memory. The second choice was unacceptable because it requires garbage collection and Ada was supposed to be suitable for embedded systems where you cannot have the system pause for garbage collection. IIRC, in 1983 on-the-fly garbage collection (that doesn't freeze the system until done) was a new and untested concept, far too risky to add on to a language that already severely challenged the compiler technology of that time. (IIRC, it took a few years after the first release of the spec before you could buy compilers for more than one or two CPU's, or count on the code beiing compiled 100% correctly.)

Yeah, now if you need to handle strings freely you've probably got a >100MHz CPU with >32M RAM, so you just choose whether bounded or unbounded strings will fit your programming style better. But it sure wasn't so when the spec was written.

Supercruise Operational Buttkicking

[Mittermeyer]

All this hoohaw about the OS is fine and well, and the stealth characteristics of the F-22 are nice (although likely to be countered sometime before the end of program life by LIDAR, passive EMF bounce, UWB radar or some other technology), but the really big billy bad boy aspect of this plane is the supercruise (otherwise known as flying at cruise power at over Mach 1).

Supercruise gives this plane the ability to cover far greater distances in less time, with less refueling then would be required by F-15s running the same circuit at the same speeds. That translates to a far greater amount of territorial coverage for defense per plane, a terrifing capacity for a dash attack and an ability to have a lethal number of F-22s converge on a crucial position.

Simply put, fewer F-22s will be able to defend more space, threaten attacks to keep an opponent on the defensive across more territory, and concentrate for overwhelming superiority.

The F-22s' greatest capability is this operational superiority. Air forces across the world are trembling at the prospect of facing this beast.

Moderation Totals: 11

[Louis Savain]

Moderation Totals: Flamebait=1, Troll=1, Insightful=1, Interesting=4, Funny=1, Overrated=3, Total=11.

Interesting moderation totals. I must have struck a sensitive nerve. For the record, my site received over a twelve hundred hits in less than 12 hours after I posted my message on Slashdot. I thank the few enlightened souls who were kind enough to email me their words of encouragement. Stay tuned. There is much more to come.

Project COSA

Re: Ariane 5 was written in Ada

[markmoss]

I thought it was a re-used software module, not hardware. But either way, the problem was the module was re-used without sufficient review, and assumed to not need much test because it worked flawlessly before. That's a human error unrelated to language or even to whether it's hardware or software.

What I really do not understand is why they did not run a full flight simulation that would have revealed a problem occurring at such and such a speed or whatever? This is more understandable if it was a hardware issue, since it might be pretty hard to persuade a hardware unit that it is flying through space at x kilometers per second - and if there was a simulator input to the hardware, it still might not react to a simulated out of range value input the same as it would to the sensors actually hitting their stops.

hah someone mod this up!

[MongooseCN]

hah someone mod this up!

Re:Why java cannot be used in a realtime environme

[Jamie Zawinski]

I had a professor which demonstrated the problem of this in a simple example. Suppose you are designing a robot which can climb and descend stairs. It must monitor sensors and adjust angles of its joints appropriately to go down (quite difficult, really). Now suppose the GC runs halfway through the middle of a step. All processing stops, gravity takes over, robot falls down.

Well, your professor was a very ignorant man who understands little or nothing about modern garbage collection techniques. Just because a system uses GC does not mean it can't make guarentees about latency.

I'm not claiming that Sun's implementation has a good, low-latency GC (it's been a while since I've used Java, so I don't know what they're up to these days) but I do know that the Java specification does not say much about such things. Which is as it should be: the desired GC behavior depends heavily on the platform on which the code is running.

Garbage collection gets a bad reputation due to the seemingly inexhaustible supply of crappy implementations out there in the world (e.g., Perl.)

Hence the reason java puts a clause in its license about no use in safety-critical applications.

Oh come on, they put that in because the company is run by lawyers and they wanted to cover their asses. That license clause doesn't mean "you can't use Java in a critical application", it just means "if you do, you can't blame us."

"Warning: coffee may be hot!"

Re:Why java cannot be used in a realtime environme

[rebelcool]

The JDC you download from sun (and every other major implementation that I know of) has no way for the programmer to decide when to collect, or methods for guaranteeing collection time. These two are crucial for any real-time system that wants to make use of garbage collection.

It quickly becomes a big problem too. Such as do you let some kind of subsystem decide when to collect (and thus complicate timing rules for time-critical apps), or in-line the code into every module? When you start in-lining it you begin to lose the main reason for garbage collection, which is to remove memory management from the programmer's error-prone human nature.

I don't know what the java designers were thinking, but probably it was that real-time precision is a small segment and not the market they were targetting, and thus went with the easier to implement, easier on the programmer style of GC.

Honestly, 'modern' GC's aren't terribly different from the older types except they let you choose when to collect and how long to let it collect for. And every implementation has a way of determining which memory to reclaim which varies from one to another...

Re:There Is Something Rotten in Software Engineeri

[Black Parrot]

> Also, since most software cannot be returned for refund, even if ridiculously defective...

And of course, even if you could take it back for a refund, you'd just get another copy of the same thing.

The actual choice is almost always between crappy software and no software, which is why people so avidly consume the crappy stuff.

Re:Ada ?

[aebrain]

Ada is designed to inherantly prevent a programmer who follows the appropriate standards from writing a program that can just crash and exit. As long as every possible exception has a handler, an Ada program can be written that will not crash.

In what way is Ada better than Java in this respect? I only know a little about Ada, so this is a serious question. My understanding is that Ada and Java have very similar safety goals (especially with respect to exceptions) so I'm curious about what you think Ada gets right and Java gets wrong.

Speaking as someone who's got nearly 20 years of Ada experience (started in 83) and about 3 years with Java... you're not quite right.

Exceptions and exception handling are just part of the issue. Java's exceptions are in many ways more informative than Ada's - which are basically "Exception of type X raised" rather than "Exception of type X thrown with the following additional information [blah blah]".

The more important issue is that with Ada it's trivial to make all sorts of checks that will raise exceptions. For example:

type SpeedType is new Float;

KPH :constant SpeedType := 1_000.0/(60.0 * 60.0);

-- Kilometers per Hr in standard metres/sec form. In practice the two 60.0's above would be constants, MinsPerHour and SecsPerMin respectively

subtype LegalSpeedType is SpeedType range 0.0 .. 1_000 * KPH;

Any time an object of type LegalSpeedType tries to take on a negative value, or one over 1,000 Kph, you'll get a CONSTRAINT_ERROR (a predefined exception).

With Java, you'd have to have a class for CSpeed, then a derived class for CLegalSpeed, with any sets triggering a check which would throw an exception if out of bounds. It can be done relatively easily, it's just more work with more opportunities to get wrong.

Ada's a language that, when in the hands of a competent programmer, prevents the expression in code of a lot of mistakes. They're picked up at compile, rather than run, time. A hopeless incompetent can write horrible code in it, but it's actually harder to write buggy code than correct code.

One other thing: the representation clauses of Ada allow you to make records where with each individual field, you know exactly what bits mean what - and simultaneously have a high-level view so that you know that bits 7..8 of word 11 mean STOPPED when 00,STARTING when 01 and RUNNING when 11, with any assignment of 10 raising an exception.

For more data about Ada, see the Ada Information Clearinghouse. Free, Open-source compilers available (GNAT).

Two disadvantages of using Ada though. First, no-one much uses it, the products are too reliable to be commercial successes requiring lots of expensive maintenance - so a project that took 30 programmers to build only needs 1 part-time to keep it running. Forget job security, you're always doing something new, usually something really cutting-edge. Secondly, you're confined to such boring applications as spacecraft avionics, supersonic jets, medical applications, railway management, air traffic control systems, sonars, radars, missiles... :-)

MS Pilotclip

[zCyl]

Hello! It appears you are trying to fire a missile, would you like my assistance?

Re:I had to say it...

[NanoGator]

ah! t'was fun. :)

Cheers!

fill in the blank

[alizard]

"Security by obscurity is for" ________________.

Proof of "correctness" isn't.

[Ungrounded Lightning]

It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.

I thought all this "proven correctness" stuff was laid to rest when the "proven correct" software examples in Dijkstra's seminal book on the subject proved to have at least four bugs.

It is not possible to prove that software is "correct". That is because what constitutes "correct" varies with the intent of the software. hello.c is "correct" if the intent was to type "Hello, world!\n" but not if the intent was to display a popup window or play a CD.

What it IS possible to do is to prove two or more distinct expressions of the desired program behavior, one of them the program itself and all of them in formal languages, are equivalent.

But expressing the desired behavior in ANY formal language is the act of writing a program. How do you know that the non-program expressions of the "correct" behavior themselves are "correct", rather than having equivalant bugs?

The answer is that you do it by having the languages be as different as practical and having different people (or teams) write the various versions of the expressions of intent. Then you debug them all together, until they all agree, and all also agree with what the people THOUGHT was right when their attention was brought to the places they initially disagreed.

This works because different people tend to make different mistakes, and different languages tend to lead even the same programmer into making different mistakes. (The former has been known since before automation. It was put to good use in the tab-card era, where one operator would punch the cards on a keypunch, then another would "verify" them by typing the same keystrokes on a similar machine.)

Of course, if you substitute "spec" and/or "comments" for "formal description", and "QA team" for "proof engine" you have the classic team software development process. Substitute "other programmers" for "QA team" and you have the walkthrough. And so on.

= = = =

I agree with the rest of your point, however: Well designed, well tested software can be enormously more reliable than the hardware it runs on. A program is digital. If it is correct, it is ALWAYS correct. It never fails, never makes a mistake, and never wears out.

Re: Proof of "correctness" isn't.

[Black Parrot]

> I thought all this "proven correctness" stuff was laid to rest when the "proven correct" software examples in Dijkstra's seminal book on the subject proved to have at least four bugs.

I haven't heard that particular story, but proofs certainly haven't been laid to rest by that or anything else.

> It is not possible to prove that software is "correct". That is because what constitutes "correct" varies with the intent of the software.

Yes, formal proofs require formal specs. (IMO the mere fact of pinning down the spec that carefully will probably do as much good as the verification proofs would.)

But the challenges of constructing formal proofs are irrelevant to the claim that algorithmic systems are inherently unstable. The fact that you can prove correctness for some algorithms is sufficient to refute that claim.

Re: Proof of "correctness" isn't.

[Ungrounded Lightning]

But the challenges of constructing formal proofs are irrelevant to the claim that algorithmic systems are inherently unstable. The fact that you can prove correctness for some algorithms is sufficient to refute that claim.

Substitute "equivalence" for "correctness" and I agree completely. Algorithmic systems are not inherently unstable (read that "buggy").

The ease with which they can be built and modified leads to the construction of software that is fantastically more complicated than what could be implemented in hardware with a similar amount of manpower. This creates more opportunities for error. Then sloppy programmers (or programmers rushed by sloppy managers) ship software with errors and this creates the illusion that flakeyness is inherent in software.

But with sufficient care every piece of this complexity, including the assembly of the pieces into a system, can be implemented correctly (no bugs) and/or robustly (works appropriately despite bugs). And unlike hardware, once implemented appropriately software KEEPS working correctly and/or robustly, unless/until someone breaks it by changing it or its environment.

Re: Why C?

[Black Parrot]

> You act as though C is responsible for a stack overflow or pointer pointing problems.

> You wanna know something: IT'S THE PROGRAMMER.

Yep, people write programs. And the errors are almost always the people's fault, not the language's. And people can, in principle, write correct code in any language - including by toggling the machine code in on the front panel.

But you're missing the point. The reason we don't toggle our programs in on the front panel is that it is very error prone, and we can eliminate a huge number of errors by putting the computer itself to work doing that sort of tedious grunt work where lots of errors occur.

And that's why some of us use Ada instead of C. It's essentially the same reason we prefer C to assembly language and prefer assembly language to toggling in the machine code. Programming is fun; tracking down stupid bugs isn't. The question isn't which language prevents you from writing buggy code; the question is which one helps you catch the most bugs with the least effort. Let the compiler do the grunt work.

And which do you think has the least negative economic impact: catching a bug when you compile, catching a bug during testing, or catching a bug in a system that's already in production?

If your language can move bugs forward in that process, it can save your company money. (And perhaps even save lives.)

You are entirely correct when you say that people cause bugs. But that's an argument that supports the adoption of bug-reduction technology, not an argument against adopting it.

> Let me tell you a little story. ... Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.

FYI, there are many different GC algorithms, including some that make trade-offs to ensure that the GC never uses more than a fixed amount of time. If someone uses a language with an inappropriate GC algorithm in a real-time situation, you should take that as de facto evidence that they aren't qualified for the job.

> Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.

Bet you never saw a bug that resulted from using a macro, either.

The first step in solving the world's software crisis must be owning up to the distinction between "what I like" and "what's good for me".

Re: Why C?

[Black Parrot]

> Let me be the first (or second or third) to point out that TeX, quite possibly the world's only bug free program, is written in Pascal, an ancestor of Ada.

Let me add that in the typical programming team of n programmers, you can expect to find about 0.00000n Donald Knuth's. Erich's pointing out that TeX works very well is about as useful as pointing out that Einstein was right about relativity. Most of us don't operate in Knuth's league any more than we do Einstein's, and so we need all the help compiler technology can give us.

Re:There Is Something Rotten in Software Engineeri

[gmarceau]

you'd just get another copy of the same thing

Not quite a refund, ain't it?

which is why people so avidly consume the crappy stuff

Which is why people came up with open source.

Re:Why C?

[Erich]

is generated, not by the garbage collector, but by the JVM when it trys to access a method from a null object, a pointer vers a non initialzed object. This has nothing to do with the memory management. If you had said: java.lang.OutOfMemoryError, I would have aplaud you. But, You missed the mark by a mile.

Sorry, what I meant was that the object paradigm allows for invalid references. In Java I can have a reference that doesn't point to a valid object, and if I dereference it I can get a NullPointerException. This is, of course, a separate issue from the garbage collector.

"Memory management" from the point of view of the programmer, not that of the environment. That of how you manage your storage.

Re:Why java cannot be used in a realtime environme

[Glock27]

I suggest you look at the Realtime Specification for Java. You can find it here.

It's been final since September 2001.

LOL

[DaveWood]

Ah, undecidable. Forgot to click anonymous? Oh well. So nice to see you again.

I know I must have hit pretty close to the mark in our previous conversation to earn your lasting affections. ;)

OK Captain Hypocrite

[DaveWood]

If you have a burning need to make an ass out of yourself, then by all means, don't let me stop you.

Frankly, I feel you'd really be shortchanged if you didn't strive for even higher levels of embarrassment.

Have yourself a ball, cheez whiz. :)

Oh, I almost forgot to mention

[DaveWood]

Welcome to my ignore list. ;)