silverbacknet

That was also the era when DBMS locking was iffy, so competing inserts/updates would happen once sites got too busy, and everyone was encouraged to turn off transactions (or, on MySQL, just use MyISAM instead of InnoDB) and put it on XFS or even tempfs for speed.

So many websites I remember came back up with "the last two weeks of posts are gone, sorry" or just shut down for good because it was all too corrupted to fix, and so were the backups, if they had any.

This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.

I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.

So many of the quotes feel like pure projection. The guy makes up little fantasies about everyone he spied on, even assuming his tales are true, he certainly doesn't interview them afterward to see if he guessed right or was way off. For every fact there's a lot more deep ruminating that would be more at home in LiveJournal than a sociology study, but it was his journal, so I can't really fault him for that.

If it's true, it's an interesting peek into his mind, and confirmation of some public vs private social mores, but all the pontification on society and morality and futility is just so much old man yelling at clouds.

I hope the author can come back to tell us whether he did comparisons with different speed presets for BPG; it ranges from insanely fast to insanely slow, and that's probably just the default.

I don't feel like that page is entirely fair.

The PNG and GIF comparisons are unfair; they're the same low resolution as FLIF, but given nearest-neighbor upsampling instead of bilinear. Most web browsers use bilinear or bicubic upsampling for progressive pictures now, so FLIF isn't nearly as unique as it presents itself. Aside from that, progressive is only useful if you're on a slow connection or the file is broken; in other cases re-rendering multiple times becomes a bottleneck and battery drain. In general it's rare that progressive decoding is a win anymore (although progressive encoding of JPEG is always a win).

In another comment I pointed out that jpeg2000 can be encoded to any size, even 1k, even though the q-scale doesn't go that low, by using the target size parameter instead. It looks better than anything but BPG and is fully progressive. Of course, J2K is a dead format outside of DejaVu, PDF, and the medical field, but it serves as a useful baseline.

A comparison to JXR would have been nice; it's an open, patent-indemnified format that fully supports progressive decoding, and compresses about as well as WebP. That format's the biggest disappointment for me, I thought it had everything in place to displace JPEG.

BPG could be made somewhat progressive, but only by changing the underlying HEVC bitstream, while one of its goals is to stay as close as possible. The inclusion of a thumbnail is the only recourse.

He didn't try hard enough. OpenJPEG has a file size parameter, which can go well below its -q 0 size. I was easily able to generate a 16.9K jp2 by specifying the size: https://dl.dropboxusercontent.com/u/54412753/doom9/fish.jp2 which in png looks like: https://dl.dropboxusercontent.com/u/54412753/doom9/fish.jp2....

Looks better than anything else but BPG at that size, to me, although FLIF obviously isn't optimized for lossy.