In fact, the assumption that cognition is computational or mechanistic is where the mind-body problem comes from (right from the 17th century). If it's all just syntactic, then explaining semantics is now a problem, and you have problems like dualism. Non-algorithmic doesn't mean magic, by any stretch. If you don't assume algorithmic, then there is no mind-body separation about which you can have a dualist stance.

If you think that the universe in general is algorithmic, e.g. that the evolution of the sun is an algorithmic process, then we might easily only disagree about terminology. Those who do not follow computational theories of mind might say that the complexities of intelligent behavior are more like the complexities of the sun than anything you will get out of a turing machine.

There are a frightening number of different issues once we go into details, and there is a long history of people attempting to address them. I don't think a slashdot thread is capable of holding it all. And of course, the more one learns the more one realizes that the answers are far fewer than the questions.

You're making a *huge* assumption that humans operate algorithmically, which is exactly the problem being discussed in the debate between Searle, Dennett, Haugeland, and others. Getting a handle on "understanding", or more specifically the origin of meaning, is the larger question that these folks are addressing. So you're entirely correct about needing more than intuition, and that is what people have been trying to do using these means for many, many years.

That's funny, using sudo for administration always makes me think of ubuntu, speaking of noobs in the basement.

Seriously though, I don't like giving a regular/admin user easy access to root like that. If my user password is compromised by some means, the sudo thing means root is also compromised. I'd rather have the authentication and environment separation.

I have a Chinese Room that wants to talk to you.

All NAT devices have a stateful firewall; tracking state is how NAT can happen at all. If you remove NAT, you are still left with a firewall with rules to deny inbound connections unless initiated from inside.

That is, the security you're talking about is not provided by NAT, but by the firewall underneath NAT. That's not going anywhere.

That was the plan, but it was walked back by draft-ietf-v6ops-3177bis-end-sites-01. I still like rfc3177 and think everyone should get a /48, but who knows what we'll actually see people do.

I can imagine devices in the kitchen wanting to communicate to each other, but not wanting to hear from the garage door. The reasons for keeping separate broadcast domains in general will apply to the home when many, many devices are IP enabled. The topology of these domains could be organized automatically by the devices as well. Really no one knows what demand for IPs and subnets will be in the coming years, so it's good to think in terms that allow for growth. That's how I think, anyway.

Give rfc3177 a read, especially section 4. That RFC is obsolete now, but the math hasn't changed.

These numbers are ridiculously huge, and it is intended in the design that subnets would normally be sized at /64. Thinking of that as 18 quintillion addresses is thinking like IPv4. IPv6 is different, and you think in terms of subnets. There are also (since an address is 128 bits) 18 quintillion /64 networks. If we give each person on the planet 65536 /64s (that's a /48) then we have enough for 5000 times the current world population in the current pool of addresses, which is 1/8th the full IPv6 address space. If you use the whole space, then it's 40,200 times the world population.

A /48 is actually 65536 times bigger than a /64 (2^(64-48)), but it's still reasonable to give home users that much. Only 4 subnets is extraordinarily restrictive. Think many (actually probably not that many) years down the line when you have subnets per room and such. I'd want my kitchen to be on a different subnet than my garage, for instance.

Assigning a /48 for end users is still the recommended thing to do. Some ultra-conservative types are planning on /56 instead. I expect ISPs assigning /64s to go out of business (maybe that's hope).

It was probably just a typo, but to help those who are reading...

HE gives you a "6in4" tunnel, which transmits ipv6 packets encapsulated in ipv4 packets. The names are confusingly similar, but 6to4 is a different technology that uses ipv4 to ipv6 address maps. The 192.88.99.1 anycast address is indeed 6to4.

The problem with *stateful* firewalls in front of servers is that you can DoS the link without coming *close* to using all of the bandwidth. The state table has a finite size, and it doesn't take many packets per second to fill it up, depending on how long it takes for state entries to expire.

Additionally, since a server is there to handle unsolicited requests, there's not much point in tracking state anyway.

Stateless ACLs are what you want in front of a server, not a stateful firewall.

There are metallurgists and steel workers, and you're right, seems a lot of people go into cs now to be steel workers. I noticed this even at a school known for cs, many years ago (hmm, and steel too). I'm sure a core of metallurgists will remain though.

Amen to that. With 400 line grub config files, there seems to be this auto-complexification syndrome in Ubuntu. Not using the gui has become something for the advanced only. It's not really tinker friendly, and I think has become rather windowsy in that regard.