I don't think anyone said anything about the proton's mass, just the radius.

A difference of 4% in the previously measured mass would be a much bigger story.

The radius, on the other hand, has much less significance -- it even depends heavily on an arbitrary definition, since a proton doesn't have a definite boundary.

Thanks!

And since we haven't discovered how the neuron depends on quantum mechanics to work (like how we've discovered how chloroplasts do just this past year), we need more physics too.

I'm not saying you're wrong, but that's a really, really bad argument. It basically boils down to "we don't completelly understand neurons, therefore we can't possibly build an intelligence that's at least as good as one based on neurons".

You have already given an example of why exactly it's a bad argument. We've only recently discovered how quantum effects play an important role in photosynthesis[1], but that didn't prevent us from building photoelectric cells that turn sunlight into usable energy (more efficiently than plants, by the way) before that.

The point is that we have no reason to believe that we'll have to to mimic neurons closely in order to build an AI. Other people already pointed that we have built things that work better than the human body (even though we don't completely understand the human body), and your answer has so far been "mechanical things are simple". That's a huge cop out: they're "simple" because they've been done -- can you imagine convincing a physicist from the 1700s that building a flying machine is simple?

Now, maybe AI is really not "simple" like that, maybe it's actually impossible without closely mimicking a neuron -- but nothing in your argument gives any reason to believe that.

Footnote [1]: I know the studies that have shown the quantum effects on photosynthesis by some bacteria, but nothing that uses chloroplasts. Do you have a source, or were you just referring to photosynthesis in general? (I'm not trying to be pedantic, I'd be really interested to read about studies like these in more advanced forms of photosynthesis).

That's a fair point, but you have to pay closer attention to what Carmack wrote:

I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.

The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.

He said functional programming style, that doesn't necessarily mean using a functional language -- the point is that he is going in the direction of functional style when writing C++, which would involve, among other things, making as much as possible immutable (hence being a "const nazi").

It's sad that this is modded so high; it's completely wrong.

A requests a secure channel to B from C. Instead C establishes a secure channel with A *claiming* that it's B, while also establishing a secure channel to B claiming that it's A.

You're describing a MITM attack, which is prevented by SSL and TLS by using certificates -- C can only fool A into thinking it's B if C knows B's private key (in which case, C has essentially stolen B's identity).

What happens in Nokia phone's case is that the browser happily trusts C to forward things to B without looking at what's being transmitted (the browser accepts C's certificate authority).

Yes, I found that extremely confusing.

I think he's using the term "watered-down" to mean something like "with increased volume", but of course the usual meaning (what you find in the dictionary) is exactly the opposite: "diminished in force or effect".

The fix might be as easy as having the ability to see all reviews by each reviewer.

On Amazon, that's already possible; just click on the name of the author of the review.

There is absolutely no value in having random people review things.

Any sufficiently articulate reviewer can give me very valuable insight that helps me decide whether I'll likely enjoy a science fiction book from an author I've never read, for example.

You might have a point for reviews that are meant to deeply analyze high literature works. For most books sold on Amazon, what you wrote doesn't apply at all.

If you read the second link in the comment that started this thread, you'll see that

On average, elite male soccer players -- who often use their heads to direct the ball -- had a range of negative changes in white matter architecture compared with a group of competitive swimmers who were unlikely to have repetitive brain trauma

I think they picked the control group from professional athletes because they are more likely to have similar lifestyles. Even so, the authors of the study are cautious and note that

differences in head injury rates, sudden accelerations, or even lifestyle could contribute

So, like MightyMartian said, obviously researchers do their homework, otherwise their papers would be ridiculed during peer-review.

It's undeniable that microkernels open very cool possibilities, like the ones you mentioned.

But my first point was that, every time someone makes a microkernel that has to compete with the kernels we have today, they end up doing all kinds of compromises ("hybrid" approaches) which end up with all sorts of drivers (network, disk, graphics) in kernel space. Anything else just slows things down too much, to the point where very few people would want to use those kernels.

And, to be honest, while the kinds of things you mention would be useful, crashes in drivers for mainstream hardware are very rare, so there's very little practical reason to try too much to mitigate their effects. Unless, of course, you count gaming graphics cards (their drivers do tend to crash a lot) -- but in this case, trading a lot of performance (and if you remove the graphics driver from kernel space you do lose a lot of performance) for the ability to recover from a crash is really not what you want.

a kernel mode component can crash the system and leave no trace of what did it. Like pre X MacOS or DOS.

... and Linux, NT, and the Mac OS X kernel (XNU).

NT and the Mac OS X kernels are interesting cases: they started as microkernels, but soon moved on to "hybrid" approaches that keep a lot of drivers inside kernel space.

Everybody knows mircrokernels are slower. They are more stable. Misbehaving drivers are identified quickly. They usually have fewer issues and the issues they have don't take the whole system down.

That sounds great in theory, but if a disk or network driver crashes on a production server, how much do you care that the rest of the system is still working? These things must not crash, period -- if they do crash, the state of the rest of the system is usually irrelevant.

you definitely are an idiot.

That's great to know, thanks! I look forward to more varied insults.

An #include influences the linker just in the most trivial sense that it changes the code seen by the compiler, and so it changes the compiled code seen by the linker. The point is that there's nothing magical about "stdio.h" that requires one to #include it; everything that can be done with #includes can be done without them. I keep repeating this point because I'm still not sure you understand it.

You at least *did* realize that your previous point about code compiling but not linking is complete and utter nonsense, right?

I know what it does you idiot.

Ah, so you've finally realized you're wrong, and now are resorting to ad-hominem attacks...

That's fine, as long as we're clear that it is possible to write any C program as a one-liner, and #include is just a text-processing directive that doesn't influence the linker.

One more time: #include does exactly what I said: it just includes a file verbatim (I can't believe you haven't taken the time to check this, after all this time in this discussion). This means that, after you resolved all #includes, you can then proceed to put the contents of that result in one line, ant the result will be a one-line program. If the original program compiled and linked, then the one-liner also will, by construction.

Now, to the point of missing struct declarations:

If I am trying to link to something that takes a pointer to a struct and I don't include the headers for it, the linker won't work. So, with it the linker succeeds and without it it doesn't.

In your specific example, it will either fail during compilation or during execution, never at link time. That's because the information about return and argument types is gone by the time the linker runs (it might be present on debug sections of the object files, but the linker doesn't care about those). So, if the compiler is happy with the struct declarations, the linker will happily work -- even though the result might be undefined and crash during execution.

What happens when your function returns something other than int and you don't declare it first?

What happens is undefined behavior, according to the standard. But now you're changing your story.

In response to my examples (both of which are completely valid and contain no undefined behavior), you wrote nonsense like "It might compile, but it won't link, ergo it's not a valid program". Now you're trying to sound as you were talking about general programs.

The whole point is that #include does nothing magical that influences the linker. It's *exactly* the same as inserting a file verbatim at the #include point. Which means you don't *need* any #includes in C (in particular, they're not required by the linker). Ergo[1] it's possible to write any C program in one line, keeping in mind the limitation about the minimum line length the translator is required to accept, which I explained earlier.

Good luck learning C!

That's very funny, you gave me a good laugh!

[1] I can try to sound smart, too :)