Hmm... cleaning staff walks off with a phone running a GPS tracker. Gee, how hard is it to tell a) who was in the office when it left the desk, and b) where the fuck it when from there?

(I've never understood the logic of stealing cellphones. A device identifiable and trackable by it's very design.)

It's a cellphone. Wrapping it in foil means it won't function as anything. You'd be better off a) turning it off, or b) leaving it on your desk (at the office or your home.) If you are "on call" then you are technically working, so that phone needs to be 100% functional and they have the right to track it. If you don't like being tracked on the job, then find a different job.

Depends on the quality of the recordable optical media. In fact, the same is true of pressed CD/DVD/Bluray.

You've completely missed the weakness of those initscript function library dependencies. In the handful of debian specific scripts I checked, all of them use at most 2 functions. They are all distro managed scripts, so it's not a surprise they all want to use "daemon" -- the most trivial shit in the world to remove.

The issue with systemd is not in how it starts or stops tasks. It is entirely with it's size, complexity, and the cancer-like scope creep of taking over tasks that aren't "starting and stopping" other subsystems.

Yes, rcS generally is just a stub to call "rc S", but not in all configurations, which is why inittab isn't: "si::sysinit:/etc/init.d/rc S"

Startup order dependency was "fixed" (for various definitions) by update-rc.d and language in the initscript header, like a thousand years ago. It's not perfect, but it does work. And for servers, a 100% predictable, repeatable, deterministic boot sequence trumps the 1.28s speed boost from the likes of upstart and systemd. For desktops, speed and flexibility are important, but troubleshooting a "random" boot order is a pain in the ass. (even moreso when upstart/systemd is eating all console output "for logging purposes")

./foo start and ./foo stop, perhaps??? An initscript is just a shell script. 90% of the initscripts I've written will work anywhere you have a somewhat smart /bin/sh. (the other 10% are targeted to specific distro's and will include shit specific to that distro, ugly, but that's what it takes.)

Plus /etc/rc.d contains /etc/rc.d/rc?.d directories, so the total is ~8x too many... 192 vs. 26 *actual* scripts on my machine. Looking at those 26 scripts, most of them use only 1 or 2 functions defined in the "library", and most don't need a library function for the task.

Only because inittab (what the traditional init does) lists rcS and rc as tasks. Change that and it can run anything you damn well please.

systemD... good luck purging that, as many other parts of the system are becoming dependent on it in increasingly complex ways. (for another really good example... plymouth in ubuntu.)

And if you bothered to look at what's in sysv-rc, you'd understand the "dep:". It's what created all the rc.d directories, rcS script, and rc script that actually enumerates and calls the rc.d scripts, and on various systems include the helper scripts update-rc.d and invoke-rc.d. Yes, you can run a system without it. But you'll be replacing it with almost exactly the same shell loop to process rc.d scripts, so why bother? (*cough*file-rc*cough* which is historically how BSD does things)

While we're on this horse... rcS is what calls all the scripts dropped by the initscripts package. (the equiv of a redhat rc.sysinit split into a bunch of files)

... or why AT&T couldn't tell what was what when he called. A call from local media, and the whole thing is figured out in seconds??? If it was "long distance", there'd be line items (i.e. each. individual. call.) on that bill.

Exactly. If there's a bug, fix it. Forcing me to "upgrade" to the next release (which may never be available for a particular device) is NOT the answer.

5.0 (and 5.1) have low adoption numbers because many people (me included) simply don't want that shit. I hate the new UI, and refuse to use any of the "new and more like facebook than ever" 5.0 gapps.

Aluminium is not found in a raw state in nature. It's an oxide ore that requires a fantastic amount of power to extract the metal. (i.e. break the O2 away so Mg has somewhere to go.) The sand used for glass, is pretty much right out of the dessert. (very little effort is put into splitting the Si from the O2)

Since when is kevlar transparent?

[is it] cheap enough to replace glass

Not even remotely. Glass is stupid-cheap to make -- and is made from the most abundant stuff on earth.

Adding someone to a circle doesn't magically give me permission to see their NON-PUBLIC posts. Plus, you can block anyone, and they won't see any of your posts. This is no different than facebook.

The entire problem was that it wasn't different from FB. G+ was just one in a long line of attempts to be facebook; and forcing everyone to "use" G+ certainly didn't make them any friends. So, the choice is Facebook By Facebook -- a system that's been around for a long time with relatively little change, or Facebook by Google -- who is well know for chucking things under the bus. Gee, surprise! Google's chucking G+ under the bus. Google simply cannot. leave. things. alone.