I believe Advantech will still happily sell you ISA backplanes. At the same time I put these things together, I had to reverse-engineer and fabricate some old I/O cards which had "unique" (incompatible with readily available cards) interrupt register mappings, also with EAGLE - great software!

I should mention: the MS-DOS system has outlasted three replacement attempts (two windows-based applications were from the original vendor who sold the MS-DOS system). There's just something completely unbreakable about the old stuff.

Many industrial computers have CF-card slots for this very application. I put together a few MS-DOS systems using SanDisk CF cards around 8 years ago and they're still going strong, using a variant of one of these cards which has a CF slot built-in (so no need for a CF -> IDE adapter): PCA-6751

Yes, that's a problem. BHL is really the go-to source for plant people I've worked with in the past.

That's true. People scoff at the older taxonomic groupings from before we had molecular evidence, but actually I'm often surprised at how similar new phylogenies are to huge chunks of the old taxonomies. What's more, at least with plants, one molecular study can produce quite a different looking evolutionary tree to another depending on what genes they used to compute them.

Which begs the quesiton... what's the ground truth? Data from classical taxonomy is actually extremely valuable. It can help inform molecular studies. It can be used to feed consensus trees or indicate which genes might yield certain phenotypes.

There seems to be many who think that with enough CPU power and algorithms we can turn any old meaningless garbage string of GATC into something we can pretend is useful. It seems like a lossy way of thinking... you can do interesting work without names, that's true - but the reckless abandon and total lack of scientific discipline when using names would never be tolerated in the "harder" sciences.

I dare you to pick up ten different papers using species or group names... and find even just one that cites the name in a reporducible, scientifically useful way (i.e. cites the taxnomic publication which specifies what they mean when they use the name).

I wouldn't ask Chrome to do anything more than it already does, which is to just do its job - help me navigate the web. I refuse to believe that a prominent domain part which yields the exact same phishing mitigation, and a visible path part are mutually exclusive things.

I am at a loss as to why you'd dismiss the ability to spot obviously funky URLs with a dodgy "but script injection vulnerabilities are browser-independent!" straw man; surely there's a stronger rebuttable to my thoughts than this.

Are you seriously suggesting that a prominent domain part and a visible path part are mutually exclusive?

And whilst it's fun to talk about redundancy between the <h1> text, title text and the address bar, it's also true that the address bar is the only one that's always visible in a consistent location that isn't lying to you.

There's obvious ways to shoot for the phishing mitigations that this is apparently seeking to achieve, without turning the web into an app store. We used to make fun of stupid flash sites due to lack of linkability, is it really necessary to so thoroughly lunge off the cliff into this idiocy now?

I wonder how many bad guys are already thinking of ways to exploit this. Yes the domain is more prominent, that should have been fixed years ago - but how many sites out there are completely free of XSS vulnerabilites? When this eventually becomes non-optional, how am I going to spot https://mybank.foo/?q="><script>evil; stuff;</script>

?

The perfect irony of course is that Google's own pagerank depends on cross-site linking... By robbing people of URLs, a future generation of net users will grow up never knowing how to share a page with their friends unless there's a sharing mechanism within the same site their friends already use.

BTRFS is so mature already, I never lost my data with it

Dude, nobody said BTRFS is mature. Did you read the part where I've had to manually rebalance several volumes on multiple occasions? I'm sorry that you interpreted this statement as a ringing endorsement of a mature filesystem - but it's not the case that users should have to do this kind of babysitting in a mature technology.

I *have* had BTRFS fill my logs with checksum failures on a couple of dying disks, and I was able to recover everything intact (the bulk of this data had shasums thanks to some deduplication I had been doing months earlier).ext4 on the other hand (by its very design, unless you count recent kernels where metadata may be checksummed) happily allows the disk (or whatever) to take a shit all over your data without so much as the slightest hint that something might be wrong until you go to open a file years later and discover it's zero bytes long, truncated, or full of garbage.

The data integrity features of the new file systems are nice only if you can assume them to be bug free.

No shit. But if your idea of data integrity is to start with something that doesn't even try, there just isn't any hope of that is there?

ZFS, and BTRFS are designed to cope with bitrot. Perhaps you believe the implementation renders the design ineffective, all I know is that ext4 doesn't even try.

I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data (btrfs has actually coped rather well with failing/dying disks in my experience), unlike ext4. COW, subvolumes and snapshots are nifty.

But too many times I've had the dreaded "no space left of device" (despite 100GBs remaining) when you run out of metadata blocks. The fix is to run btrfs balance start /volume/path - I now have a weekly cron job on my non-SSD machines - but it's hugely inconvenient having your machine go down because you're expected to babysit the filesystem.

Recent months of Docker usage has made me encounter this condition twice this year already.

I'll continue using btrfs because I've experienced silent corruption with ext4 before which I believe btrfs would have protected me against, and I like snapshots and ability to test my firmware images cheaply with cp --reflink pristine.img test.img.

It's even more amazing that it came from the guy who built Catalyst. But I guess he had to have that journey to create Mojolicious.

It's a shame that perl's taint mode is actively discouraged from use in production. At least from #perl lurkers. I've encountered a few almost-show-stopper unicode regex regressions that core perl devs just don't seem to care about - apparently there aren't enough people that care about taint mode enough among perl core devs.

Nothing the GP said was incorrect - perhaps you've misread it. I thought GP was referring to the FUD/backlash against KDE which lasted many, many years longer than the actual licensing dillemma itself (less than a year?).

So yes, politics/belief/FUD drove the creation of Gnome, and that mis-maneouver by Qt/KDE project - despite being quickly rectified - had repurcussions that lasted much of a decade, despite the indifference of pragmatic users such as yourself.

I've been a Gnome user since around 2001, to say things were pretty rough back then is an understatement... In 2012 I switched to KDE. I finally had a machine with 16GB ram to run it on (FWIW KDE seems slightly better at running on limited hardware now, but stil..) Its defaults made me angry, though (especially Konsole - seriously, no keyboard shortcuts to hit a specific tab? Tabs at the bottom [oposite edge to the menus and titlebar]?) but I can actually repair it a lot quicker than fixing Unity/Gnome.

It's been this long and they still can't make KDE remember the orientation/resolution/relative position of any monitor that isn't the primary one - if I'm going to suffer through that sort of thing I might as well give i3-wm a proper go. I was able to use it productively for a whole day recently, which is more than awesome and xmonad lasted for me.

A *lot* of funky SCADA software. In 2012 built another MS-DOS 6.22-based data acquisition server (which is still in use, along with the others) using incredibly overpriced (albeit reliable) bits from Advantech, 16-bit ISA cards and all. The application's last update was 1996, not quite 20 years but getting there. Slightly less ancient data acquisition software runs in parallel with nicer looking reports and modern export formats, but isn't as reliable. The DOS machine, as clunky and ugly as it is, just absolutely refuses to ever fail. And I can't say that disaster recovery in an environment without any internet connectivity (drivers? activation? updates? etc.) is any worse with MS-DOS: transplanting the windows software from one installation to the next is actually quite traumatic compared to "let's just dd this image to a new CF-Card and boot from that"...

Also, did some work last year on an impressively large website with many millions of hits per month whose codebase began circa 1997. I should tell them perl 5.19 has dropped CGI.pm from the core distribution, heh