Bad Design of Programs and

Found at: zaibatsu.circumlunar.space:70/~yargo/clog/zc-bad-program-system-design.txt

# Bad Design of Programs and Systems // 18-10-06

(This should logically be on gopher.first.ethz.ch but I don't dare to put
there any post containing personal opinions.)

We have a DWL66+ direct laser writer (by HIMT -- you're certainly able to
your-preferred-search-engine that if you need more information) installed
in our lab since some weeks. It's operational, but not yet available to
our users, because we first need to familiarize ourselves with it and to
define the procedures of use.
It's quite a nice system, but as always, you find annoying design flaws.

Controlling is done by a Windows10 (yikes!) computer through C# (maybe not
*that* bad, but I don't have any experience with that language).
There are two more computers in the system, an OS9 device running the
exposure part and to which we don't have direct access; and an OpenSUSE 42.2
Linux machine for data conversion, which can be accessed through ssh and
SMB mounts from the Win10 PC.

The Win10 machine has all relevant data including DBs in a single directory,
which I put immediately under Git control. It's rather nicely done, as it
works well in a normal (non-administrator) account we created; of course the
manufacturer runs it with full admin privileges...

(Side note:
We have a Keithley DC prober incapable of working on non-admin accounts, as
it is programmed in such a stupid way that the drivers don't work if you
are an unprivileged user. *Idiots!* I put it into our "quarantine" network,
to reduce the probability of contaminations.)

The Linux computer is required to convert design data in CIF, GDSII or DXF
(totally stupid for mask design, but used by Johnny Noclue-Sixpack) formats
into the internal binary format used by the OS9 exposure system. This can
be quite heavy work, as the design needs to be cut into traces of defined
width (depending on the write head) and converted into bitmaps. It's the
reason why it's done by a dedicated computer.

The workflow is as follows: From the Win10 PC, you connect to storage at
the outside world, fetch the design data, put it into the corresponding
directory (cif, gdsii, dxf) in the home directory of the "convert" user on
the conversion machine, launch the converter software there, and this puts
the resulting (binary) exposure data back into the *home directory!*

You certainly spot the flaw. The home directory, which of course also
contains other files and directories necessary for the conversion process,
gets filled up with the conversion results. Dafuq! Was it not possible to
afford one additional layer of directories, to keep all the conversion
output separated!? I do wonder what people were thinking designing that...

I am planning to install git on the Linux machine and to put everything
relevant into a repo, so that I can do an `rm *` (yeah, risky...) in the
converter home directory when it fills up. As the conversion PC is not on
the internet, I will need to fetch all required packages and transfer them
there, though.