My Vintage Dream PC

[ItsASecretDummy]

Doesn't make the dough and bake the bread while you're at work.

No, but it makes one hell of a vaporizer.

 

[Kim Enkovaara]

About 17K lines; zero known bugs as of today. But big projects are

That is very small project in terms of software. Even my ASIC/FPGA
testbenches are sometimes 5x bigger

usually made out of small modules. Since big projects are usually
buggy, either the small modules have internal errors, or the module
interfaces are poorly defined. In neither case has academia nor the
software industry had a lot of success in managing to fix the
problems.

The problem is how to define these interfaces. Modules have interactions
at different levels of hierarchy and trying to keep all those in mind
during design phase is difficult. When you approach the millions
of lines of code, then the documentation also is in the range of
(ten)thousands of pages. Trying to keep that kind of monster in
control is not easy.

Unit level interaction problems are quite common, they are usually
caused by misunderstandings of the big picture. Of course also unit
level problems are common, they could be mitigated via module testing
etc. but that costs money. The development process is always compromise
between time to market, price and reliability. Maybe in military
projects the time and money are not a problem

--Kim

 

[Kim Enkovaara]

And you trust your entire code base to this?

And you trust your filesystem, operating system, backup media,
manual operations for release versioning etc. How do you know
that 5 year old release file xyz is not corrupted? In VCS systems
metadata usually contains crc or hash of the version, and the
database integrity can be checked. Do you have manual pictures
of the relationships of the code, or is it so simple that it is
in one linear progression, which is not normal.

At least in VCS systems usually mere mortals can't delete any
versions at any time. In that way a user can not do any real damage.
And of course those systems are also backed up, maybe replicated
for hot switch-overs if the system is not healthy etc.

This is not rocket science, VCS systems have been in use for a long
time and for a reason.

--Kim

 

[ItsASecretDummy]

Not to diminish good fresh bread, but i also like good steak, good
fish, good poultry, and similar hot off the grill. Also fresh string
beans, broccoli, cauliflower, interesting salads, and fresh fruit.

Mmmmm... steak.

I also like belly meat blue fin tuna sushi, but there is not much in
the way of aroma coming off it. Sure tastes amazing though.

 

[Kim Enkovaara]

There was "the" unix filesystem, before they proliferated. Even
though there are now several filesystems, as you say none has done
this. That's because of all the parts of the OS that would have to be
modified at the same time. File open calls and the shell would have
to be modified to open the latest generation of file by default, and
yet still be able to open an earlier generation when wanted, and to
delete the oldest generation depending on settings. File deletion the
same way.

How about ClearCase mvfs? In mvfs you can probe older file versions, or
even versions from different branches. Checked out files can be edited
freely. The hard part of creating a file version is left to additional
utility that is used to checkout, checkin and delete the version
controlled files.

For example in mvfs you could do "less file.c@@/main/mybranch/3" or
"less file.c" for the default version (latest, or any other specified by
configspec).

--Kim

 

