mkovach

I didn't mind the language itself, but the application I worked on was inventory related, which was mind-numbingly boring.

Then, learn about mainframes since most of the COBOL in the wild is running on z/OS or the like. IBM use to offer a free Mainframe course. You would also want to learn JCL, REXX, and a few other mainframe related tools.

The apps are no different then most things now (inventory, accounting, etc.) is is the legacy processes that will most people that biggest problems.

And checkout a YouTube Channel by moshix. Lots of great mainframe info there.

That would get you started on the path.

But he really thought that TV was an important medium and there were things he wanted to say. He just found out that science fiction allowed him to get around censorship.

There are plenty of running themes he includes, but interestingly enough, baseball (he was a huge fan of the Dodgers) and religion have an existence in the Twilight Zone, which always fascinated me.

One of the most complete sources of baseball stats including game logs. Yes much of the data is from other sources (MLB, Retrosheet.org, etc) but they really ties things together nicely and I can spend hours on the site.

He did quite a bit of work (and had a similar lawsuit) that code was speech.

He use to attend the Linux Users Groups meeting I was part of. Amazing person and really friggin' smart. Also, he was pretty good with Tex.

One of the reason, at the place were we ran about 100's of RHEL/CentOS instances, he stayed with RHEL-ish installs was to maintain API compatibility through out the lifecycle of the OS version.

I've now moved on to places were that isn't that specific need. But I still have a few smaller projects that I use RHEL/CentOS/Rocky/etc. because of the stability that those built into the releases.

Addie Joss threw the fourth perfect game in MLB history, in 1908.

I switched from Postgres to SQLite for a couple of versions, put mainly because Postgres wasn't "supported" I called SQLite an "internal database thing".

Worked flawlessly for about 7-8 years before both services were gobbled up into micro API services.

At the last count, we have about 14,000 services checked by uptime (about 1,000 every 5 minutes, 2,000 every 10 minutes, the rest every 15). Probably had about 60,000 tinyurls in MyTurl. We also ran the MyTurl urls through uptime every night to look for bad links. The system go hammered, often.

It took minor tweaking to get the the best performance out of the database and AOLserver has some nice caching features, which helped to take the load off the database a bit. But overall, it worked as well as the Postgres counterpart.

And now, I have to figure out why I never released the SQLite version of both.

The biggest problem in baseball is you have to maintain a minor league AND a major league. You need younger less expansive players, inexpensive players to fill the roster, and expensive players. Depending on the market you need to either trade your younger talent before it gets expensive (getting younger players from other teams) and be able to develop those players. Or, you have to be able sign high price players and make trades to bring in lesser talented players from other teams to developer your farm system, where you'll often trade your best prospects for older, more expensive players.

Both systems have worked lately. Cleveland has had one of the best records in baseball since 2014, but the Dodgers and Yankees spend and do well.

The larger problem is revenue sharing in MLB. While there is revenue sharing because of the TV contracts, New York, Boston, and LA make a huge amount of money off local TV deals. Cleveland, Tampa, et.al. make a lot less. So, unlike many other sports, revenue is not shared equally and teams need different ways to acquire and use talent.

In the NFL, you need to have a very good QB and you can build a team around them. In the NBA, you need 2-3 very talented players, mid-cost starters to fill your game day rotations and strong reserves to handle injuries and such. Since those leagues share revenue that can implement caps and floors with salary. Sorry, I can't talk about the NHL, I don't understand their business enough.

The bigger problem with the MLB is their lack of equal revenue sharing makes a floor and cap next to impossible to setup. MLB teams simply are not going to put all their money in a big pool and share it.

Funny part is now I do a very basic Slackware install that setup pkgsrc (https://pkgsrc.org) on it so I can really experience the best and worst of times!

It was fairly easy to learn the language and port the C/Perl/TCL CGI things I normally did. In fact, I ended up writing library much like Don Libes cgi.tcl that was somewhat popular back then.

Surprisingly one of my favorite data projects (https://retrosheet.org) has tools that will output data in a format that makes it really easy to read in FORTRAN. So, I still use it quite a bit to do some heavy lifting with my baseball research.

It was banned in two steps. In 1920, players could assigned up to two pitchers to throw the spitball. After that season, 14 players were grandfathered in and allow to continue throwing a spitball. Burleigh Grimes threw the last legal spitball in 1934.

Carl May threw a pitch that killed Ray Chapmen in 1920, which the spitball rules still allowed teams to have spitballers. May was generally a wild pitcher, in fact he had hit Chapman's teammate, and manager, Tris Speaker in the head in 1918. May's claim was Chapman was crowding the plate, He throw a high inside fastball, that his May's teammates claim was a strike, to brush him off the plate. It was an unwritten rule about brush back pitches that lead to Chapman's death. Chapman's death had nothing to do with getting the spitball getting banned.

Rivera was the best pitcher I have seen in throwing a cutter. His long fingers let me get unique grip on it.

The problem that MLB didn't see was that my providing information about spin rates, pitchers would be able to start experimenting, see results, and adjust.

I still have a few internal apps that use Naviserver.

They had a computer system there to keep the inventory, running dBase III and hooked up to a NetWare network.

First day: No reports could be printed. Reloaded the various drivers, re-ran the reports.

Second day: They told me about a bug that caused the counts to be off so after checking things in, I had to manually add the right answers to the totals. Fixed the bug in dBase app.

Third day: The pull me to the front office, I'm working in the IT department and somebody's else kid is working in the parts shop.

Of course, you have to overcome decades worth of ``stuff'' but it certainly is the right tool for what I am doing. It has a purpose but there is a learning curve to getting things done the FORTRAN way.

Fun times was one they sent a tape to do major upgrades.

I enjoy the simple syntax and I wouldn't call it dormant by any means. It kept simple on purpose and doesn't require many changes.

Teacher took away points not using assembly or C and because "you shouldn't be able to add code on the fly".

Still bugs me to this day.