SulphurSmell

I am with you. Been messing with tools my entire life...have tried ratcheting screwdrivers of several kinds...Hard no. If I do lots of screws, I use a drill or impact driver. Or, failing that a nice 1/4 or 3/8 ratchet wrench with the appropriate adaptor + bit.

I recall this fondly when it came out. I had a few racks of Sun servers at that time...and anyone I showed the video too were convinced it was bullshit. April Fools anyone? However, Brendan and Bryan know their onions...and all the naysayers had to pause and think a bit. It too crazy to believe...and too crazy to not believe. I miss this stuff.

Edit: This was done when everyone ran spinning media. I wonder how modern SSDs hold up?

I don't really doubt the numbers...in fact, I thought them a bit low. My feeling is that this will really change the automotive landscape for the overall lifecycle of a car. Seems to me that the dealership currently doesn't worry too much about immediate margin on a new car. They know that that car will come back to them for in-warranty service (which the dealer bills back to the manufacturer) and after-warranty service (loyal customers afraid to go to a less expensive garage). In a nutshell, all the real money is the recurring revenue for service. EVs will require less service...so I'm thinking the dealer will just keep their margin higher up front to make sure they don't lose after the sale. I would bet the dealers would rather sell some sort of EV that needs frequent/predictable/reasonable service...thus supporting the annuity model that has existed for decades. What to do? Build super high quality EVs that need almost no maintenance? Then you don't need that expensive dealer network. But consumers want that dealer to visit and complain to when things don't work...and that costs money. In the end, I think consumers will need to realize that their overall experience and expectations of car ownership are in for a big shake up over the next few years.

Canada,ditto.

I am surprised I had to scroll this far to find a dBase reference. I am the same vintage as OP, and yeah... back in the day dBase was the key to riches...at least as a contract dev. I remember spending A Lot of Money on the big box of dBase IV when it was released...all the diskettes and manuals. Around that time there was much talk about migrating from dBase databases (those .dbf files) to the magic of "SQL" which at the time meant nothing to me. Needless to say dBase IV cratered, and the industry went elsewhere. Good times!

Shelves and shelves of tidy orange binders. I had them too!

I am also old. And tend to agree with you on this.

Interesting. It was never an issue for us, as we were close to the CC servers. Some folks were not, so they ran their dev/build locally ("network close" to th CC servers) and VNC'd in from their actual location. In that case, only the stuff on the screen had to transit the "far away" network. Although, I think today, network issues would be less of a thing...as I tend to think that networks have scaled faster than code base size. I could be horribly wrong about that though. Any centralized repo is going to have this challenge though. It also depends on if you prefer snapshot or dynamic views. Snapshots were much easier on the network, at the expense of consistency. I also remember the CC team could work magic at optimizing things if you gave them time and a bit of flexibility. Crappy config specs were hard to read, and often slow to work off of. Any config spec that I had to scroll...I knew I was in for a shit week.

I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was amazed at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of "bug fix" or "special customer branches". Oh, and likely 2 or 3 on-going major version dev branches. Somehow, it all worked. If you could describe (by whiteboard or hand-waving) what you wanted to see as your working branch, it could be done. "Give me a view that is exactly what customer x has, but for this directory, give me latest, except for this file...I want that one from customer y" . And blam! The CC guys would make it happen. The magical config spec. I have had to dabble in many other SCMs.. SVN, Git, etc...and they all seemed to be a compromise. Or, just ran out of gas when the going got tough. In my mind, I wish I could argue that ClearCase was where it was at, and the patterns it supported would be wonderful to have today...especially over Git. But I don't know enough to defend the point. All I am saying is that even with enormously complex version scenarios, the damn thing didn't break and we all got our work done.

The compressor doesn't move any air inside the refrigerator. There is a separate fan in the freezer compartment that does that.

Thanks. Scar tissue sometimes breeds insight. In further conversation on this phenomenon, I would argue that "long lived databases" are not so as result of brilliant design. Rather, it happens because the database itself is neglected and largely misunderstood, and gets less investment. And they live on and on...managers come and go...no investment. And then, years later, some poor bastard is stuck with a hideous mess that can't go anywhere. Don't let this happen to you.

If I publish a stored proc as an API, it leaves me free (within reason) to alter the actual SQL supporting it. Like modern API design, as long as you don't remove functionality, then change it as required.

I would be having words with the DBA about this. If there is a DBA. No DBA I would hire would allow this silliness. At least not in the actual application schema.