Yet the Mac survived despite similarly being a proprietary design, it wasn't until Windows 95 came out that the Mac became technically inferior -- MacOS 8 and Windows 3.1 were pretty comparable technically, but Windows 95 had real multitasking and while it crashed a lot, so did MacOS 8.

The reality is that Commodore was mismanaged was mismanaged from the day Tramiel left. I doubt Tramiel could have done much better -- see his track record at Atari -- but he was replaced by idiots who had no idea how to run a computer company.

Disclaimer: I interviewed at Commodore as an engineer in early 1991. The product they were working on at the time was the CDTV. Just looking at the prototype I could see no point to it -- it was too expensive for the big box retailers to sell as a game console, and at the time they weren't interested in selling computers (this was before you could walk into Walmart and buy a PC). I ended up going elsewhere and adventuring in non-computer-related fields for a while before getting back into computing with Linux in 1995, releasing our first commercial product for Linux in June 1996 (a school administration package ported from SCO Unix and which we sold as part and parcel of an administrative solution to school districts including computers, terminals, and administrative software). Linux brought the fun back into computing that died with the 1980's, it was an adventure there in the late 90's. Now it's just a job, but I'm older and okay with that.

The C64 was basically the Arduino of its day. For budding hardware hackers, it had lots of parallel I/O pins right there on the back of the computer, accessible with a simple card connector. I controlled a calibration oven for directional drilling probes with the thing in the late 1980's, using a custom BASIC program to run the analog to digital converters via bit-banging pins on the CIA (the parallel I/O chip). I also used it for a weather radar system used on offshore oil rigs, that one was mostly 6502 assembly code and again bit-banging data on the CIA. The computer came with a complete hardware schematic that basically encouraged doing things like this. I even designed my own cards to plug into the "cartridge port" for doing various things.

Yeah, it sucked as a computer. But it was a hardware hacker's dream toy. There wasn't anything like it ever again until the Arduinos and Raspberry Pi arrived around 2010 or so.

No it didn't. You could replace ROM libraries with disk-based libraries without a problem at system boot. The only libraries that had to be in the ROM were the disk libraries (else you couldn't load libraries off of disk, duh) and even there, you could replace them after boot. There was a standard API call to get a library handle, that API call didn't care where the library lived, whether disk or ROM, it looked on disk first, and only then did it look for the library in ROM. In fact, workbench.library lived on disk in the very last Amiga 4000 variant because there wasn't enough room in the ROM for it. That said, in the days before systems with 96 gigabytes of RAM, replacing a ROM to upgrade your version of AmigaOS made more sense than using precious RAM to hold copies of libraries. Remember, large numbers of Amigas only had 1 megabyte of memory (I had to scrimp and save to buy a 4 megabyte board for my Amiga 2000) and most never even had hard drives.... I did add an 80 megabyte (!) SCSI hard drive to my Amiga 2000, but the drive plus controller cost almost as much as the computer at the time.

Windows 95 wasn't any worse from a customer point of view than the Amiga. Both crashed regularly for the same reason -- lack of memory protection. The Amiga was the only pre-emptive multitasking consumer OS before Windows 95 (I don't consider OS/2 to be a consumer OS, its hardware requirements were far higher than a consumer OS, it was a business workstation OS). Once Windows 95 brought that to the Windows world, there was literally no reason for the Amiga to exist anymore -- everything it could do, Windows 95 could do, maybe not as elegantly but for a much lower price.

Thus why the Amiga technology basically died with Commodore -- oh sure, various companies bought the intellectual property over the years, but none of them invested any money in it to bring out new computers. There just wasn't any business logic to doing so in a world that contained Windows 95.

Exactly. So why do you recite a valid criticism of FileVault1, which had exactly the problems you mentioned due to it being layered as a DMG on an unencrypted filesystem, as if it applied to FileVault2, which is an *entirely different technology*?

Once upon a time, like ten years ago, File Vault encrypted home folders as a dmg file on a partition. That is no longer the case and has not been the case for years. File Vault doesn't work like that anymore, and it hasn't worked like that for years. Now it's whole disk encryption like Microsoft's Bitlocker, and utterly bulletproof. The only way to lose your disk is to overwrite the key blocks at the start of the disk.

Technology moves on, man.

I still have most of the Commodore 64 code that I ever wrote, even though the computers are sitting in my brother's attic 2,000 miles from here and the disks are long gone. As I've upgraded platforms I've pulled in my files from the previous platforms, and now we have emulators so I could even run the programs again if I wished. This obviously isn't going to help with things that had a hardware component like my card for interfacing a Commodore 64 with a 1571 disk drive at full 1571 speed (wire-wrapped, naturally, and using a ROM simulator SRAM chip to hold my code), but (shrug). The whole need for that is really not there anymore since a simulated 1541 is ridiculously faster than the real thing was.

