phkamp

The (only) solution is for people to care about quality in computing.

There's still too much money to be made on kludges for that to happen.

(Author of the essay here)

It is discussions like this which make me truly admire Douglas Adams for his insights and ability to express them.

For instance, when I read through the debate here, I can't help notice how many of the arguments are really variations of "It's a bypass! You've got to build bypasses! Not really any alternative."

The alternative ?

You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>.

Then you could eliminate all the other autocrap checks which come out one and the same way on every single OS in existence.

And in all likelyhood, you would find out that you don't actually need autocrap at all, because the remaining two checks can be done with an #ifdef instead.

I think you misunderstand my essay.

Yes, autoconf was clearly a response to the incompetence of the UNIX industry, were everybody thought they could become Da Man over everybody else.

But that doesn't mean that it was the right solution then, and it certainly is not the right solution now.

And autoconf is absolutly nothing like a cathedral: There is no archtectural vision, no economy of style, no consistency and absolutely no symmetry or simplicity.

Your argument that "autoconf [...] is [...] rarely run" is akin to saying "I only pee in the shower in the morning": That is of course better than doing it all the time, but it is still going to stink.

For everybody ? No.

But some minority have to take the open SOURCE seriously, if we want it to actually work.

I'm part of that minority.

The fact that Apple indicates that they would be able to produce such a software version is in itself a backdoor in the iPhone.

Yes.

Varnish author here.

I'm several sets of information short of being able to say anything particularly precise about their results.

Their diagnosis is very detailed and useful, but I think the main thing we can learn from it is that the Linux kernels VM system is horrible when memory is overcommitted. At least to me that's not news.

I will also say that we in the Varnish project have not worked much on performance the last couple of years, because people have asked much more for features than performance.

Some of the stuff we have done have traded CPU cycles for flexibility, but if the Varnish users change their mind and decide performance needs a boost, we can do that too.

The reason we dropped sendfile(2) in Varnish was that nobody seemed to be able to show any credible performance improvement, and dropping it allowed us to implement on-the-fly processing of the HTTP bodies in a cleaner way.

We can certainly bring sendfile(2) back for "the straight" path if that's important to people.

The "file" storage was our first rather primitive storage engine and it has never been optimized to any extent. Varnish Software Inc. has a commercial offering that includes a "massive storage engine", but most people seem to just use the 'malloc' storage.

And no, Varnish is not dying just because BBC doesn't use it in the absolute far corner of high-end usage doesn't use it: If NGINX is the better tool for them, they should absolutely be running NGNIX.

I don't think anybody doubted they would sign something in Paris, and that is baked in, but the actual content wasn't known until after market close on friday.

Professional traders will have diversified away from fossil stocks due to the uncertainty, but on monday they will either jump back in, or stay even further away, depending on their take on the agreement.

We'll see on monday when the stock exchanges open if this agreement actually matters.

If Oil/Coal companies tank: Yes

If not: No

Always follow the money.

Given the fate of TLS3 I really don't see that as much of an endorsement ?

The NSA leadership would be utterly incompetent if they have not planted people in the FOSS world.

(I gave a talk about that, google "Operation Orchestra")

That is exactly how it was done during the 1960'ies: The duration of atomic seconds varied from year to year and it proved utterly unworkable for everybody.

They are very low (motor) power, so they need to run often, in order for the grass not to grow too tall.

Here in Denmark they usually run at least three times a week, but very often every day of the week.

How many hours they run each time depends mostly on the ratio of the lawn-size to the mower-width.

Don't worry about what I can do to mitigate my problem, I have the electronic and RF skills+kit to deal with this.

My point is that John F. Consumer will likely conclude that his "radio controlled clock" is dying, throw it out, waste money on another one, and maybe never make the connection to his (or his neighbors) lawnmower robot.

And more importantly, that if popular enough, such (badly designed) signals will eventually make VLF timekeeping useless for everybody.

That was mostly because the were (perceived to be) an economic threat to some very big industries, it had very little to do with electro-magnetic radiation.

It is not obvious to me that emission limits are being exceeded here, and I don't have a calibrated antenna which would allow me to decide one way or another.

But even if emission limits are not exceeded VLF-based radio-clocks near the loop will still have much more noise to contend with.

You should have bought a "Rugby" clock in England. Many of these clocks come in four different versions: Japan, Europe, UK and USA, depending on which signal they use (JFY, DCF77, Rugby, WWVB)

DCF77 works OK in Denmark, provided you don't have too much local noise (switch-modes, old televisions etc. etc.)

DCF77 is indeed not a protected broadcast in denmark, despite the fact that an awfull lot of public infrastructure uses it for timekeeping.

