I don't think anyone claims that Uber should not have insured drivers or should permit their drivers to discriminated by race.

What they do claim, is that it's ridiculous for the city to have a fixed number of medallions for drivers, instead of letting anyone that meets the (insurance,inspection,background,...) checks compete under the same set of rule. The sad fact in a number of cities is that possession of an arbitrary token is more important that substantive comliance with an objective set of requirements.

With a dozen or so lines of code you can convert any services that listens on a socket (UNIX, INET, NETLINK or POSIX) to have systemd create the socket and pass it in -- and that includes code to fall back to socket creation if it's not launched by systemd. This has a few benefits:

• Startup: Services don't need to signal back init systems that a service is ready to receive requests (or, worse: I've seen colleagues either put in a sleep, or having dependent processes poll, shudder). As soon as the socket is created, requests can be received. When the process is ready to read/select, it gets everything in the buffer.

  In fact, while a ton of people are focused on the way systemd manages dependencies between startup processes, they overlook that socket-passing actually removes dependencies between them. In other words, even if you have some horribly complex web of socket-based services, you can treat them as entirely independent.

• On-demand-services: Got a socket service that doesn't have tight startup latency requirements and is launched infrequently like sshd or ntpd? Why does it have to stick around all the time consuming resources? Let systemd hold the socket and launch it whenever a client connects and just exit() when your last client goes away. Apple has been doing this for years -- aggressively reclaiming memory from daemons that don't need to be immediately available. This also improves startup times because non-essential services aren't launching at the same time as essential ones, decreasing CPU/IO thrash -- I've seen admins create init-groups that launch 5 minutes after startup for this purpose actually, this solves the issue more sensibly.
• Crashes: Services that crash obviously lose all session state, but having the socket persist means that requests never get rejected -- they just wait a bit longer. For a concrete example, if Apache relies on SQL and then SQL crashes, obviously any in-flight queries are going to return errors. But new queries launched by different Apache worker threads will just sit in the socket buffer until SQL comes back to life. This is a pretty big win for mitigating client impact.
• In-place-updates: Services that need to be updated/patched are just a different manifestation of the "Crash" bullet above. Need to patch your services without killing all its clients? Stop processing new requests, fulfill everything in the queue, restart, pick up where you left off. Unless the client is closely monitoring the latency of requests, they won't even know that the service was patched underneath them.

So that's at least one thing that systemd brings that other init systems don't, that solves a few real problems and enables some new features that other init systems can't.

Actually systemd doesn't care if it's actually running yet or not, because it already created a socket listening on port 80/443 (or whatever) and passed it to Apache. If anyone tries to send something to 80, it will be queued in the socket's buffer, and once Apache finishes its startup goo, it will process the backlog.

In other words, there's a third state in between "Not Ready" and "Fully Ready" which is "I'm ready enough to receive and enqueue requests without dropping them but I can't fulfill them immediately". Once a service hits that state, no one should care any further.

