knz42

- re. anonymous keys. There is no need for them to be part of the web of trust. If you really want them there it is then a common requirements for signatories to require at least a verifiable e-mail address bound to the person they know and are authenticating. But then arguably it's not very anonymous any more.

- re. multiple identities. cross-Signatures in the web of trust are done on individual identities, not the master key! So if you sign an identity and the key owner then creates another, that new identity will not carry your signature.

- re. key parties: so far it wasn't an issue because it was implicitly assumed that people attending a key parting were savvy enough to understand how to sign. For PGP to be democratized the concept of key party needs to evolve. I personally combine them with a small lecture on PGP use, and say "you get to sign each other only if you have attended the lecture including its small practical".

- re. software keys. These are typically considered as an extension to the developers' keys. You as a user shouldn't sign those.

Actually these topics are actively discussed at CS programs in higher education - MSc and higher. At least in the department I'm working at, the specific topics you name are very active conversation topics among students and faculty alike.

Patents count I believe ;)

This explanation subtly forgets to explain which agent is responsible for executing the contract-programs. Obviously you don't want the contract to be processed (and the money spent) two or more times at its deadline. Who is doing the processing and ensuring the execution only occurs once?

Have the workers own the robots, not the elite of company executives. Then redistribute the profits made by the robots to their new owners.

The idea of having the workers own the means of production is hardly new, it's just not very popular in the West. Not surprising that the NYTimes missed mentioning that entirely. It would be deliciously ironic if socialist China was the nation that would show the rest of the world how to deal with pervasive automation socially and economically.

The functional runtime (i.e. not compiler) is built upon an imperative foundation. This is necessarily so as long as hardware computer are built upon state-modifying processors and random access, in-place updatable memories.

> i'm saying we need to stop immoral behaviour when it is happening. we can't define morals in law, and the law is the only thing corporations understand. we can't change laws and retroactively apply them.

Two things:

a) you can definitely capture part of your morals in law, like "don't kill". Our anti-genocide legal system is built for this purpose and applies to corporations as well as to individuals.

b) at the time of the Apartheid, unlike during WWII, crimes against humanity were already prosecutable "anywhere on earth". In other words we can definitely prosecute IBM now for a crime they committed under a law that was already active when the crime was committed, and which has no statute of limitation.

The other “alternative” to Docker is SmartOS, which combines KVM with Solaris zones and ZFS.

Also relevant, an article from earlier this year: http://www.bibbase.org/network/publication/poss-altmeyer-tho...

About your last point: if you have a space elevator you can have a mass going down to balance for the mass going up, which reduces the energy needed merely to working against the friction on the cable and the connection point at the top. That's cheap.

After doing some research on "I also got attacked by PHK" I did some research and found this:

