Though I never was aware of him before, I do use debhelper all the time. It's a shame it's come to this. For what it's worth, my impression is that he sees the recent GR proposal two weeks from jessie freeze as being the last straw for him in a long line of suffering from administrative/bureaucratic interference with getting real work done (don't know if he "liked" systemd, but it seems he wants the Debian project to stop wasting energy on debating it endlessly, especially given that endless debates were apparently already had last year).

For me, it's keyscript in crypttab which completely stopped my systems from booting. They're not keen to ever implement becase apparently shell scripts are intrinsically racy (for what it's worth my own keyscripts have a 10s timeout and fall-back to askpass if the crpyt token doesn't become available. I've never had one of my servers reach this time-out, the hardware config rarely ever changes). I wrote about some of the infinite permutations possible to support the use-case of just having a 4-line shell script, but it just seems that systemd is religiously opposed to shell scripts. Eventually, someone pointed out that I could pass keyscript args in the kernel boot parameters which seems to be a partially satisfactory solution for now.

For what it's worth, I do like the declarative nature of systemd for starting processes, socket activation etc. and I have migrated most of my stuff to systemd. It bothers me that debugging dependency issues is still so hard (ever tried "systemd-analyze dot"? the output is completely worthless as a debugging aid). Still, I am uneasy about the dogmatic anti-shellscript religion, I worry about the project's overall approach to security when simply accidentally running systemctl as a non-root user causes it to segfault, and it doesn't seem right that a change in pid1 should even remotely impact userland applications at all, let alone as deeply as systemd has.

At the end of the day, choice of default init system isn't going to make me switch from my favourite distro of the last 14 years (apart from a 2 year excursion to Ubuntu), but I think some of my own hostility toward systemd has been a result of the instantly dismissive remarks whenever I've tried to explain a problem I've had with it - by now I'm realizing that perhaps everybody is just too tired to tell the difference between a valid systemd complaint and yet another "get off my lawn" argument. In any case it's made me realize I should really diversify my tastes a little, currently playing with FreeBSD (again) and NixOS - that has to be a good thing.

Hey, um... what if dark matter is just heaps of rogue planets and left-over dust and gasses from nebulae? Given that we've only recently gotten a handle on how many rogue planets there are out there, wouldn't they've been left out of our previous calculations?

I actually can't tell if you're being sarcastic... but you've just described U2F. Whilst YubiKeys and other vendors do challenge/response, I think FIDO usage is typically one-time-pad mode. All other items are addressed (you can set a PIN to protect config and firmware updates, or finalize so it can't be changed ever again).

I eventually got submodules to work properly for me, and have been using them effectively (I think) for a few years now. But it's not easy teaching other devs. Which is why I need to spend some time investigating hg properly. Although you can do sparse checkouts with git, apparently hg has some plugins which allow you to partially clone a repo without necessarily cloning all of the objects in its history (supposedly plugins can fetch that on demand, rather than in the initial clone). It seems this is possible because git is designed around a data format, whereas hg is designed around an API. It all seems great but I just can't find the time to invest in hg

Oh, but it is. You just need to know how to refer to it properly.

I think he means that it's trivial in Gentoo to run arbitrary versions of any old library or dependency for the sake of a given application that is stuck in the past, not just package-pinning as we do in Debian-land. For example, I have an old gnuradio application that was written for gnuradio 3.6.x, but this was never shipped in any official release of Debian (it went gnuradio 3.5 in wheezy -> gnuradio 3.7 in jessie).

In gentoo it's trivial to have a specific old version of libfoo (and all the old, terribly specific versions of its huge pile of dependencies) installed along-side whatever passes for the current version of libfoo for the rest of your applications which aren't stuck in the past.

In Debian I had to re-build gnuradio from the 3.6 source, with much tweaking of the debian/control, debian/rules files and wading through debian-specific patchsets intended for gnuradio 3.5 or gnuradio 3.7, that don't apply to gnuradio 3.6. And all its dependencies. And suffer the fact that now all of the rest of my applications are forced to use gnuradio 3.6.

Oh, how embarassing.... the above post wasn't intended for you.

Other than being forced to type in 12 passphrases manually to decrypt each hard disk at every single goddamn boot, because custom keyscripts just "aren't the systemd way". Or spending hours figuring out why your Requires=network.target units inexplicably never start on boot, without a single shred of clue or evidence or event in any logs whatsoever, despite LogLevel=Debug and even though network.target clearly flashes by during boot and systemd-analyze clearly shows that it knows about this relationship with your unit and the service starts normally when you login and systemctl start manually. Or that tweaking your daemon args now requires a systemd daemon-reload as well as restart.

Yes, apart from all that, and the time saved now that admins will never have to see another freaky, alien shell script ever again because init systems were the only thing which used them, apart from all that... I'm hoping like hell systemd will hopefully one day buy me something other than more downtime.

The genes they identified were all proteins.

I'm not that much of an expert on microarrays, but I'm pretty sure most or all of the arrays they used predate the Encode project's results that made people re-evaluate the question of how much of the genome is really important. Here is a list of the arrays they used:

Illumina: HumanHap550, 318K, 350K, 610K, 660W Quad, HumanOmniExpressExome-8 v1.0, Human610 Quadv1, 370, 317, HumanOmniExpress-12v1 A

Affymetrix: GeneChip 6.0, 250K

This study was the keystone project of a consortium founded in early 2011. I think, given the size, it simply took this long to get the results. That, too, was a time before Encode publications had really started impacting the world. Whatever RNA genes they would have had at the time would be pathetic and paltry by comparison to what we consider worth studying now.

We know that the most important distinctions between humans and other animals are in RNA genes, that most of the genome is transcribed as RNA genes and that the brain modifies itself using them and that malfunctions in them cause disease. This study ignored RNA genes entirely, AFAICT. Its mindset is about ten years out of date and simply reaffirms what everyone already assumed: proteins aren't everything. Intelligence probably still has a significant genetic component, this study just looks in the wrong place. (Psst: SNP studies are snake oil in almost all unsolved diseases.)

For the same reasons your package manager bothers with shasums on the software you install even though the several network layers reaponsible for delivering it already faithfully checksummed each little packet as it flew past: the filesystem is the earliest and only point which knows exactly what files are supposed to actually look like in their entirety. That ZFS/BTRFS scrubs turn up errors on large pools with otherwise perfectly fine hardware means those block/packet level validations are at too low a level to make assurances for the higher level data structures using them.