[Ahem A Rivet's Shot]

The development process is always compromise
between time to market, price and reliability.

Hence "There's always time to do it over and never time to do it
right".

 

[Ahem A Rivet's Shot]

My car starts reliably every morning. From turning the key to being in
motion takes, literally, about 3 seconds. Turning on the radio never
makes the power steering fail. Jet planes rarely fall out of the sky.
People can do this right when they care to.

The big difference between cars and programs is that programs are
generally one off designs done under time pressure with urgent spec changes
at the last minute. There are usually glaring errors in every stage from
requirements to final product - some of the errors cancel each other out,
many are never found.

That being said - my BSD boxes run reliably for as long as I care to
run them, start reliably whenever I choose to start them, opening vi never
causes sylpheed to fail (to pick two applications at random). Most unixish
systems will run crashme indefinitely (crashme is a delightful program that
populates a chunk of memory with random numbers and then executes it after
setting handlers for all the error signals this behaviour is likely to
produce) without causing problems to anything on the system.

In other words there is reliable software and it has become
reliable through pretty much the same process that cars and jet planes have
become reliable - refinement in light of experience. Cars were far less
reliable in 1920 or even 1950 - it wasn't until well into the 1970s that
electric start was reliable enough to dispense with the cranking handle
completely. They have become reliable because over the years engineers have
been learning about, understanding and removing the causes of unreliability.

 

[Peter Flass]

That is very small project in terms of software. Even my ASIC/FPGA
testbenches are sometimes 5x bigger


The problem is how to define these interfaces. Modules have interactions
at different levels of hierarchy and trying to keep all those in mind
during design phase is difficult. When you approach the millions
of lines of code, then the documentation also is in the range of
(ten)thousands of pages. Trying to keep that kind of monster in
control is not easy.

Unit level interaction problems are quite common, they are usually
caused by misunderstandings of the big picture. Of course also unit
level problems are common, they could be mitigated via module testing
etc. but that costs money. The development process is always compromise
between time to market, price and reliability. Maybe in military
projects the time and money are not a problem

There's always a question of how much "scaffolding" you want to take the
time to write. If you have one module in isolation you have to write
code to provide its inputs and do something with its outputs. When you
do that, you still have a potential problem with misinterpretations and
bugs, so you're not much further ahead than if you tested large chunks
of code all together.

 

[Peter Flass]

I have worked with plenty of machines with no ROM whatsoever. You had
punch in by hand the most trivial tools, then use that to add a
loader, maybe 50 words or so (of 150 to 200 bytes on a byte oriented
machine). Then, on the machines i used, a paper tape could load any
useful program. Once you had some ROM to work with booting/IPL got
much easier.

I can't exactly recall that PDP-11 video on U-Tube. Didn't they have to
toggle in the initial bootstrap in order to load the paper tapes?

 

[jmfbahciv]

It doesn't make any more sense as an assignment. You have sophomores
hand-assemble a few lines to get the point across, and then move on.

The university I went to had a grad level course which consisted of
writing a compiler. There were no classes.

/BAH

 

[jmfbahciv]

In other words, it was successful because it was very small.

Nor complicated like a monitor can be.

/BAH

 

[jmfbahciv]

But ditto smells so good.

<grin> I once had a secretary who would condemn anybody
who drank beer but would figure out how to spend an hour
making ditto copies.

/BAH

 

[Patrick Scheible]

How about ClearCase mvfs? In mvfs you can probe older file versions, or
even versions from different branches. Checked out files can be edited
freely. The hard part of creating a file version is left to additional
utility that is used to checkout, checkin and delete the version
controlled files.

For example in mvfs you could do "less file.c@@/main/mybranch/3" or
"less file.c" for the default version (latest, or any other specified by
configspec).

This is a good thing. When was it released?

-- Patrick

 

[Joe Pfeiffer]

The university I went to had a grad level course which consisted of
writing a compiler. There were no classes.

Most CS departments have an undergrad class in compiler writing, in
which the term project is to write (for a toy language, of course).
They don't write it in machine code!

 

[Ahem A Rivet's Shot]

This is a good thing. When was it released?

The bad thing is that it's proprietary storage with no
available documentation on the storage format (at least there wasn't when I
used ClearCase). It was also fragile when I used it and hard to set up. It
may have improved but using it made me think fondly of CVS.

 

[Scott Lurndal]

Early 1950s. Granted, that's an assembler for a different computer.
But I just can't believe that when there were something like five (or
fewer) computers in the world, such a small community couldn't do favors
for each other.

I suspect getting time on one of those 5 computers would be like
getting observation time on the hubble.

I should ask around the MV plant and see if there's anyone left that
remembers.

scott

 

[Scott Lurndal]

This is a good thing. When was it released?

IIRC, 20 years ago. I believe it started on the Apollo systems.

It would only be a good thing if it were open source, never a good
idea to trust your crown jewels to a proprietary file(system) format; will
almost always bite you in the end.

scott

 

[Rich Grise]

Aromas? Can't beat fresh-baked bread, hot out of the oven.

The greatest invention since the microwave oven is the bread maker.
[/QUOTE]

Nah - it's gotta be hand-kneaded. The little droplets of sweat add
to the flavor! ;-)

Cheers!
Rich

 

[Patrick Scheible]

I don't think I could bear to part with any of them. Well, maybe a
dead '35. I want to fix the 9100s some day. Unfortunately, HP never
released the schematics for some bizarre reason. The HP historian has
a trove of documentation on the 9100 that they won't release, so 9100s
are going into dumpsters.

Sigh.

-- Patrick

 

[Walter Bushell]

Most CS departments have an undergrad class in compiler writing, in
which the term project is to write (for a toy language, of course).
They don't write it in machine code!

Write a c compiler in c is the basic exercise.