- you sent 2 e-mails to the Varnish-misc mailing list in Feb 2011 about the ESI-related bug you found (https://www.varnish-cache.org/lists/pipermail/varnish-misc/2... https://www.varnish-cache.org/lists/pipermail/varnish-misc/2...), which then remained unanswered

- but then you also tried to "help" another user in an unrelated thread "Lots of config" in March 2011 (starting here, https://www.varnish-cache.org/lists/pipermail/varnish-misc/2...), and PHK had a knee-jerk reaction (https://www.varnish-cache.org/lists/pipermail/varnish-misc/2...) to one of your "suggestions", a reaction that was indeed a bit vitriolic, but when read in the context of your other contributions to that thread, it makes a little bit of sense.

The article is well-written and makes a good point that scripting languages open new avenues for OS extension.

However the question remains whether Lua is the right candidate for the job, being not-so-open yet. Obviously the hacker cultures in NetBSD world and Lua world are still quite different, so I see no official integration in any foreseeable future.

A lightweight LISP or Scheme, on the other hand, might be a good candidate for a long-term implementation of the article's claims.

It's because they are ostentatiously making a lot of money while blatantly flaunting the law. This attracts attention, as much as Al Capone once did.

Except that to make a few diagram at the end required a lot of Wolfram code, although the model was very simplistic.

To me (working with complex models for work) I fear that complexity with Wolfram would shoot up to unmanageable levels once you start doing serious work.

Technically SMTP can be decentralized in the way you describe. Anyone can run a MTA. In principle a MTA should try routing messages through alternate routes to the destination if the first route does not work; also messages are stored on the way if some routes are blocked.

The fact people do not currently use SMTP in a fully distributed fashion does not detract from the fact that e-mail can be (re-)made fully distributed if/when need be.

"“If you have everything but land – if you have a population that is displaced – whether that allows you to be a state is a novel question,”"

Jews would have disagreed that this is a novel question -- for them the question has been about for around 2000 years if not more.

Emacs still runs on more platforms than VS and Eclipse, using fewer system resources, and is applicable to a larger diversity of programming / work tasks. There are not so many tools that are both that ubiquitous and long-lived.

Hey James, I know that most .NET/Windows programming has ALL-CAPS names but you should still write "OCaml" with small letters a-m-l.

Thanks for the link, I have added it in the references of my article.

I did not know that for was actually expanded early in the compiler and that one could print out the expansion with --pretty expanded. Color me enlightened. I have incorporated this, thanks!

You sir are a very patient and enlightened commenter. I am grateful for your detailed comments! I'll answer in detail in the reddit thread.

Thanks for the suggestion about side effects. I added a small sentence to that effect.

Thanks for those comments, I have incorporated them in the document.

The "stuff about boxing" has been discussed on the reddit thread, and I will have it fixed by tomorrow. Thanks for highlighting.

As to "Gc not being clever", the code is clear that it is intended to be clever in the long run, so the essence of the message could stay. Maybe the wording could be made more precise, thanks again for highlighting.

As to the "number of other wrong or slightly wrong things", I would be more than happy to fix the text if you have concrete remarks.

a) side effects are "masked" in Haskell in that a function that is generic over any type of monad may or may not incur side effects at run-time, depending on which actual monad it is used with.

b) see above - because monads as a type class exist, a function may be written with a type signature that does not indicate in any way that it will be eventually used over IO.

c) the fact that the Haskell denotational semantics are entirely silent over what happens at run-time with the IO monad is definitely a loophole. From a birds view, a Haskell program is a giant expression that reduces to an object of type IO, and what happens with that object is entirely outside of the language semantics.

e^(i * pi) + 1 = 0

In all fairness, the paper on which $100 bills are printed is quite worthless as well.

I think ever since people have stopped using gold and silver bullion (after arrowheads and knives) as currency items, there has been this consensus that money has the value that people give to it, not the value of its material (or, in BTC's case, immaterial) representations.

No C++ does not specify evaluation order in this case.

Remember "<<" is just that, an operator.

Only && and || have a mandated evaluation order.

Arguably the previous poster only mentioned he wants a 10GHz processor, not fast off-chip memory accesses. Also you can achieve a lot of performance in signal processing applications using a fast-clocked single core with on-chip SRAM scratchpads.

There are 3 physical reasons besides heat dissipation:

- size: higher frequency means you need smaller circuits, otherwise the electric impedance works against fast switching. There's a limit to how small we can build chip components right now.

- molecular stability: higher frequency requires higher voltage (to provide the energy), which in turns makes it easier for the metal oxide to degrade over time (this effect is additional to degradation due to heat)

- phase divergence: the digital circuits in our processors are heavily synchronized, and require components to react simultaneously to clock edges. However the propagation of the clock signal across the chip introduces errors in the signal phase. As the frequency increases, phase errors accumulate and cause circuits to "lose synchronization". To avoid this, one must increase the complexity of the clock distribution network greatly, which in turn compounds the effects above (and the heat problem).

All in all the current state of affairs is summarized by a rule of thumb (so-called "Pollack's law"): the speed (instructions/sec) of a single core processor increases with the square root of its complexity.

By this rule, to clock up from 3 to 10GHz would be a 9-fold increase in complexity, for which we don't have the technology ready just yet.