Continuing the theme of previous item, examining modern shit by trying to transpose it to an earlier era.

I’ve got Github updates on my mind today because I just finished shaving an especially dirty yak.

I’m cranking up my courseware-making tools for a new edition. One of my processing programs depends on the PIL image-handling module. I lost PIL from my main Python folder last year when a computer failed, and didn’t need it until now. PIL has now been replaced by a “new” and “improved” module called PILLOW, which doesn’t work with Python 2.7 because EOL or some such shit. PIL has now been memoryholed in all the ‘official’ archives. After figuring this out, I wandered around and found the correct installer for the real PIL in an obscure place.

Everything in every network is updated constantly, and all of the updates are connected. When one item in the chain updates, it effectively DESTROYS all the other members of the chain, which then must revise their own code to fit the new fashion. And every update makes every product WEAKER, not stronger. For instance, every update to the audio editor Audacity restricts the types of audio formats it will handle. When a format goes EOL, it doesn’t matter how many clips are still around using the format; you’re not allowed to touch it.

= = = = =

This concept doesn’t transpose to earlier eras at all. Before the computer age, there were only two common types of updates to an existing product, and neither was automatic or destructive.

[For clarity, updating an existing product is not the same thing as offering a new product. Every product, from wines to books to cars, tries to offer new vintages or editions or models as often as possible. Planned obsolescence makes you want the new, but it doesn’t  alter or delete the old.]

(1) Cars have been updated since the 1930s. When the maker decides that a new car has a SERIOUS bug that will cause quick failure or accidents, dealers receive instructions and parts for the repair, and dealers reach out to the buyers. Recalls were legally required in the ’60s, but the process was already well established.

(2) Catalogs and handbooks issued frequent Supplements of changed product details or prices. This was mostly at the business-to-business level, not retail. If you were a regular buyer of gears or wires or switches, you’d have a big annual handbook from the maker, plus an accumulating stack of monthly revisions. Often the big book was loose-leaf so you could replace old pages with new. (This resembles the pre-Github practice of voluntary updates to software.)

I can only think of one retail relationship involving updated publications. When you bought a complete Encyclopedia, you received annual Supplements or Yearbooks. These included new scientific or cultural developments plus errata for the permanent book.

The B2B nature of older updates gives a clue about the purpose of the new updates. Larger businesses can handle frequent changes in specs or prices. They have clerks and office managers to deal with such crap.

A casual user who isn’t trying to ACCOMPLISH anything may be annoyed by auto-updates, and will have to pay unnecessary money, but he doesn’t have an AMORTIZED TOOLBOX of homemade tools and developed skills. When the current version of his favorite videogame reaches EOL, he buys the new version automatically and goes on playing.

A small business, or an individual trying to get shit done, is SWAMPED by the constant chain of updates. I have to spend about 1/5 of my time figuring out how to keep my TOOLS working despite constant weakening and prohibitions in the chain of subtools.

That’s the purpose. Increasing chaos and complexity is hard for everyone, but it’s deadly for small businesses. This trick has been employed in regulations and tax laws for centuries, and now it’s employed in software.

= = = = =

Just for fun, here’s my unedited worklog for the shaving.

For variety, let's detour to other parts of the project.  Convert some
of the worksheet LSNS to HTML and check them on ScormCloud.

Yak shaving!

Made shortcut for svg-convert.  It needs JPGlist.dat, which must be made
by JPGlist-maker.  And in turn the JPGlist-maker needs to have PIL
installed in the Python27 folder.

This is a huge yak.  PIL won't install on a 64-bit computer, so had to
use the newer Pillow.  It comes close to installing but needs VC REDIST
9.0 or something.

No, didn't need that.  Just needed the trick that I had used earlier for numpy:

sys.path.insert(0,'c:\\python27\\Pillow-1.0')

The jpglist-maker starts but doesn't do anything yet, for ordinary
non-yak reasons.  There are several specific folder refs that need to be
changed, and the JPGs need to be copied into one of those specific
folders.


Filled in those folders.

Now the jpglistmaker py starts, but hits 'imaging_C module not found'
Checking online....

AHA.  Finally found a correct and usable installer for the real PIL, not
the fake PILLOW.  Installed, and immediately the jpglistmaker worked and
generated the Txt and Dat files.  Saved the correct PIL installer to USB
for security.

The URL is
https://github.com/lightkeeper/lswindows-lib/blob/master/amd64/python/PIL-1.1.7.win-amd64-py2.7.exe?raw=true

Now return to the main SVG-convert and see what else it needs.  Trying
with 90-01, the first of the worksheets.  It errs at the first ref to a
JPG.  It wants the filenames in the JpgsNeeded folder to be lowercase,
so I changed them and reran the jpglist-maker.

Now the svg-convert works, and made the complete set of htmls and css.
I moved them into a new folder, and now it works fully.

Hmm. My unedited private writing is identical to my edited public writing here on the blog, except that I cuss more in public. So in this context edit means Insert ‘fucking’ in every sentence.