No, Mod GP -1 inaccurate. Lotus 1-2-3 never ran on the Apple ][ family. It ran on the PC from the get-go. It was launched in 1983, not 1982.

Lotus bought VisiCalc in 1985, not 1986.

Excel didn't come out until 1985 (not 1984), and it was never ported to DOS. Its first appearance on a PC was as a Windows version in 1987. It came with a run-time version of Windows if you didn't already have Windows. Excel managed to kill Lotus 1-2-3 primarily because it was born as a GUI app and was native GUI all the way through. Lotus 1-2-3 stumbled on its way to the GUI, which allowed Excel to eventually overtake it.

Well, just because the missed advertising didn't affect sales yet, there's no guarantee that would continue to hold. Eventually someone would fill the advertising vacuum and they'd have a turf war on their hands.

Wow, that's some comedy gold right there!

We do something similar with our tool releases at work. The release notes indicate bugs that were filed on a previous release and closed with the current release, and if there are open issues what the open issues are. (Usually, it's something very obscure, otherwise it would be fixed.) We do something similar with chip errata. The errata document states which chip revisions are affected, and thus implicitly what chip revision fixes the issue.

Thus, we actually have a two tiered approach. There's the internal system(s) that tracks bugs against the actual development. So, if a bug shows up in a development version, developers and internal testers can file bugs on each other. All that noise has absolutely no business going outside the development team, as it's really just developer-to-developer communication. Then there's the customer issue tracking system. Customer-reported bugs get filed in that system, and they get their own ticket number, and it gets tied to a bug filed in the internal system. The customer bug reports are the ones we comment on in the release notes, along with any notable bugs we discovered in internal testing that customers may not have hit yet.

Disclaimer: My description above is a loose description of the processes we employ at work, and there is variation across teams and business units. It isn't intended to be rigorous. I'm only commenting on my team and teams I've worked closely with. The principle is the same, though. Our dirty laundry (the internal bug tracking system) stays internal. Externally reported bugs get tracked somewhat more opaquely, simply connecting the bug report to the release it's fixed in. It seems quite reasonable to me.

For me, both coffee and beer took a certain amount of acclimation. For coffee, I started out 'candying it up' with a ton of sugar and cream/creamer. And then one day I said "the heck with it" and started drinking it black. Within about a week or two of drinking it every day, I found I actually really liked it. Now you can't keep me away from it. I drink half a pot to a pot of coffee a day, and don't shy away from espresso.

It was a similar story with beer. I started out with really smooth beers (Red Dog was the choice for a fairly smooth, inoffensive beer at the time), and then one day I decided I was going to try all sorts of varieties whether I liked them or not. I started with the beer I had tried and liked least (Guinness Extra Stout—this was before they had the widget cans), and made that my exclusive beer for awhile. After a couple six-packs, I found I really appreciated it, and my palate was now open to a much wider range of beers. I've tried a few hundred different beers since then, and found it quite an enjoyable journey.

I think with both, there's the 'bitter' aspect to get over. Once you get past 'bitter', you can taste the rest of the beverage and enjoy it.

Try a Rochefort 10 sometime. It's a delicious (and potent) Belgian beer with carmelly goodness and very, very little hops to it. It's liquid candy.

When I tried to brew a clone recipe of it, the recipe called for a ton of Belgian Kandi sugar and grain, but the only hops were aroma hops added in the last few minutes of the boil. The clone came pretty close. (I think the differences were in the yeast, and the temperature profile during fermentation, really.)

I've actually visited a coffee plantation in Puerto Rico. The fresh ground coffee I had there was delicious, too. But, then, I voted for "bioengineer all the major vitamins," as I drink between half a pot and a pot of coffee a day. (It doesn't need more caffeine; I enjoy the flavor and too much caffeine means I'd get less of the flavor! But I also enjoy the caffeine so no decaf either, please.)

Or did you mean "everyone voting for Roundup Ready?"

You still need a way to mix a key into the result if you want a symmetric cipher.

In any case, certificate validation doesn't use SHA-1 as a cipher.

While that may be true, web browsers aren't using SHA-1 for encryption, especially for validating certificates. It's a cryptographically strong hashing function, but not, on its own, encryption.

What about an app that burns the bandwidth of playing a video as part of its 'preload', but never provides feedback that it's doing so? Is the user supposed to be clairvoyant?

And where on the label does the Facebook app say how much data it's going to use?

And how about the fact that for a long time, the FB app was fine, and then a change that FB pushed out to folks surprised them later only after they were using it?

It's worth remembering that not using the facebook app is supposed to hit facebook harder than yourself.

That's only true if there's a wide-scale boycott. Otherwise, network effects suggest you're wrong. It's like arguing "Not using Windows is supposed to hit Microsoft harder than yourself." BS. Microsoft hasn't felt a thing since I switched to other platforms years ago. I, however, have had to deal with incompatibilities and quirkiness. For the vast majority of users it never made sense to switch from Windows and it still doesn't, and the reason why is network effects.

Your arguments remind me of the 'Countepoint' guy from Airplane.

The issue here is that most smart phone plans make you, the user, responsible for paying for the total amount of bandwidth consumed, but the phone and the apps don't give you a good mechanism to allow you to act on that responsibility in a meaningful way. Saying "Well, then, don't use it" is unhelpful and unrealistic.

Ok, as explained elsewhere, this isn't autoplay per se but rather auto preload. That is, the video consumes bandwidth with no outward indication it's doing so. Again, do explain how the miracle of personal responsibility solves this.