Why don't we separate the configuration interface from the init system?

Patch upstart to include the ability to read in the configuration items of a Systemd system and either run these services in a compatibility mode or automatically generate its own configurations from the Systemd configurations.

Hint: one of them terminates init. The other restarts it. A highly consequential distinction.

It's not possible for a user process to kill -9 on init. The kernel will pass only SIGHUP or SIGINT. "kill -9 -1" effectively kills all processes except init. Traditionally.... init would then respawn all processes in the init tab marked as respawn for the current runlevel, so it would bring the local VTY gettys back online, but not daemons such as inetd and SSHD which are started through scripts that do not have respawn lines in the inittab

Personally; I always thought this was quaint... this is one of the reasons why I like Solaris SMF --- the possibility of automatic self-healing applies to ALL services, not just the gettys.

Kill -1 is like an emergency "Oh Shit"; and you're going to need to do some serious manual repair efforts and probably reboot shortly after, as only things managed by an init respawn will automatically restart.

Really? You don't reboot after a kernel security update?

One word: KernelCare

I think the answer is to fork Redhat EL6, and not accept the choice in RH7 of moving from Upstart to SystemD. Upstart and Udev in RH6 is just great....

Good news, everyone... just like with Agile I have 10 years experience with reactive methodologies.... we just called them something else back then, now that we have a name for reactive methodology, we can claim it :)

Then comes people with missing one arm/hand bashing that idea. Making that configurable to be used with one hand kind of defeats the purpose, no?

If someone with just one hand/arm gets convicted of texting while driving holding the phone with ZERO hands available to put on the wheel, then that is so much more dangerous and unsafe, that they should just be forced to undergo the standard punishment; or give up driving or having a cellphone altogether.

Your point? ABC/NBC/Fox/etc are not Canadian companies, they still have to comply with CanCon rules within Canada. Netflix is operating under an exemption from those rules right now.

Netflix is not a broadcaster/Television company. They are a subscription internet service that streams video over the internet or ships DVDs for rental on demand.

As such, they do not need to license any spectrum or broadcast rights, as their transmissions are in private over the telecommunications network. And they are essentially an equivalent to an online "All You can Eat" DVD/Video rental shoppe.

Last I checked, video rental shoppes and other businesses besides broadcasters are not subject to regulation in regards to what their video library can carry.

There would be fundamental free speech rights violations in attempting to dictate what a store or information service should carry.

No, it means they "can" not that they 'will".

No... it means they say they can. They cannot legally confiscate property without due process contrary to the 5th amendment.

Because dealer franchise agreements give individual dealers a defined geographical area in which they are the only sales outlet for that particular model. And that contract language is difficult for manufacturers to break*. Tesla had no such agreements in place.

Well, if it doesn't suit them, they'll likely just revise the language, or allow the agreement to end at its expiration date, and terminate the contracts; if they don't suit the manufacturer.

This. Hardware specific keys are the killer for any forensic attempt. It makes breaking a copied image totally impossible

Apple obviously has an image that is not locked to specific hardware, when you take a backup. As it's possible to restore to a different device!

The law can just send Apple an order to deliver THAT version of the image.

You can restore that from iCloud (or wherever you stashed the backup if it ain't an iPhone) one would think, then punch in the passcode once that's done.

Then law enforcement can get a warrant drafted to order Apple to hand over a copy of the backup image and instructions to decrypt it, assuming they discover the passphrase.

So much for "wipe after 10 attempts"

How does a copy of a drive image wipe itself after any number of failed attempts?

Ideally, if the actual key encrypted with the passcode is stored on a tamper-resistant hardware chip, so the "image" will not contain a vital hardware element needed to produce the actual key.

And 10 failed attempts results in the chip memory contents being "zapped"

Instead of providing just one global canary.... more canaries, so the identity of which canaries were withdrawn, could be used to help ascertain the nature of the request(s) received.

They should also provide each user their own 'custom' canary.

For example: an option to receive every month, every quarter, every week, or every day, a personalized canary statement that "Apple has never received an order under Section 215 of the USA Patriot Act which included information related to your account records. We would expect to challenge such an order if served on us."

Yes.... I just wish they'd make it a "graduated" scale and tier the subsidy. 10 megabits complete build-out and availability to all prospective customers over at least 1 square mile - Subsidies capped to mb+contiguous miles 1 to 10% of maximum.

20 megabits complete build-out and availability to all prospective customers over at least 10 contiguous square miles - 11 to 20% of the maximum (for that area).

30 megabits complete build-out and availability to all prospective customers over at over at least 20 contiguous square miles - 21 to 30% of the maximum (for that area).

40 megabits complete build-out availability to all prospective customers over at over at least over at least 30 contiguous square miles - 31 to 40% of the maximum (for that area).

50 megabits complete build-out availability to all prospective customers over at over at least over at least 50 contiguous square miles - 41 to 50% of the maximum (for that area)

60 megabits complete build-out availability to all prospective customers over at over at least over at least 60 contiguous square miles - 51 to 60% of the maximum (for that area)

70 megabits complete build-out availability to all prospective customers over at over at least over at least 70 contiguous square miles - 61 to 70% of the maximum (for that area)

80 megabits complete build-out availability to all prospective customers over at over at least over at least 75 contiguous square miles - 71 to 80% of the maximum (for that area)

90 megabits complete build-out availability to all prospective customers over at over at least over at least 80 contiguous square miles - 81 to 90% of the maximum (for that area)

100 megabits complete build-out availability to all prospective customers over at over at least over at least 85 contiguous square miles - 91 to 100% of the maximum (for that area)