You're right insofar as changing from a SysV-style init to SystemD obviously presents opportunity for boot failure.

However, to me that would logically mean that you have broken/unimplemented SystemD unit files. So either fix them or wait until someone else does. It's not an argument against SystemD, it's an argument against bugs and/or poor transition implementation. I would point to the Windows XP x64 switchover as a prime example of that. Despite which, x86-64 is ubiquitous now.

I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.

...Or you could /technically/ break the file up into blocks with each one being as large as the key modulus, but then you've got the issue of reassembly so this is typically only used in situations where the data is read, verified and then written to another location (such as in the case of a firmware update)

A PGP signatures is a signature of the computed hash of the file. Otherwise you would need to have a key modulus as big as the file itself, which is clearly impractical

Copyright of the Linux Kernel is actually spread across all its contributors, The Linux Foundation doesn't have any overriding ownership. Though of course any particular author(s) code could be excised from it in order to make their copyright irrelevant.

In any case though, the copyright holders get to determine what licenses or permissions to grant over the work, they don't get to then decide how the license should be interpreted - that's up to an arbitrator or a court. If Canonical's lawyers are incorrect in their interpretation then someone will need to bring a court case to have it resolved.

a score of 5 for this tired old ignorant shit? Alright, let's get cracking.

RA, aka. ICMP router advertisement. Abandoned circa 1970 as a "bad idea". It was a colossally bad idea in the 90's, and f'ing suicidally bad in 2000+. Yeah, let's trust whoever the f*** on the cable claims to be a router and send it our traffic. Oh, to protect my network(s) from that brain damage, I have to buy new switches that support "RA Guard"

Right, because DHCP totally solves spoofing problems yeah?

They didn't like DHCP. So "no f***ing DHCP in IPv6!" DHCPv6 is a bolt-on, staple-on, and bandaid addition to IPv6. It's a horribly incomplete shadow of DHCPv4, and still requires an RA tell you to use it.

No it isn't. You can do practically everything that DHCPv4 does with DHCPv6. Yes you should send an RA, so what? DHCPv4 is as much if not more of a bolt-on than DHCPv6 is (in so far as it's absolutely not part of the protocol stack whatsoever)

SLAAC... originally 80bit prefix plus 48bit MAC. They ignored the fact that ethernet is not the only technology in the universe. That was later amended (breaking older stacks) to 64bits. The entire purpose for the vast over-simplification of address selection (for tiny embeded systems with limit RAM/ROM/CPU) became moot 7sec into the IPng committee's existance -- IPSec shoots all three in the head, repeatedly, with artillery. Everything supports privacy extensions these days, so the logic for random address generation and duplicate address detection is there -- and rather trivial. Yet it, and SLAAC, demands the prefix-length be 64. Just to put that silliness in perspective, that's a single LAN with every ethernet device ever created (that will ever be created) in it 65,536 times over.

Just to put YOUR silliness in perspective: the remaining number of bits is 2^61 (within 2000::/3 obviously) which comes to 2,305,843,009,213,693,952 /64s. Get a damn sense of perspective. As far as "older stacks" go... clearly not anything seriously used in production today.

This leads nicely into the blindness to history... a 64bit LAN is pure lunacy. Today and likely for several decades. But we "have an infinite amount of address space." Actually, NO, it is, in fact, quite finite: 128bits, to be exact. If we carve it up with the same pez-like abandon as the early IPv4 assignments, it will be even less "infinite". Sure, we can change the way we do things "with the next ::/8", but that dooms us to live with the colossal stupid of this ::/8 for ever. Again, dooming us (and our children's great grand-children) to live with our bullshit. We did a lot of stupid things with IPv4; and we're doing them all over again with IPv6.

No, your failure to grasp the scale of numbers is pure lunacy. If we somehow manage to fuck up 2000::/3, there's several times the size of the current global IP space waiting to be spun up with the flick of a pen, so we have plenty of opportunity to make mistakes.

That's an April 1st RFC, it's not serious.

...Good time to lament the disgusting treason of the colonials against the British Empire

"amplified the DNA"
Sounds Legit.

No, it's really stupid. Take two species of plant, pollinate one with the other. BOOM, genes from both plants are recombined to form a new unique plant. genetic modification.

They do get to know what is in the food, all the ingredients are right in the packet. the operative word in GMO is the G - if you'd like a full readout of the genes of whatever it is you're eating, go take it to be sequenced - it matters not one iota to your digestion, what does are the proteins, starches etc that are expressed (or not) as a result of those genes, and the information is right there on the packet.

according to a commenter elsewhere, they apparently phoned SOCA's press office and asserted it to be genuine, so, perhaps I stand corrected.

whois indicates the original owner still controls the domain, the server itself is Rackspace owned whereas SOCA's own website is run themselves via Connect Internet Solutions Ltd. - throw in the fact that SOCA haven't made any announcement or press release regarding the alleged takedown and the whole thing looks like a setup, I call shenanigans.