Ok, that is a fair point. I had not seen that option before.

So rewinding a couple of steps to the part of the argument that led here:

Assume that a patch is created as an ed script, it does not contain any of the kernel code. Its only use is to transform the kernel source. Who owns the coyright on the transformed source that results after the patch is applied?

Please enlighten us oh great unix guru:

What type of patch does not specify which content is being deleted as part of the edit?

You’re confusing Vint Cerf with Al Gore. It’s easy to do, but try to remember: Al was the real inventor.

You’re not so good at reading are you?

Instead of projecting your ideas onto what somebody has written, try reading what they have written. What you are arguing against is not a varied dist.

Again, you seem to have missed the meaning of words.

“If people are eating a varied diet then they are spreading their calorie intake across different food types - not overeating carbs/sugar.”

Do you understand what varied means?

You do not seem to have understood the comment that you have replied to. If people are eating a varied diet then they are spreading their calorie intake across different food types - not overeating carbs/sugar.

You’ve never understood why the experience of being close to death is called a Near Death Experience?

That’s quite a naive assumption. There are no proofs that it is hard to unscramble. There was a paper last year showing it is not as hard as it should be.

I was not agreeing with you as you seem to assume - read it again. Duh

It will be competitive, but only on different metrics. Manual layout will win on size, performance, power efficiency etc, but the new approach will end up winning on design time. This has a larger effect on product cost and time to market for applications they are targetting.

Thanks for this - the most interesting thing I've read on slashdot in over a decade. The only point that I don't think that you covered is that as society moves further into specialized roles there are many people who simply do not rise above the threshold in any particular specialty - the statistics behind this are quite simple. Yet we need to maintain these "unproductive" people specifically so that we have a broad enough pool to avoid over-fitting what we focus on.

Just because it is possible to write good or bad code in any language does not mean that it is equally as easy to do. Some languages make it easier to write good code and some languages make it harder. This is why you should care if you use the software - choosing a language that makes it harder will make the work harder. For any project beyond a simple toy that will result in worse code and lower quality software.

In particular:
* Static guarantees rule out classes of bug.
* A well defined platform makes robust code possible.
* Simple language semantics make it easier to reason about behaviour.

How would you try and replicate the measurement over a period of time that has already passed?

Hmm I see that you are discussing a topic completely unrelated to the agenda that I want to push. ”It generally turns out” that I can shoehorn illegal immigration into unrelated discussions.

His overall message has not changed: the rate of progress will continue at an exponential rate of increase - when one technology hits its limit and flattens out into an s-curve another will appear that allows us to jump. Hence the ”curve jumping” terminology. But silicon has hit its limit, and there is nothing far enough through its adoption cycle to act as a replacement. The overall rate of progress for processors is hitting the top of its curve rather continuing using another technology.

If we see a shift in the rate of overall progress from exponential then it blows Kurzweils predictions out of the water, they all rely on the continuation of this same trend for several more decades.