They aren't leasing. What they are doing is buying blocks of minutes wholesales and reselling them retail:
A units of 100k minutes M-F 8-6
B units of 100k minutes nights
C units of 100k minutes weekends
D units of 1m SMS
E units of 2t data
F DIDs

Then they break this up an sell it retail. I don't know that they actually have much of an advantage over the in-house providers. Sprint for example does most of its business on the wholesale side. AT&T does a lot of wholesale. Verizon doesn't like the wholesale side but PagePlus still has millions of subscribers.

As for separate and competing infrastructure. That's a different problem though some of the MVNOs allow you pass between infrastructure. For example they might use T-mobile where it is available (cheap) and AT&T where they can't get T-mobile.

What you are proposing exists for cellular as well. http://en.wikipedia.org/wiki/L...

Capturing information is useless unless you can access it. Systemd logging does require special decoding.

And there are already several of these decoding programs, plus libraries so that adding support to existing editors won't be a problem. Ergo that is not an issue today and will be less of one going forward.

A version-compatible log reader facility, however, stands a very good chance of not being so easy to get.

Why wouldn't it be? Libraries already exist. So what is going to stop this from being part of most Linux editors and thus most open source ones? Just boot from CD-ROM.

If I sound extreme, it's because I've spent a lot of time with various binary loggers and have found them to be counter-productive on the whole, and especially frustrating when things have gone to hell.

On mainframes and minis? This is going to be a standard system. It is going to be well supported. The situation isn't comparable.

Why introduce a middleman, especially for something that - as I said - needs to be easy to get at in times of emergency?

Well for one thing the middleman is going to be capable of making it easier to get. Moreover the middleman introduces lots of additional functionality which will make the logs easier to use. Also emergency is not the primary use case. Emergency / hardware failure is something that is less important in the world of virtualization. The actual hardware OS doesn't do much and the virtualized OSes will be accessible.

But this is yet another example where a bunch of designers replaced something that was very functional with something new, shiny - and missing critical functions

journald supports text export so it does what you want. The fact that you don't know that should give you pause in your analysis. That being said syslogd doesn't have basic logging functions like indexing, security / verification, ability to prioritize.... It wasn't functional. Certainly it is possible that syslogd is a better fit for you, though I doubt it. But even if that were the case a better fit for you and a better default for everyone on the planet are not the same thing.

Did you miss the second sentence?

That's not "lack of diligence", that's a fundamental bootstrapping problem. CA's are meant to verify identities. If the identity you are trying to verify is not itself cryptographically verifiable, then the attempt to verify can be tampered with, but the only way to solve that is to use harder to verify identities. Which is what EV certs do, and my own experience of getting one was pretty smooth.

You might think I'm exaggerating, but even major corporations fuck this up all of the time. There is no "just choose sensible defaults and give me a secure socket" call, because if there were someone would complain that it's not secure and shouldn't be used.

Sure there is. Perhaps not in C but what did you expect? Here we go in Java:

HttpsUrlConnection conn = (HttpsUrlConnection) new URL("https://www.google.com/").openConnection();
Certificate[] certs = conn.getServerCertificates();
InputStream stream = conn.getInputStream(); // read stream here ....

That'll do the right thing by default.

SSL is imperfect, but that's because crypto is hard, not because of some fundamental fuckup somewhere and if only we all used the alternative protocols (which?) everything would be peachy.

Yes, but exploited browser rendering engines have been a large source of infections too. Sandboxing mobile code is just really hard. However the web is indispensable whereas Java applets aren't, so Java is the one that gets thrown out.

I suspect there isn't any way to build support for Java applets that satisfies Google's policies, therefore, they will end up being restricted to other browsers for the small number of people who need them (mostly enterprise apps).

These days the Java sandbox is actually a lot better than it used to be. Last I heard there had been no zero days this year at all. However, the Java update story still sucks, and Sun/Oracle have made Java supremely unpopular on Windows thanks to the crappy update nags and bundled adware. So nobody will be sad to see it go. Java is moving to JRE bundling for distributed apps anyway: I've written one with the new tools and it basically works like a regular desktop app, with a native installer / package on each major platform.

To heck with the local charges - why the hell hasn't Holder's Justice Department filed federal civil rights charges against the officer? They're rabidly on the side of SJWs. Think about it for a moment. If the facts were there, do you really think the JD would be sitting on the sidelines while some local grand jury no-bills the case?

And I'm pretty sure that is not their job

Absolutely it is their job. They are obligated to exercise due diligence in a prosecution. Any attorney presenting witness testimony they don't find credible is grounds for disbarment. For a prosecutor it is much more serious because they are held to a standard of diligence they don't have to just find the testimony not non-credible they must actually find it credible.

There were multiple witnesses saying that Mike Brown had his hands up and was not attacking Darren Wilson when he was shot

The problem is those witnesses were discredited by the investigation. Their statements contradicted physical evidence and some admitted they had fabricated their testimony when crossed.

I just don't understand how with the witnesses that have come forward, they couldn't find enough evidence that maybe there was wrong doing to want all the evidence to come out so we can have answers.

The prosecutor is releasing all the evidence.

The prosecutor presented all witness testimony. All of it. And he most certainly did present that evidence, he also presented why he didn't find it credible.

Actually in this case the prosecutor declared the case closed so sunshine laws apply. We know what evidence they saw though we know nothing of the deliberations.

If they are wrong then there is no indictment. What does wrong have to do with it?

There's too much secrecy in the system.

What secrecy that the EFF wouldn't see. A certification agency doesn't need secrecy. In theory the EFF could be the one to generate the private key and run that on a server they control. That might be an excellent way to build trust, that it runs on EFF hardware.

Yes, we are living with that contradiction right now. The elections confirm it.

How does the election confirm that we have: A widespread belief there is privacy and at the same time he government violating that privacy through monitoring and frequently acting on the information? I'm not following at all.

So the main problem can be solved just with systemd not running as pid 1 but running only as service supervisor. Is that possible?

Actually that's like of what systembsd and systemd-shem do. So yes it is possible. The question is whether the systemd-shem team can keep up with the systemd people and so far no they can't. Same problem that everyone has had. The systemd group is:

a) really good
b) really big
c) has a mandate to do a lot.

On the other hand the Docker people are creating a containerized version of systemd that doesn't depend on systemd and unlike the other two groups that one is adequately funded. So that might solve the problem in terms of ways of handling the dependencies in theory. Debian is not gong to create a hard dependency on running Docker infrastructure so it doesn't solve Debian's problem however.