The modulation type for the lawn-mower is digital current pulses with no bandwidth limiting, as is obvious from the scope signal I conveniently included for your and everybody elses information.

As for what exactly goes wrong with DCF77, that is pretty obvious from the two spectrum-analyser traces provided by that signal: It gets overloaded with AM noise which the simple AM-discriminator receivers used in clocks cannot deal with.

And you think NSA with their enormous budget and a mandate to collect "everything" looks askance at the CA's and go "Nope!" ?

Really ?

How many of the root-certs that are in your browser by default do you actually trust ?

What objective evidence is there, that any of them can be trusted ?

So what you're saying is that because you disagree with me, I'm a terrible person ?

Needless to say, I don't agree.

How many mentions do companies get in national constitutions ?

They're not mentioned one single time in the US or the Danish Constitutions, yet, both countries they more or less run government now.

UN's human rights don't mention them either.

Companies have no claim to human rights, like privacy, because they are not humans.

And if you think all humans, no matter what, should have a universal, unabbridgable right to privacy: Vote in your elections, and if nobody is worthy of your vote, get yourself elected instead.

But right now there are fully valid laws that says certain classes of humans do not get privacy, and the government which enacted those laws are legit, elected and have every right to enforce their laws.

Right now, the biggest problem is the unlimited invasion of privacy done by transnational companies accountable to nobody.

NSA could, in theory, be reigned in by the government, but nobody in the world has the power to stop the transnational companies deconstruction of everybodys indentities.

For instance, I have never agreed to FaceBook's terms and conditions, but they track me, like everybody else.

So we have established that your factual knowledge of varnish is severely lacking (and/or skewed) and now you just demonstrated that you have no idea who you are lambasting either.

Let me know if you ever want to have a fact-based discussion, in the meantime, don't get cold up there, on your high horse.

I gave a talk called "NSA Operation Orchestra" some time ago, I recommend you watch it, it might give you something to think about.

HTTPS doesn't provide authentication. It only communicates authentication, and that is from the untrustworthy and widely trojned CA-concept, which is as broken as it almost can be.

There are other, far better authentication methods for things like emergency services, and I'd rather have unauthenticated information, than no information at all anyway.

You also don't need authentication to stop ISP's being stupid, for that Integrity is all you need.

"Should we use HTTPS" is very much a closed question, and for a lot of sites the answer is a resounding "NO".

The fact that you might not use those sites doesn't mean that we who deliver tools for them can just ignore them, or even worse, impose our political agenda on them.

You can do HTTPS with Varnish if you want to, but you'll have to do it with the architecturally and security-wise most sensible configuration: With a SSL terminating proxy in front of Varnish.

And again: Talk to your legislators about peoples right to privacy, I'm just pointing out that such laws exist, I'm not writing them (or for that matter agreeing with them.)

I have a really hard time following your argumentation, because it seems to have very little to do with both reality and what I wrote.

What I did WRT moving people closer to the finish line was to implement the PROXY protocol, so that using a(ny) preexisting and well-tested SSL-termination solution works seamlessly with Varnish.

IMO, that is a far superior solution to adding a lot of security critical code to Varnish which, at the end of that huge effort, doesn't work any better.

As I wrote in my piece: "the world really don't need another piece of code that does an half-assed job at cryptography"

And doing a full-assed job only makes sense if you have the resources, competence (important with crypto!) and the result makes a positive contribution, one way or another, which offsets the cost of its production.

Nobody has yet been able to point out what the positive contribution would be, compared to a solution where SSL termination is its own layer.

Do you know something about that which I don't ?

If so, please share...

Right, so when you're guest at a company you have to install their CERT on your device to use their guest-wlan ?

If you're an employee you have to put the company CERT on your smartphone ?

How does that improve your security ?

I'm kind of surprised about this repeated "I just use nginx" argument, it doesn't make sense to me at all.

If your site runs fine, in all situations you care about, without FOO, you would be pretty lame if you increased its complexity with FOO nonetheless, for any value of FOO.

That is more or less exactly the central argument of the piece I wrote.

The KISS principle dictate that I do not add SSL/TLS to Varnish, because it would just increase complexity without any comparable net increase in benefits.

Yes, it's probably (slightly) more work to configure a SSL-terminating proxy and varnish, but that is the maximal benefit you can hope to obtain if I implement SSL/TLS.

On the other hand, having SSL termination in a clearly defined separate layer gives you at least the following benefits:

You can change implementation in one layer without affecting the other.

You can scale one layer separate from the other.

You can have different administrator access in one layer than the other.

You can scale the SSL layer for CPU and the Varnish layer for RAM.

You can have multiple independent implementations of your SSL termination, thereby vastly increasing the chances that you don't have to shut down next time some SSL library breaks.

&c &c &c

I have opinions on life on Mars ?