Is Information an Important Science?

How long is 'once in a while'?

I just took a look at a couple of Debian GNU/Linux webservers with reported uptimes of 340 days and 289 days. IIRC it was last July that we had a major power outage for several hours, so that might explain why they are so low. I've seen regular reports of linux and unix machines up for years on end, and only being restarted due to a hardware change/failure or kernel update.

True, there is little to no financial reward for Linux or BSD UNIX to make great code or crappy code. However, keep in mind that both projects are written and maintained by people who love it. People who love things tend to self-educate themselves about it to a very high level, and tend to make these things to the best of their abilities. Doesn't mean that there *won't* be bugs in the OS, but it does mean that there is a great level of care devoted to keeping them all to a minimum. Each release of FreeBSD, NetBSD or OpenBSD simply IS NOT RELEASED until it is ready. There is no pressure on deadlines, only the desire to make it as good as it can possibly be.

In my personal experience of GNU/Linux, FreeBSD and NetBSD over the last 7 years I've never had a show-stopping system crash. *NEVER*. I won't say it can't happen, but I will say I've never seen it. As much as I dislike Windows, i've got to say that 2000 and XP are light years ahead of all the Win9x crap. It's got its own security issues, but as long as nobody fecks with it it's alright.

Apple on the other hand....... naw, I better just keep quiet about that :-)

-phaeton

Well, you could normalize both to contact-minutes-per-day; the coffee wins by a wide margin.

Scientific equations are based on reality, so they don't change much and, if they do change, it's always an incremental improvement. Computer languages aren't based on much of anything, except maybe resume padding.

John

Each year there are tons and tons of 'fad' languages written and forgotten.

At the end of the day, the world still runs on C, Perl and assembly.

Go finger.

No, and I don't know of any direct relationship. However, we are both members of ACM.

And, I am not Congressman Ron Peterson of OK although my sister once lived in his district.

So why is Bill Gates the richest man in the world, if his programmers can't write code?

-Bill

That's a good idea!

Ouch, that's harsh. ;)

Michael Darrett, Plainclothes Engineer

when it does it doesn't.

Bye. Jasen

his lawyers are good at law, his strategists are good at strategy, and his marketers are good at marketing.

Bye. Jasen

He's rich because he sells you software that's buggy and unstable, and he sells it to you over and over, because you hope the next version of Windows or Word or IE will crash less or be less of a security risk. Microsoft has a dilemma now, in that Windows isn't, after 20 years, all that bad, so people are getting less inclined to upgrade. So microsoft is trying to (sneakily... go do a patch upgrade) push the "genuine advantage" thing where you pay them forever to run their crappy code. He got rich by writing garbage and being ruthless about selling it and crushing competitors.

Have you *seen* any Windows source code? I have. It's garbage. No doubt some of the microserfs are good coders, but Windows fails at the higher, structural/interface/policy level, which is a symptom of Bill Gates' hombrew hacking history.

John

Bill does have good business ability unlike his competitor (was it Gary Kildall?) who failed to sell IBM a different operating system.

I have a friend who writes embedded software lik John does. Although, they are smaller software projects, there is a greater need for reliability and less need for hundreds of features to attract mass customers.

Microsoft does hire the best comp sci graduates, but corporate goals get in the way of enabling the workers.

The map is not the territory; the program's inputs are our _interpretations_ of real-world experience and are only as useful to the software as we accurately describe what we see.

There's opportunity for error here that isn't the program's "fault"- we can misread instruments or even mistake one physical phenomenon for another before we tell the program what we saw. The program will diligently output predictions that aren't congruent with reality, but we won't know that until we compare the predictions against reality.

Outputs are not experiences; they're _predictions_ of what a real-world experience will be, and are as useful to us as the software accurately models the physical process(es) covered in the software given accurate input. If the software doesn't frinst know about the linkage between the EM force and the weak nuclear force or something as simple as precession/nutation in macro phenomena, it will output blatantly wrong predictions but again, we won't know until we them against reality.

If the predictions are congruent, we can trust our observations, interpretations, and the program _for that iteration_. If not, we have to re-examine our data-gathering techniques and/or what the program does with its input.

(This assumes no software or hardware glitches.)