I would use an Arduino board with a Bluetooth adapter to do all the grunt work, and use the (Android) smartphone just for the user interface, talking to the Arduino via a Serial profile. We do something like that in ham radio nowadays to interface APRS with Android tablets, with the Android tablet providing GPS coordinates to be outputted as ham radio packets to the APRS system, and accepting GPS coordinates sent via packet radio from the ham-radio-interfaced Arduino to display the call signs of surrounding ham radio stations on the Android tablet's display . (Can't do it with iDevices because Apple won't open up access to the Serial profile).

The capacitors are easy to replace. The chips are fat and happy NMOS that are somewhat static sensitive but otherwise pretty indestructible. The big problem with the chips is the 6526 CIA, which is the parallel port chip that is likely interfaced with the balancer machine. Those tend to pop if you stare at them wrong because the raw digital lines go directly from the CIA pins to that port on the back with no (zero) buffering, and it's been quite a while since they were manufactured. I used to pop them all the time when interfacing my wire-wrapped gadgets to my Commodore 64 and our local Commodore repair center knew me by name and when I came in the door immediately went in the back and got a 6526 out of his tubes of spares to sell to me. That was, of course, thirty years ago. Today they can still be found on eBay as pulls from recycled machines, but with the normal caveats of buying recycled components from eBay -- i.e.,. most of the time the seller has no way of testing them, so what you get may or may not work.

Err, no. The SID chip is on the motherboard of the Commodore 64 (the schematic is even in the technical manual -- want to see my copy?) and is mixed with the television signal out the RF port on the back, or is available as a pin on the 8-pin round audio-video connector on the back of the Commodore 64, from whence it can go into a 1702 monitor (via an 8-pin to 8-pin cable) or broken out and sent to a powered speaker (via an 8-pin to RCA breakout cable, which also allowed hooking to a normal composite monitor). The 1541 has nothing to do with sound.

Back in the day, the Commodore 64 was often used for industrial applications like this where the cosmetics of having a trash computer were outweighed by the cost savings of using a common off-the-shelf piece of hardware that had a bunch of easily controlled digital I/O lines hanging out on a card edge connector on the back. In the late 80's I had a contract to write software to display weather radar on a C-64 screen where the resulting consoles were deployed on offshore oil rigs talking back to the homeland over 1200 baud radio modems. I also had a contract to do the heat and magnetic calibration on directional drilling probes, where the signals from the drilling probe went through an analog to digital converter and were then bit-banged in over the parallel port lines on a Commodore 64.

Today I'd probably use something like an Arduino for things like that. But that of course didn't exist back then.

Tell that to the arbiter who is being paid by the Big Bank to arbitrate your case :).

You can bet that these contracts have forced arbitration in them -- you must agree to forced arbitration, or you don't get your severance pay. Because that's how evil banks roll.

So why is that bad? Well, consumers win 40% of the time when they sue a bank in court. But if a consumer instead is forced into arbitration because of a forced arbitration clause in the contract, consumers win less than 4% of the time, according to a study of arbitration decisions in California. I.e., forced arbitration basically means you signed away your right to sue in any meaningful way -- and the Supreme Court has upheld those agreements as fair and reasonable, so you can't even appeal to a "real" court.

Apple gave fair warning to vendors that they wanted sandboxed applications to be the standard for the platform. Sandboxed applications do not run out of system directories, they are basically "jailed" in their own sandboxes. Microsoft, like most software vendors, ignored Apple. So now the vendors are reaping the rewards of what they sowed.

The bigger problem with El Capitan lies with virtualization and VPN software. These need to make changes to the system routing and interface tables to properly route packets between virtual machines and the Internet, or between the local host and the other end of a VPN tunnel. El Capitan breaks our VPN at work and I have advised our employees to not upgrade to El Capitan due to this fact until Apple and VPN vendors come up with a solution to this problem. I certainly am not going to advise employees on how to disable Apple's security system (SIP), that would be lunacy on my part akin to telling employees how to disable virus protection on their Windows laptops given the increasing threat level for Macs recently.

In the end, we need more secure systems, and Apple is providing one. The fact that it breaks existing applications and inconveniences users is unsurprising. It would have been surprising if that *hadn't* happened -- which is one reason why consumer operating systems are so insecure (because making them secure breaks so much stuff).

Yep. Microwave fade. It's inherent in ultra high wavelength transmissions. That said, we have modulation techniques today that have effective error correction, unlike back in the day when this was all done with FM and you ended up losing data when you had poor conditions. Think about how your mobile phone gets massive bandwidth and reliability out of OFDMA (LTE's downlink technology) under much worse propagation conditions in city canyons, and scale that to microwave frequencies.

That said, given the bandwidth limitations of long distance microwave technology and improvements in fiber technology over the past five years, it seems to me that this is a solution whose problem is already on the way out. NTT has fiber that can transmit 69.1 tbit/sec over a 240km distance. Out here in the West you can put towers on top of mountains to get line of sight for that long of a distance, but practically speaking you won't get line of sight for more than 100km or so in the flatlands without an enormously tall and expensive tower. The network between Chicago and NYC mentioned in the paper has towers every 70km and runs at 400mbit/sec. Clearly fiber can do that distance, and with much better bandwidth.