[ Bonus round: if Apache crashes, that's fine too because systemd keeps the socket around and passes it to the relaunched instance with all the pending requests intact. Which actually means that it never goes to "Not even ready to receive requests" even on crash and all requests are seamlessly processed. ]

Administrators dislike constraint based systems. ...
it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself.

First of all, it's about a dozen lines of code in the daemon to be able to query if you've been passed in a socket and, only then fall back to creating it yourself. And that's backwards compatible. There's example code totalling no more than a single page.

Second, Administrators ought to love the model of daemon's receiving the socket because it actually removes constraints entirely, instead of just managing them. You're correct that admins dislike constraint-based systems instead of imperative ones, but removing the constraint is even more favorable -- an real admin should love nothing more for the applications to sign a contract that says "You can launch me and my dependencies in any order and we will Do The Right Thing(TM)". Socket activation does exactly that.

Yes, when you get to the front of the line you should pay attention to the instructions. In the meantime, while you are waiting to get to the front of the line, there's nothing to pay attention to.

If you've got a recent iPhone, it's already randomizing the MAC used for background scans:

When iOS 8 is not associated with a Wi-Fi network and a device's processor is asleep, iOS 8 uses a randomized Media Access Control (MAC) address when conducting PNO scans. When iOS 8 is not associated with a Wi-Fi network or a device's processor is asleep, iOS 8 uses a randomized MAC address when conducting ePNO scans. Because a device's MAC address now changes when it's not connected to a network, it can't be used to persistently track a device by passive observers of Wi-Fi traffic.

Of course, that doesn't work if you are using the phone to read Twitter while waiting in line, because seriously, what else are you expected to do while shuffling along?

And you can regulate the person doing the selling and the car he's driving without favoring one person over another or empowering a cartel.

Falling into the "regulation-bad" "regulation good" dichotomy is really killing us here. Regulating the driver's record, the vehicle and his insurance is eminently sensible. Beyond that, it's just protectionism.

I really don't have any problem with any of the requirements you've listed at the end there, so long as they are administered objectively and impartially. They all seem unobjectionable.

But providing favorable treatment to some licensed taxi companies over others -- such as the use of taxi stands and spaces -- rubs me as unjustified favoritism.

Your bit about "without proper credentials" makes it sound like all that's needed is for a driver to apply for a license and meet some objective requirements like driving records, vehicle inspections and insurance. If that were the case, you'd have a lot more folks siding with the law.

Instead, in order to pick up a fare in Amsterdam, you need to meet some other arbitrary requirements, chief among them being a member of a TTO ("Regulated Taxi Organization") with at least 100 cars. And to pick up a fare from a taxi stand in Amsterdam, you need a further license -- one given at the discretion of the municipality for "professionalism".

So there we have it -- there's a whole set of common sense regulations that are applied and that anyone can meet based on a set of objective criteria. Then there's another set that got "glued on" which makes no sense at all. So ditch the latter, and soon you'll find there's no reason for uber at all.

[ But hey, at least it's not as bad as the US medallion system ! ]

Straight keyboards are really poor ergonomically, but I do love the mechanical feel of these old IBM models (and their newer imitators).

Might as well use this as an impromptu Ask Slashdot: are there any ergonomic one-piece mechanical wireless keyboards out there? I periodically Google for it (to replace an old Logitech one that's nearing EOL after a decade or so) but have never been able to find anything suitable.

Perhaps stories like this will make clear what the costs of disabling code signing really are, to be weighed against the incentive to disable it ...

Pistols, however, are used by criminals, by people committing suicide, and by kids playing around with them. As a direct result, over 30,000 people die every year after being shot with a pistol.

This is an example of a truthful but not useful statement. Yes, 30,000 people die every year as a result of being shot by a pistol. According to the CDC, in 2010 there were 11K firearm homocides and 19K firearm suicides.

That's a big difference in perspective, since a regulation that might be justifiable to prevent an individual from shooting his wife or neighbor might not be justifiable to prevent him from shooting himself. It's not dispositive, of course, but society has a much larger interest in preventing individuals from killing each other than killing themselves.

Do these bags simultaneously keep the phone powered on while preventing the internal clock from advancing? If so, I think there's some folks in Sweden that would like to award the creator some very nice jewelry.

Too bad for "standard forensics" that the passcode is mixed in with a hardware-specific key baked into the SOC. So you'll first need to be able to run arbitrary code on the individual's phone itself in order to keep guessing beyond the limit. That's going to require a significantly more intrusive examination.

Self incrimination has never applied to physical evidence that the individual has in his possession, it only applies to things that are "testimonial" (quotes because this is a term of art). After all, the 5A specifically talks about being a witness against one's self, not about providing evidence. See also Fisher v. United States, 425 U.S. 391 (1976), Schmerber v. California, 384 U.S. 757 (1966) and United States v. Wade, 388 U.S. 218 (1967).

The classic example is business or tax records related to fraud prosecutions. An individual served with a valid order cannot refuse to turn over documents because they would tend to incriminate him, that doesn't make sense. You can't force the individual to testify to anything, but you can compel them to produce physical objects that you have probable cause to believe are evidence relevant to the prosecution of a crime.

Another canonical example is a court order forcing an individual to provide a cheek swab for a DNA test. Again, not testimonial because it's not communicative in any way -- you are just talking about physical, tangible evidence.