That _scientific_ modeling is not a "once through" process; it's recursive. We reduce our observed data to something the software can handle, run it through the software, take its output and compare it (the software's predictions) against reality, and then use the comparison (whether it's congruent or not with reality) as new input to refine the model.

Bottom line- "properly" is unfortunately asymptotic; we cannot know if software is written "properly" until we do that comparison (and if necessary, reiterate until the model's predictions either are congruent with reality or diverge from it and show no signs of reconverging).

I'm not saying that computer modeling is a Bad Thing, I'm saying don't put too much faith in it.

Mark L. Fergerson

I haven't seen any of it, but rumor is that it's actually got some marginally good bits here and there, but they're all stuck together with several layers of mopish kludge, none of it is documented or commented, and such. Any truth to that?

Pervasive licensing/business models aside, word on the street was that MS admits the Windows code base is too big and too complicated (in the spaghetti sense) for them to really deal with it and keep it all straight anymore. Hence the whole LongWait Project, where they're (supposedly) starting from scratch.

OTOH, I have looked at stuff like the FreeBSD and Linux kernels. Some of it's over my head, but the stuff that I did grasp and see looked pretty good, esp. in the case of FreeBSD. I'm no expert, though.

-phaeton

A lot of the stuff that matters is coded in ADA, and a lot that doesn't matter is coded in Java.

John

Yes, apparently the Greenland glacier is breaking up much faster than predicted by computer models. Garbage in, garbage out?

Predictions wrong

The ice sheet seemed such a stolid reservoir of cold that many experts had been confident of its taking centuries for higher temperatures to work their way thousands of feet down to the base of the ice cap and undermine its stability.

By and large, computer models supported that view, predicting that as winter temperatures rose more snow would fall across the dome of the ice cap. Thus, by the seasonal bookkeeping of the ice sheet, Greenland would neatly balance its losses through new snow.

Then the ice sheet began to confound computer-generated predictions.....

They say if it all melts, the sea level will rise 20 feet. I live about

-Bill

On Wed, 28 Jun 2006 13:18:19 -0700, in message , John Larkin scribed:

My last company spent an enormous amount of time and money investing int he future of Ada. I spent a six-week training course in just that. I liked Ada, it's nearly bulletproof to tinkering. It's one great advantage is that, if it compiles, it will probably work. This adds a lot of time to program development, but saves greatly on integration and maintenance.

Then everybody and their brother started getting waivers to programming in Ada (probably because poor programmers couldn't use it), and the company ended up with a figurative ton of applications written in c and c++, much of which is completely indecipherable, because programmers like to safeguard their "style." Even the ones who have no style to speak of.

On 27 Jun 2006 20:22:37 -0700, in message , "phaeton" scribed:

Your subtlety was noted and appreciated. :-)

Are you in Portland by any chance? Oregon, nay, PNW, crafts are the best.

We have an excellent brew pub in my local area (it's a small town, so one good brewery is sufficient). If you join the "beer club," the first beer of the night is always free, and $1.00 per pint thereafter. They have eight styles available at any one time of the season. Wine is good, beer is better.

On Tue, 27 Jun 2006 16:06:16 -0400, in message , Straydog scribed:

Your inference is flawed. His statement, to me, is saying that if programming involved any serious amount of mathematics, science, and engineering, it wouldn't crash so much. "So much" being the phrase that rules out your faulty inference of "100%" reliability. If you've ever studied reliability, you'd know that there is no such thing as 100% reliability.

John's implication is borne out by my experience. Programmers, especially when using c (and its attendant variations), are free to put together heaps of garbage that are sold to the consumer with nary a thought to quality or robustness. Engineering projects, such as bridges, buildings, aircraft design, etc, tend to stay up and in the air without falling down with regularity (granting some rare but notable and spectacular failures). This is because these projects are held to a higher standard of performance than your typical Windows application. The bottom line in much programming is to produce something that *looks like* it works, and makes money.

On 27 Jun 2006 21:51:04 -0700, in message , "Ron Peterson" scribed:

So you know of him. I took some courses from him back in the day, and worked with (athough not alongside) him for some years.

Well, good to meet you.

On 28 Jun 2006 09:36:46 -0700, in message , "phaeton" scribed:

Not much different than some of the projects I've worked on, sad to say. Anytime the bottom line is cost and schedule as opposed to quality, you'll get that. Another problem is that the modern way of doing things is to have MBA's and professional managers in technical management spots, and so they tend to be clueless about the process they are managing. Added to this is the fact that marginal programmers can be very good at talking a good game, and hiding defects. I've seen all this first hand.