No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
Then what do you suggest that identifier is? Can't use DNS because there is absolutely no guarantee that a host has correct DNS records (when was the last time you saw a home user create public DNS records for all their workstations?). And even if you could guarantee that the DNS records are correct, it still doesn't help when there is NAT involved since your DNS lookup (or whatever identifier you use) is going to have to resolve to a globally reachable network address, and no such thing exists when machines are hidden behind a NAT on local scope addresses.
The point of supporting/having NAT is to allow the network to be modular/segmented, so you aren't stuck waiting for a the last few people on the other side of the world to upgrade to the latest protocol, or having to wait for them to upgrade every one of their applications which depends on having 'IP addresses'.
You're not talking about network address translation. You're talking about protocol translation, which is rather different. And also isn't really possible to do in the way you're suggesting. Lets look at the IPv4 to IPv6 migration as an example:
Alice is on IPv6, Bob is on IPv4 (12.34.56.78), Charlie is on IPv6.
So Alice wants to connect to Bob. Since they have different protocols, there will need to be a protocol translation system involved (NAT64). As IPv6 has a larger address space than IPv4, a chunk of that address space can be mapped 1:1 to IPv4 addresses. So Alice takes Bob's IPv4 address and shoves the designated NAT64 prefix on it to turn it into an IPv6 address -::ffff:0:12.34.56.78. Alice sends a packet to that address, the NAT64 box gets the packet and translates it into an IPv4 packet. But Alice's address is IPv6 so can't go in the IPv4 packet so the NAT64 box puts its own IPv4 address on the packet and sends it along to Bob. When Bob sends a reply, it goes back to the NAT64 box, which looks up the IPv6 address associated with the connection (Alice) and is then able to translate the packet back to IPv6 and forward it along. So far so good, and all this really does work in practice and is in common use today - it works pretty well for simple client/server protocols such as HTTP.
Now, Alice needs to tell Bob to send some data to Charlie (pretty common in peer to peer applications). Here's where you hit a problem - there's no way that Charlie's address can be encoded within an IPv4 address. This means that no matter how you pass that addressing information within the protocol, when it is eventually translated back into an IP address to connect to, it is nonsensical - Bob has no idea how to connect to Charlie's IPv6 address. It didn't matter whether you passed an IPv6 address within the application's data stream, or a hostname that Bob's OS resolved to an IPv6 address - either way, Bob can't connect.
I'm sure you could invent a protocol extension whereby Bob can know to connect to the NAT64 box when he sees an IPv6 address and somehow hand the NAT64 box Charlie's address. But that requires Bob to know about IPv6, so it pretty pointless - if you're forcing Bob to implement new protocols like that then you may as well force Bob to upgrade to IPv6 properly.
Another option is that you could invent a protocol so that Alice can tell the NAT64 box to expect a connection from Bob and to forward it to Charlie. But now Alice needs to know lots of information about the NAT64 box's addresses (which you claim is always a bad thing), and more importantly, the NAT64 box could well now be subject to having to forward lots of traffic between two third party networks! That's not satisfactory.
It's so people can run what they want on their networks and still use applications that work across heterogeneous networks.
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
Eh? No it isn't. I don't need NAT now so I'll remove it so it doesn't cause problems. No reason why I can't add it back in the future if I either discover I need it for something or I go completely insane.
The disagreement is whether or not the recipient needs to know *IP* addressing information.
In the cases where NAT is a problem, the answer is an emphatic "yes", the recipient does need to know IP addressing information.
Sending application level data across the network 'encapsulates' the data in an IP packet. IP packets are NOT the application.
IP packets are not the application's data, no. But the IP addressing information is often needed so that it knows where to send data to. It doesn't matter whether you handle the IP addresses in the kernel or in the application, *something* needs to know where to send the data. If the destination machine is on the other side of a NAT then you're out of luck - you can't trivially send data to it (there are NAT traversal mechanisms but they aren't reliable for a number of reasons that are beyond the scope of this discussion).
Actually, people could, but they don't. What it would require would be to take something like SRV records. A server behind NAT would have to inform the NAT device that it is offering service X on port Y for domain Z. The NAT server would have to server up a NAT rule for an outside port A to map to the inside server on port Y. Then it handles DNS requests for domain Z and returns SRV records (or similiar) saying that if you want to reach service X for domain Z, connect to the NAT server on port Y.
You've now delved into the realms of redesigning NAT from the ground up - that's a silly discussion to have because the whole issue is that we're stuck with protocols that were not designed to cope with the current situation. If we were designing the internet from scratch with the knowledge we now have, we would have a bigger address space and NAT wouldn't be required... oh wait, that's one of the reasons we're migrating to IPv6.
I don't understand why you seem to want to hold onto NAT - I'm not saying "NAT is evil", on the contrary - it serves some very useful purposes. But when we switch to IPv6, most of that usefulness evaporates. Why would we want to hold onto a layer of complexity that is no longer serving a purpose?
Lets be clear on this: application data should *not* break if it's encapsulated in IPv4, and then unecapsulated, then re-encapsulated in IPv6. The application data should be separate from IP information just as it is separate from other encapsulation.
In simple protocols between a client and an a server you are correct. And in those cases, applications *don't* break if you do this. On the other hand, if your application needs to somehow tell the remote machine to go send data to somewhere different (which peer to peer protocols need to do, such as SIP, Bittorrent, etc) then you *are* going to need to communicate the appropriate addresses to the remote machine.
The ability to write directly to the memory of a data structure may be considered advantageous in some situations. Yet, a lot of people prefer object-orientated programming or styles with getters and setters which can manage this access. You may disagree.
And yet programming isn't exclusively object orientated. There are situations where object orientation would produce too much overhead. Hell, sometimes we still program in raw assembler! Same goes for the internet - the protocols that are broken by NAT are the protocols that cannot sensibly incur the overheads associated with running in a strict client/server architecture.
NAT has its uses, but it also has its problems. If there is no IP address shortage then *most* (not all) NAT suddenly has no use, leaving nothing but the problems. So in these use cases it makes sense to remove NAT since it is no longer doing anything useful and is a potential source of problems. This is not "demonising", this is simply looking at it in an objective way and realising that things can usually be improved by removing NAT from the equation.
I mean, seriously. We have networking traffic that moves from optical to wired to wireless, across all sorts of protocols and encapsulations, constantly. No one freaks out, no one complains.
There is a huge difference here. What you're talking about is encapsulation - this does not modify the packets a user's application is sending, it mearly puts them inside other packets. No information is destroyed - you can always get all the original data out by simply unencapsulating them again. And indeed, this is exactly what happens - an application sends an IP datagram and it arrives at the destination unaltered. The application has no need to care what has happened in the middle because any encapsulation that has happened gets undone again before it gets to the recipient. On the other hand, NAT destroys the original addressing information - what the recipient sees is *not* what the sender sent.
NAT only impinges the functionality of software because the software and protocols are badly designed
That is fundamentally not true. The protocols you are talking about (SIP is a common example) were specifically designed to do exactly that. It was not a design flaw, it was intentionally done that way because in a network that has end to end connectivity (which is the type of network SIP was designed to be used in) this actually has some big advantages, such as reduced latency requirements (this was a *really* important criteria for the use cases SIP was designed for), reduced infrastructure and bandwidth requirements (you don't need honking great servers forwarding media between peers).
Anyone interpreting these features as "bad design" is demonstrating a lack of understanding of the design goals for these protocols.
-- i.e. they insist on using IP information inside application level protocols instead of application-level identifiers (i.e. hostnames rather than IP addresses.)
Host names don't help. You can't magically route a packet to a host that is behind a NAT by knowing its hostname.
If applications do not break or fail to work because my traffic switches from wireless to wired to optical data transport, or because the encapsulation changes (ethernet frames vs. ppp vs. ATM vs. frame relay), then they should also not break because the network protocol changes (i.e. IPv4 to IPv6 and back again.)
Lets be clear on this: applications do *not* break if their IPv4 packets get encapsulated within IPv6 packets for part of the journey and then unencapsulated again. In fact, this is exactly what 6to4 tunnels do, but in reverse - IPv6 packets are encapsulated within IPv4 when traversing parts of the network that have no IPv6 support; applications do not need to know or care that this is happening since the data that comes out is the same as the data that goes in.
People blame NAT for the problems, but it is not that NAT *breaks* the applications, it is that the applications were *already broken* in design, and NAT just reveals the flaws.
Occasionally, yes, but in the vast majority of cases where NAT breaks things this is completely untrue. An application requiring the ability to send packets directly to a specific machine is not a "broken" design, rather, it is a design that has a lot of advantages. The disadvantage with this design is that it requires the remote host to be addressable, which i
Only real disagreement I have with you is your comment about network access being ubiquitous. For a vast majority of us, it already is via - at a minimum - 3G on a mobile
I frequently travel by train and I can tell you that 3G is *not* ubiquitous. I have frequent drop outs - its enough for a bit of web surfing so long as you're happy to wait 5 minutes for the signal to come back every so often, but I wouldn't want to work over it. Not only do trains pass through areas of poor coverage, they also pass through tunnels where there is *no* coverage. I also frequently go to reasonably remote parts of the country where there really is no 3G signal (e.g. on the Isle of Skye I get no mobile phone signal at all anywhere on the island). Another important factor is going abroad - with MNOs charging 10gbp per megabyte for roaming data, you can bet I expect pretty much everything to work without network access. 3G is also a bit of a battery hog, so if you can avoid using it you get much better battery life.
Modern computers are vastly powerful and have huge amounts of disk space, why on earth would we want to cripple them by tieing them to a network for things that fundamentally don't need to be done remotely?
Not sure why you seem so particularly offended by what is, essentially, a marketing term.
I get slightly annoyed at people using meaningless terminology to pass something that is no different to what we have already been doing for years as if it were new.
Not to mention that UPnP essentially reduces your NAT "security" to nil.
Not really... But the NAT bit is irrelevant here - UPNP can poke holes in stateful firewalls and NATs alike.
The reason why UPNP doesn't really reduce security in a home environment is because once you have malware inside your network, you don't need UPNP to open up holes in your firewall for more evil to flow through. Firewall traversal (and NAT traversal) are quite trivial procedures that don't require UPNP.
The solution to that is to do native dual stack. That way you don't break any IPv4 compatibility while using a clean approach to IPv6. Then, in the future, you stop giving IPv4 addresses once IPv4 falls out of use. The "IPv6 only" devices you speak of either don't exist or are completely niche, and they will continue to be uncommon until IPv4 dies out.
Dual-stack doesn't work when you've run out of v4 addresses...
Correct. But NAT does cause lots of problems, so getting rid of it where it isn't needed is a Good Thing.
NAT can be used to source many machines from the same address
Correct, but why would you want to if you weren't restricted on the number of addresses you could have?
and it can also be used to source one machine from many address.
Again, correct, but you don't need NAT to do this, you can just assign those many addresses directly to the machine in question. Doing that has the advantage that the software on that machine can know which address the connection was for.
You can do all kinds of cool stuff with NAT
Yes. Although, except for temporary measures (for network migration) and alleviating IP address shortages, the only use I've ever found for NAT in my 13 years of networking experience is load balancing internet connections. This is something I'm curious to figure out if there is a good solution for IPv6 (so far I've not had to configure load-balanced IPv6 connections).
because NAT is a firewall concept.
No... no it isn't. NAT has nothing to do with firewalls other than that it depends on some of the same low level technology (namely, stateful connection tracking). NAT provides very little security in itself (if you plug your NATting router into an untrusted broadcast network then people on that untrusted network can connect directly to machines within your NATted LAN. The only way to prevent this is with a firewall.)
Bit of a shame they still don't publish AAAA records for their main addresses though:(
Also, v6 facebook is a bit broken - a lot of their internal links are absolute references to www.facebook.com, so you only have to click a few things and suddenly you find you're on the v4 site instead of the v6 one.
If you might happen to believe that maybe some day someone will come up with something that is just an inherently better designed protocol than IPv6, then deploying IPv6 with the anti-NAT zealot brigade is stupid, because should something better come along, doing the network migration from an IPv6 network is going to take forever.
Migrating From IPv6 to something new is no harder than migrating from IPv4 to IPv6. In either case, existing widespread NAT doesn't really help you. Lets look at the current situation with IPv4 as an example: Most internet connections have a bunch of IPv4 devices behind a NAT. When migrating from IPv4 to IPv6 the whole network isn't going to upgrade in one go, so we need some way for new devices and old devices to talk to each other. Your IPv4-only device is not going to be able to connect to an IPv6-only device, because the IPv4 device has no way of specifying what IPv6 address it needs to connect to. Whether or not you use NAT is irrelevant here. Connecting the other way is possible through the use of NAT64, but that doesn't fall into the category of "existing widespread NAT" - NAT64 is something you put in *specifically* to help with migration, not something that is already there.
It should be easy to migrate *from* a network to new technologies, not get locked into a dead-end-to-dead-end addressing scheme.
I'd be curious to hear your solution to this problem...
All they need to do is use the same method they've used with IP4: They only accept one address at your site, and discard any packets that didn't come from that address or is sent to that address. If you want N addresses, you'll have to pay N x $X, where $X is their current price for a routable address. The phone system has worked this way since the beginning of phone numbers, and nobody ever complained. The phone system also has "extension" numbers, which in the IP world are called "port" numbers. But the ISPs have caught onto this, and most of them now block lots of your port numbers.
Ok, I have no idea what crazy world you're living in, but: 1. AFAIK telephone numbers are handed out by the regulator for free. If your telco doesn't supply numbers for free then go elsewhere, there are plenty of places that do (my business doesn't pay for any of its inbound DDIs) 2. Who on earth are you getting your internet connection from? I've never come across an ISP that charges per IP address. My EntaNet business account gives me a/29 IPv4 subnet and a/56 IPv6 subnet and costs me about 20gbp/month. Prior to that I had a PlusNet home account and that also gave me a/29 IPv4 subnet. If I want more IPv4 addresses, I just fill out the RIPE form justifying my need, and I'll be handed more addresses for free. The same goes for all my customers, who have business accounts with all sorts of ISPs - I've not once heard of them being charged extra for extra IPs (although occasionally you find an ISP, such as Virgin, that doesn't support giving customers small subnets instead of single IPs, in which case you just have to switch ISP). 3. What ISPs block "lots of ports"? Sure, some ISPs have taken to firewalling commonly abused ports (e.g., 25) by default, but you can always phone them up and ask them to unblock them (for which they don't charge). This is actually pretty sensible.
Can you think of any reason they can't implement exactly the same limits with IPv6 that they currently have with IPv4?
Well, other than the fact that they generally _don't_ do what you claim, in my experience... Oh, and the fact that the ISP has little control over what IP address your devices get. You need at least a/64 subnet, otherwise stateless autoconfiguration won't work, within that network, all the devices pick their own address, so the ISP would find it very hard to restrict you to a single address, especially since some of the autoconfiguration protocols involve assigning a new random address every so often.
How are you going to hack into my webcam when it has no publically visible IP address?
You're making a faulty assumption. How do you know the IP address isn't publicly visible? If the external side of your NAT box is plugged into an untrusted broadcast network (frequently the case with cable modems) and is running no firewall then your webcam's IP can very easily be visible to people on that untrusted network.
On the other hand, if you have a stateful firewall, your webcam is protected irrespective of whether you are using NAT or not.
You wouldn't. You'd write a word processor that resides native on the device and makes use of the local processing power, and tie its filestore to a service like dropbox, where the relatively small text document can be autosaved, and then available from any device with access to that dropbox store.
So, uhm, how is that different to what we have now? Except for the fact that you're building remote file system drivers into the individual applications rather than the OS, which is moronic. We can already mount remote filesystems and save files to them, what you're suggesting is nothing new.
I'm getting more and more tired of the push to "cloud computing" which perpetually seems to mean running things in your web browser. The original idea of "cloud computing" was that your PC is a thin client and the application is mostly on a remote server and is being displayed by your web browser. Then people realised that that was largely a bloody stupid idea (because network access is *not* ubiquitous!) and so now "cloud computing" seems to often involve having a local application running in your web browser. So the only difference between "cloud computing" and "regular computing" is that you're running everything inside a web browser, requiring orders of magnitude more resources to do what we've already been doing for years natively. The whole concept is idiotic.
It's funny, but he is right. Desktop and laptop sales are already in decline.
They are probably in decline because people have realised that their 5 year old computer doesn't need replacing. Gone are the days when you had to upgrade every year - modern computers are pretty much as powerful as most people need.
It's gonna be all virtualization on dense servers and thin clients, just like Sun thought (but about a decade late to save them).
I don't see many applications seriously moving to the cloud. People still want to be able to do stuff when there is no internet access. E.g. I use my computer to do off-line stuff like word processing, watching videos, etc. when I'm on the train, sure I have 3G internet access but it is slow, incredibly unreliable and battery hungry, so forcing me to use a remote server would be unacceptable (and also pointless - modern phones are powerful enough to run stuff like a word processor, why on earth would you cripple them by forcing them to be thin clients?)
The thing people complain about, even if they don't spell it out, is the replacement of stuff that works by stuff that "isn't quite there yet".
If it isn't there, it shouldn't be the default in any major distribution.
I could look at pretty much any GUI and pick out reasons why I'd consider it "not there yet". Yes, I'm including Windows 3, Win 95, OS X, Gnome 2, Enlightenment, Gnome 3, etc. They *all* "aren't quite there yet", so by your comment shouldn't have ever been in a major distribution. The thing is, after you've used a system for a while, you learn to work around the bits that don't quite work well and eventually you're so used to avoiding those problems that you don't even notice they are there. Then, you change to a new UI which has *different* problems and suddenly the workaround that you're used to using isn't needed any more and you're going to need to figure out and get used to some new workarounds, which takes time.
They're trying to push "progress" down everyone's throats, and it's probably because Linux policy is dictated by developers, not users.
I don't see open source policy that much different to the policies of large closed-source organisations. In FOSS projects, the decisions are largely made by the developers and in some cases, the bosses at the larger corporations (Canonical, RedHat, et al). In closed source projects such as Windows, OS X, etc. the decisions are largely made by the bosses. In both cases, the user is not really part of the decision making process - sure, the developers and bosses may do some usability studies involving end users (and this applies to both FOSS and closed commercial projects), but honestly, when was the last time you emailed Microsoft and asked for the Windows UI to do $feature and they actually implemented it for you in the next version? Just a quick look at Windows 8 should convince you that they don't really take the users into consideration when designing this stuff.
As for progress, IMHO progress is acknowledging that different users have different needs and producing a wide variety of UIs rather than trying to jam a single UI down everyone's throats irrespective of their needs. FWIW, I think that (for me) Gnome 3 is definitely progress - sure, they've jumped the shark in a few places (largely misfeatures that they have ripped off from OS X), but on the whole it isn't bad. I've switched all my machines to Gnome 3 now and consider it an improvement over anything else I've used (prior to Gnome 3 I had settled on E17 for a while... Gnome 2 was horrendous, it seemed that they had tried to copy Windows whilst removing the few things that Windows does right.)
Every moment I spend moving a window around or resizing it is frankly wasted time. Same with launching programs or organizing my menus.
If we can abandon the model where the user has to fiddle with a bunch of unnecessary crap just to use their computer, that would be a step forward.
Unless your computer is going to have a mind reader device attached to it, how else are you expecting to tell it how big you want the window and where you want it? Making all windows full-screen certainly isn't the answer because that is *always* wrong (I never full-screen my windows and I almost always work with multiple overlapping windows at once - forcing me to fullscreen everything and constantly switch between them would be more of a time waste than occasionally resizing and positioning a window.
iOS is great for touch devices. If someone put iOS on my desktop, it would drive me mad.
Someone did. They called it Gnome 3, and yes, it's largely unusable except, perhaps, on a tablet for people who only run one app at a time, or who automatically think that new = better.
I'm not sure why you consider gnome 3 to be a "1 app at a time" DE - it supports overlapping windows, has a good application switcher, etc. Sure there are a few places where they have jumped the shark, but those largely seem to be misfeatures that have been ripped off from OS X, not iOS.
But that's equivalent to -not- believing it. Because there's an infinite number of possible gods, and they've got an infinite variety of mutually contradictory wishes.
Rubbish. The belief that an intelligence created the universe does not inherently demand that you follow whatever you believe that creator's wishes to be. So by extension, the creator's wishes are largely irrelevant and I see no reason why you couldn't believe in the existence of a creator without being specific as to the detail of that creator. Of course, this isn't the basis of a religion but religion and faith are not the same thing.
There's no practical difference between: "he don't exist" and "I'm going to act, in every manner, as if he don't exist"
Psychologically I think it makes a big difference.
While it's true that there are frequently (actually, I'd say "always") no absolute answers, "science" should work on what is the best assumption at this time. What "scientists" base their work on is not necessarily always this - they may base their work on their beliefs, but that's just them being human. Don't blame science for the scientists...
I dunno about this. Sometimes great discoveries follow rejecting respected theories and investigating something else on a hunch. You may not call it science, but it sometimes results in great progress which leads to more good science.
Telling people they are insane isn't "pushing" anything on them. I'm not pushing personal hygene on people when I call them smelly. I'm just calling them smelly.
If someone has bad hygene they probably are smelly in the physical meaning of the word. If someone has a faith that is neither backed nor disproved by science they are not insane so calling them out as such is mere name calling.
Is it wrong to believe yourself to be correct to the point where you tell others they are wrong?
Unless you can back it up with good evidence as to why they are wrong then yes, you damned well shouldn't be telling them what to believe. By all means, tell people what you believe and explain why you hold these beliefs, but telling people their beliefs are _wrong_ in matters of faith is the root of war.
Ah yes, you don't like atheists, so you are knowingly denying the correct term because you don't like it. I call that "lying."
No, I'm using language in a way to be understandable by the masses rather than in a way that is semantically more correct but doesn't convey the same amount of information. Language evolves - like it or not, to most people the word "atheist" doesn't mean what you profess to be the correct interpretation. Much like the word "hacker" takes on a different meaning when you address the masses than when you address geeks.
This would indeed be a consistent theory, but it's also not the kind of God that's usefull in a religious persons life. (Some) people need a god that can provide practical guidance in moral matters, and give a reassuring sense of purpose to their life.
I rather thought the main purpose of a god was to explain the unexplainable (why/how are we here?) and to reassure that there's something after death. Of course, the mere existence of a creator doesn't guarantee life after death.
It is not scientific to posit any entity which is neither observed directly nor necessary to explain observed behaviour
Observed behaviour: universe spontaneously popped into being 13.7 billion years ago and has universal constants that lead to the evolution of our type of life. There is no scientific explanation for why this is so. The scientific position is "we don't know why this happened", not "it was definitely created by intelligence", nor "it was definitely not created by intelligence".
You don't have to go and drag science into it and try to claim that the belief is scientifically valid.
Here I agree with you. And that's exactly what I was saying - a faith in either the existence or non-existence of god is scientifically invalid either way. That doesn't mean you shouldn't *have* a faith, but claiming that science supports your position seems a bit silly.
You have some particular aversion to that descriptor, so you claim another.
I have an aversion to being associated with people who actively believe there is no god. The popular interpretation of atheist is exactly this so I choose a term that doesn't have the same association in the eyes of the populace.
It's not a false analogy. Unicorns are invisible, you see, so you can't observe them. They fly, so they don't leave any footprints, and they are extremely good at avoiding collisions, so nobody has ever accidentally hit one.
Ok, so now you're much more on par with whether a creator exists or not. My answer to you is that I don't know or care whether your unicorns exist, much as I don't know or care whether a creator exists - in both cases you have something unobservable that does not interact with the universe in any way and therefore is of no consequence to me.
I don't care which you believe - what I do care about is people pushing their beliefs upon other people.
You believe there can never be a definitive answer, and you are pushing that belief on others. You are a hypocrite.
At what point did I tell anyone that they should believe that? I stated what I believe (that the existence/nonexistence of a creator is fundamentally not scientifically provable), that I didn't care what other people believed but that I didn't want anyone trying to tell me what I should be believing. This is a contrast to other commenters in this thread who have stated that anyone who doesn't follow their belief is "insane".
You have faith that the creator will not reveal himself (otherwise there would be direct evidence, and you state that can't happen).
No, I have no such faith. It has not happened to me yet, nor have I seen any such revelation documented scientifically. When this happens I will change my beliefs (as is the scientific way).
So you have faith and beliefs, and are pushing those on others as the "truth" despite the fact that your opinions are no more valid than theirs.
No real faith. Of course I have beliefs - everyone has beliefs, even the pure scientist who believes one theory has more merit than another. Nor am I attempting to push anything on anyone - you can believe whatever the hell you want to believe, I just don't want you telling people they are insane for holding a different belief to you.
Slashdot Mirror
No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
Then what do you suggest that identifier is? Can't use DNS because there is absolutely no guarantee that a host has correct DNS records (when was the last time you saw a home user create public DNS records for all their workstations?). And even if you could guarantee that the DNS records are correct, it still doesn't help when there is NAT involved since your DNS lookup (or whatever identifier you use) is going to have to resolve to a globally reachable network address, and no such thing exists when machines are hidden behind a NAT on local scope addresses.
The point of supporting/having NAT is to allow the network to be modular/segmented, so you aren't stuck waiting for a the last few people on the other side of the world to upgrade to the latest protocol, or having to wait for them to upgrade every one of their applications which depends on having 'IP addresses'.
You're not talking about network address translation. You're talking about protocol translation, which is rather different. And also isn't really possible to do in the way you're suggesting. Lets look at the IPv4 to IPv6 migration as an example:
Alice is on IPv6, Bob is on IPv4 (12.34.56.78), Charlie is on IPv6.
So Alice wants to connect to Bob. Since they have different protocols, there will need to be a protocol translation system involved (NAT64). As IPv6 has a larger address space than IPv4, a chunk of that address space can be mapped 1:1 to IPv4 addresses. So Alice takes Bob's IPv4 address and shoves the designated NAT64 prefix on it to turn it into an IPv6 address - ::ffff:0:12.34.56.78. Alice sends a packet to that address, the NAT64 box gets the packet and translates it into an IPv4 packet. But Alice's address is IPv6 so can't go in the IPv4 packet so the NAT64 box puts its own IPv4 address on the packet and sends it along to Bob. When Bob sends a reply, it goes back to the NAT64 box, which looks up the IPv6 address associated with the connection (Alice) and is then able to translate the packet back to IPv6 and forward it along. So far so good, and all this really does work in practice and is in common use today - it works pretty well for simple client/server protocols such as HTTP.
Now, Alice needs to tell Bob to send some data to Charlie (pretty common in peer to peer applications). Here's where you hit a problem - there's no way that Charlie's address can be encoded within an IPv4 address. This means that no matter how you pass that addressing information within the protocol, when it is eventually translated back into an IP address to connect to, it is nonsensical - Bob has no idea how to connect to Charlie's IPv6 address. It didn't matter whether you passed an IPv6 address within the application's data stream, or a hostname that Bob's OS resolved to an IPv6 address - either way, Bob can't connect.
I'm sure you could invent a protocol extension whereby Bob can know to connect to the NAT64 box when he sees an IPv6 address and somehow hand the NAT64 box Charlie's address. But that requires Bob to know about IPv6, so it pretty pointless - if you're forcing Bob to implement new protocols like that then you may as well force Bob to upgrade to IPv6 properly.
Another option is that you could invent a protocol so that Alice can tell the NAT64 box to expect a connection from Bob and to forward it to Charlie. But now Alice needs to know lots of information about the NAT64 box's addresses (which you claim is always a bad thing), and more importantly, the NAT64 box could well now be subject to having to forward lots of traffic between two third party networks! That's not satisfactory.
It's so people can run what they want on their networks and still use applications that work across heterogeneous networks.
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
Eh? No it isn't. I don't need NAT now so I'll remove it so it doesn't cause problems. No reason why I can't add it back in the future if I either discover I need it for something or I go completely insane.
The disagreement is whether or not the recipient needs to know *IP* addressing information.
In the cases where NAT is a problem, the answer is an emphatic "yes", the recipient does need to know IP addressing information.
Sending application level data across the network 'encapsulates' the data in an IP packet. IP packets are NOT the application.
IP packets are not the application's data, no. But the IP addressing information is often needed so that it knows where to send data to. It doesn't matter whether you handle the IP addresses in the kernel or in the application, *something* needs to know where to send the data. If the destination machine is on the other side of a NAT then you're out of luck - you can't trivially send data to it (there are NAT traversal mechanisms but they aren't reliable for a number of reasons that are beyond the scope of this discussion).
Actually, people could, but they don't. What it would require would be to take something like SRV records. A server behind NAT would have to inform the NAT device that it is offering service X on port Y for domain Z. The NAT server would have to server up a NAT rule for an outside port A to map to the inside server on port Y. Then it handles DNS requests for domain Z and returns SRV records (or similiar) saying that if you want to reach service X for domain Z, connect to the NAT server on port Y.
You've now delved into the realms of redesigning NAT from the ground up - that's a silly discussion to have because the whole issue is that we're stuck with protocols that were not designed to cope with the current situation. If we were designing the internet from scratch with the knowledge we now have, we would have a bigger address space and NAT wouldn't be required... oh wait, that's one of the reasons we're migrating to IPv6.
I don't understand why you seem to want to hold onto NAT - I'm not saying "NAT is evil", on the contrary - it serves some very useful purposes. But when we switch to IPv6, most of that usefulness evaporates. Why would we want to hold onto a layer of complexity that is no longer serving a purpose?
Lets be clear on this: application data should *not* break if it's encapsulated in IPv4, and then unecapsulated, then re-encapsulated in IPv6. The application data should be separate from IP information just as it is separate from other encapsulation.
In simple protocols between a client and an a server you are correct. And in those cases, applications *don't* break if you do this. On the other hand, if your application needs to somehow tell the remote machine to go send data to somewhere different (which peer to peer protocols need to do, such as SIP, Bittorrent, etc) then you *are* going to need to communicate the appropriate addresses to the remote machine.
The ability to write directly to the memory of a data structure may be considered advantageous in some situations. Yet, a lot of people prefer object-orientated programming or styles with getters and setters which can manage this access. You may disagree.
And yet programming isn't exclusively object orientated. There are situations where object orientation would produce too much overhead. Hell, sometimes we still program in raw assembler! Same goes for the internet - the protocols that are broken by NAT are the protocols that cannot sensibly incur the overheads associated with running in a strict client/server architecture.
The initial move is to stop demonizing NAT.
NAT has its uses, but it also has its problems. If there is no IP address shortage then *most* (not all) NAT suddenly has no use, leaving nothing but the problems. So in these use cases it makes sense to remove NAT since it is no longer doing anything useful and is a potential source of problems. This is not "demonising", this is simply looking at it in an objective way and realising that things can usually be improved by removing NAT from the equation.
I mean, seriously. We have networking traffic that moves from optical to wired to wireless, across all sorts of protocols and encapsulations, constantly. No one freaks out, no one complains.
There is a huge difference here. What you're talking about is encapsulation - this does not modify the packets a user's application is sending, it mearly puts them inside other packets. No information is destroyed - you can always get all the original data out by simply unencapsulating them again. And indeed, this is exactly what happens - an application sends an IP datagram and it arrives at the destination unaltered. The application has no need to care what has happened in the middle because any encapsulation that has happened gets undone again before it gets to the recipient. On the other hand, NAT destroys the original addressing information - what the recipient sees is *not* what the sender sent.
NAT only impinges the functionality of software because the software and protocols are badly designed
That is fundamentally not true. The protocols you are talking about (SIP is a common example) were specifically designed to do exactly that. It was not a design flaw, it was intentionally done that way because in a network that has end to end connectivity (which is the type of network SIP was designed to be used in) this actually has some big advantages, such as reduced latency requirements (this was a *really* important criteria for the use cases SIP was designed for), reduced infrastructure and bandwidth requirements (you don't need honking great servers forwarding media between peers).
Anyone interpreting these features as "bad design" is demonstrating a lack of understanding of the design goals for these protocols.
-- i.e. they insist on using IP information inside application level protocols instead of application-level identifiers (i.e. hostnames rather than IP addresses.)
Host names don't help. You can't magically route a packet to a host that is behind a NAT by knowing its hostname.
If applications do not break or fail to work because my traffic switches from wireless to wired to optical data transport, or because the encapsulation changes (ethernet frames vs. ppp vs. ATM vs. frame relay), then they should also not break because the network protocol changes (i.e. IPv4 to IPv6 and back again.)
Lets be clear on this: applications do *not* break if their IPv4 packets get encapsulated within IPv6 packets for part of the journey and then unencapsulated again. In fact, this is exactly what 6to4 tunnels do, but in reverse - IPv6 packets are encapsulated within IPv4 when traversing parts of the network that have no IPv6 support; applications do not need to know or care that this is happening since the data that comes out is the same as the data that goes in.
People blame NAT for the problems, but it is not that NAT *breaks* the applications, it is that the applications were *already broken* in design, and NAT just reveals the flaws.
Occasionally, yes, but in the vast majority of cases where NAT breaks things this is completely untrue. An application requiring the ability to send packets directly to a specific machine is not a "broken" design, rather, it is a design that has a lot of advantages. The disadvantage with this design is that it requires the remote host to be addressable, which i
Only real disagreement I have with you is your comment about network access being ubiquitous. For a vast majority of us, it already is via - at a minimum - 3G on a mobile
I frequently travel by train and I can tell you that 3G is *not* ubiquitous. I have frequent drop outs - its enough for a bit of web surfing so long as you're happy to wait 5 minutes for the signal to come back every so often, but I wouldn't want to work over it. Not only do trains pass through areas of poor coverage, they also pass through tunnels where there is *no* coverage. I also frequently go to reasonably remote parts of the country where there really is no 3G signal (e.g. on the Isle of Skye I get no mobile phone signal at all anywhere on the island). Another important factor is going abroad - with MNOs charging 10gbp per megabyte for roaming data, you can bet I expect pretty much everything to work without network access. 3G is also a bit of a battery hog, so if you can avoid using it you get much better battery life.
Modern computers are vastly powerful and have huge amounts of disk space, why on earth would we want to cripple them by tieing them to a network for things that fundamentally don't need to be done remotely?
Not sure why you seem so particularly offended by what is, essentially, a marketing term.
I get slightly annoyed at people using meaningless terminology to pass something that is no different to what we have already been doing for years as if it were new.
Not to mention that UPnP essentially reduces your NAT "security" to nil.
Not really... But the NAT bit is irrelevant here - UPNP can poke holes in stateful firewalls and NATs alike.
The reason why UPNP doesn't really reduce security in a home environment is because once you have malware inside your network, you don't need UPNP to open up holes in your firewall for more evil to flow through. Firewall traversal (and NAT traversal) are quite trivial procedures that don't require UPNP.
The solution to that is to do native dual stack. That way you don't break any IPv4 compatibility while using a clean approach to IPv6. Then, in the future, you stop giving IPv4 addresses once IPv4 falls out of use. The "IPv6 only" devices you speak of either don't exist or are completely niche, and they will continue to be uncommon until IPv4 dies out.
Dual-stack doesn't work when you've run out of v4 addresses...
NAT is not the Devil coming to Eat your Children.
Correct. But NAT does cause lots of problems, so getting rid of it where it isn't needed is a Good Thing.
NAT can be used to source many machines from the same address
Correct, but why would you want to if you weren't restricted on the number of addresses you could have?
and it can also be used to source one machine from many address.
Again, correct, but you don't need NAT to do this, you can just assign those many addresses directly to the machine in question. Doing that has the advantage that the software on that machine can know which address the connection was for.
You can do all kinds of cool stuff with NAT
Yes. Although, except for temporary measures (for network migration) and alleviating IP address shortages, the only use I've ever found for NAT in my 13 years of networking experience is load balancing internet connections. This is something I'm curious to figure out if there is a good solution for IPv6 (so far I've not had to configure load-balanced IPv6 connections).
because NAT is a firewall concept.
No... no it isn't. NAT has nothing to do with firewalls other than that it depends on some of the same low level technology (namely, stateful connection tracking). NAT provides very little security in itself (if you plug your NATting router into an untrusted broadcast network then people on that untrusted network can connect directly to machines within your NATted LAN. The only way to prevent this is with a firewall.)
There are content providers starting to use Dual-Stack so they are supporting both IPv4 and IPv6.
Here are just some of them:
http://www.v6.facebook.com/
http://ipv6.google.com/
http://www.comcast6.net/
Bit of a shame they still don't publish AAAA records for their main addresses though :(
Also, v6 facebook is a bit broken - a lot of their internal links are absolute references to www.facebook.com, so you only have to click a few things and suddenly you find you're on the v4 site instead of the v6 one.
If you might happen to believe that maybe some day someone will come up with something that is just an inherently better designed protocol than IPv6, then deploying IPv6 with the anti-NAT zealot brigade is stupid, because should something better come along, doing the network migration from an IPv6 network is going to take forever.
Migrating From IPv6 to something new is no harder than migrating from IPv4 to IPv6. In either case, existing widespread NAT doesn't really help you. Lets look at the current situation with IPv4 as an example: Most internet connections have a bunch of IPv4 devices behind a NAT. When migrating from IPv4 to IPv6 the whole network isn't going to upgrade in one go, so we need some way for new devices and old devices to talk to each other. Your IPv4-only device is not going to be able to connect to an IPv6-only device, because the IPv4 device has no way of specifying what IPv6 address it needs to connect to. Whether or not you use NAT is irrelevant here. Connecting the other way is possible through the use of NAT64, but that doesn't fall into the category of "existing widespread NAT" - NAT64 is something you put in *specifically* to help with migration, not something that is already there.
It should be easy to migrate *from* a network to new technologies, not get locked into a dead-end-to-dead-end addressing scheme.
I'd be curious to hear your solution to this problem...
All they need to do is use the same method they've used with IP4: They only accept one address at your site, and discard any packets that didn't come from that address or is sent to that address. If you want N addresses, you'll have to pay N x $X, where $X is their current price for a routable address.
The phone system has worked this way since the beginning of phone numbers, and nobody ever complained. The phone system also has "extension" numbers, which in the IP world are called "port" numbers. But the ISPs have caught onto this, and most of them now block lots of your port numbers.
Ok, I have no idea what crazy world you're living in, but: /29 IPv4 subnet and a /56 IPv6 subnet and costs me about 20gbp/month. Prior to that I had a PlusNet home account and that also gave me a /29 IPv4 subnet. If I want more IPv4 addresses, I just fill out the RIPE form justifying my need, and I'll be handed more addresses for free. The same goes for all my customers, who have business accounts with all sorts of ISPs - I've not once heard of them being charged extra for extra IPs (although occasionally you find an ISP, such as Virgin, that doesn't support giving customers small subnets instead of single IPs, in which case you just have to switch ISP).
1. AFAIK telephone numbers are handed out by the regulator for free. If your telco doesn't supply numbers for free then go elsewhere, there are plenty of places that do (my business doesn't pay for any of its inbound DDIs)
2. Who on earth are you getting your internet connection from? I've never come across an ISP that charges per IP address. My EntaNet business account gives me a
3. What ISPs block "lots of ports"? Sure, some ISPs have taken to firewalling commonly abused ports (e.g., 25) by default, but you can always phone them up and ask them to unblock them (for which they don't charge). This is actually pretty sensible.
Can you think of any reason they can't implement exactly the same limits with IPv6 that they currently have with IPv4?
Well, other than the fact that they generally _don't_ do what you claim, in my experience... Oh, and the fact that the ISP has little control over what IP address your devices get. You need at least a /64 subnet, otherwise stateless autoconfiguration won't work, within that network, all the devices pick their own address, so the ISP would find it very hard to restrict you to a single address, especially since some of the autoconfiguration protocols involve assigning a new random address every so often.
How are you going to hack into my webcam when it has no publically visible IP address?
You're making a faulty assumption. How do you know the IP address isn't publicly visible? If the external side of your NAT box is plugged into an untrusted broadcast network (frequently the case with cable modems) and is running no firewall then your webcam's IP can very easily be visible to people on that untrusted network.
On the other hand, if you have a stateful firewall, your webcam is protected irrespective of whether you are using NAT or not.
You wouldn't. You'd write a word processor that resides native on the device and makes use of the local processing power, and tie its filestore to a service like dropbox, where the relatively small text document can be autosaved, and then available from any device with access to that dropbox store.
So, uhm, how is that different to what we have now? Except for the fact that you're building remote file system drivers into the individual applications rather than the OS, which is moronic. We can already mount remote filesystems and save files to them, what you're suggesting is nothing new.
I'm getting more and more tired of the push to "cloud computing" which perpetually seems to mean running things in your web browser. The original idea of "cloud computing" was that your PC is a thin client and the application is mostly on a remote server and is being displayed by your web browser. Then people realised that that was largely a bloody stupid idea (because network access is *not* ubiquitous!) and so now "cloud computing" seems to often involve having a local application running in your web browser. So the only difference between "cloud computing" and "regular computing" is that you're running everything inside a web browser, requiring orders of magnitude more resources to do what we've already been doing for years natively. The whole concept is idiotic.
It's funny, but he is right. Desktop and laptop sales are already in decline.
They are probably in decline because people have realised that their 5 year old computer doesn't need replacing. Gone are the days when you had to upgrade every year - modern computers are pretty much as powerful as most people need.
It's gonna be all virtualization on dense servers and thin clients, just like Sun thought (but about a decade late to save them).
I don't see many applications seriously moving to the cloud. People still want to be able to do stuff when there is no internet access. E.g. I use my computer to do off-line stuff like word processing, watching videos, etc. when I'm on the train, sure I have 3G internet access but it is slow, incredibly unreliable and battery hungry, so forcing me to use a remote server would be unacceptable (and also pointless - modern phones are powerful enough to run stuff like a word processor, why on earth would you cripple them by forcing them to be thin clients?)
The thing people complain about, even if they don't spell it out, is the replacement of stuff that works by stuff that "isn't quite there yet".
If it isn't there, it shouldn't be the default in any major distribution.
I could look at pretty much any GUI and pick out reasons why I'd consider it "not there yet". Yes, I'm including Windows 3, Win 95, OS X, Gnome 2, Enlightenment, Gnome 3, etc. They *all* "aren't quite there yet", so by your comment shouldn't have ever been in a major distribution. The thing is, after you've used a system for a while, you learn to work around the bits that don't quite work well and eventually you're so used to avoiding those problems that you don't even notice they are there. Then, you change to a new UI which has *different* problems and suddenly the workaround that you're used to using isn't needed any more and you're going to need to figure out and get used to some new workarounds, which takes time.
They're trying to push "progress" down everyone's throats, and it's probably because Linux policy is dictated by developers, not users.
I don't see open source policy that much different to the policies of large closed-source organisations. In FOSS projects, the decisions are largely made by the developers and in some cases, the bosses at the larger corporations (Canonical, RedHat, et al). In closed source projects such as Windows, OS X, etc. the decisions are largely made by the bosses. In both cases, the user is not really part of the decision making process - sure, the developers and bosses may do some usability studies involving end users (and this applies to both FOSS and closed commercial projects), but honestly, when was the last time you emailed Microsoft and asked for the Windows UI to do $feature and they actually implemented it for you in the next version? Just a quick look at Windows 8 should convince you that they don't really take the users into consideration when designing this stuff.
As for progress, IMHO progress is acknowledging that different users have different needs and producing a wide variety of UIs rather than trying to jam a single UI down everyone's throats irrespective of their needs. FWIW, I think that (for me) Gnome 3 is definitely progress - sure, they've jumped the shark in a few places (largely misfeatures that they have ripped off from OS X), but on the whole it isn't bad. I've switched all my machines to Gnome 3 now and consider it an improvement over anything else I've used (prior to Gnome 3 I had settled on E17 for a while... Gnome 2 was horrendous, it seemed that they had tried to copy Windows whilst removing the few things that Windows does right.)
Every moment I spend moving a window around or resizing it is frankly wasted time. Same with launching programs or organizing my menus.
If we can abandon the model where the user has to fiddle with a bunch of unnecessary crap just to use their computer, that would be a step forward.
Unless your computer is going to have a mind reader device attached to it, how else are you expecting to tell it how big you want the window and where you want it? Making all windows full-screen certainly isn't the answer because that is *always* wrong (I never full-screen my windows and I almost always work with multiple overlapping windows at once - forcing me to fullscreen everything and constantly switch between them would be more of a time waste than occasionally resizing and positioning a window.
iOS is great for touch devices. If someone put iOS on my desktop, it would drive me mad.
Someone did. They called it Gnome 3, and yes, it's largely unusable except, perhaps, on a tablet for people who only run one app at a time, or who automatically think that new = better.
I'm not sure why you consider gnome 3 to be a "1 app at a time" DE - it supports overlapping windows, has a good application switcher, etc. Sure there are a few places where they have jumped the shark, but those largely seem to be misfeatures that have been ripped off from OS X, not iOS.
But that's equivalent to -not- believing it. Because there's an infinite number of possible gods, and they've got an infinite variety of mutually contradictory wishes.
Rubbish. The belief that an intelligence created the universe does not inherently demand that you follow whatever you believe that creator's wishes to be. So by extension, the creator's wishes are largely irrelevant and I see no reason why you couldn't believe in the existence of a creator without being specific as to the detail of that creator. Of course, this isn't the basis of a religion but religion and faith are not the same thing.
There's no practical difference between: "he don't exist" and "I'm going to act, in every manner, as if he don't exist"
Psychologically I think it makes a big difference.
While it's true that there are frequently (actually, I'd say "always") no absolute answers, "science" should work on what is the best assumption at this time. What "scientists" base their work on is not necessarily always this - they may base their work on their beliefs, but that's just them being human. Don't blame science for the scientists...
I dunno about this. Sometimes great discoveries follow rejecting respected theories and investigating something else on a hunch. You may not call it science, but it sometimes results in great progress which leads to more good science.
Telling people they are insane isn't "pushing" anything on them. I'm not pushing personal hygene on people when I call them smelly. I'm just calling them smelly.
If someone has bad hygene they probably are smelly in the physical meaning of the word. If someone has a faith that is neither backed nor disproved by science they are not insane so calling them out as such is mere name calling.
Is it wrong to believe yourself to be correct to the point where you tell others they are wrong?
Unless you can back it up with good evidence as to why they are wrong then yes, you damned well shouldn't be telling them what to believe. By all means, tell people what you believe and explain why you hold these beliefs, but telling people their beliefs are _wrong_ in matters of faith is the root of war.
Ah yes, you don't like atheists, so you are knowingly denying the correct term because you don't like it. I call that "lying."
No, I'm using language in a way to be understandable by the masses rather than in a way that is semantically more correct but doesn't convey the same amount of information. Language evolves - like it or not, to most people the word "atheist" doesn't mean what you profess to be the correct interpretation. Much like the word "hacker" takes on a different meaning when you address the masses than when you address geeks.
This would indeed be a consistent theory, but it's also not the kind of God that's usefull in a religious persons life. (Some) people need a god that can provide practical guidance in moral matters, and give a reassuring sense of purpose to their life.
I rather thought the main purpose of a god was to explain the unexplainable (why/how are we here?) and to reassure that there's something after death. Of course, the mere existence of a creator doesn't guarantee life after death.
It is not scientific to posit any entity which is neither observed directly nor necessary to explain observed behaviour
Observed behaviour: universe spontaneously popped into being 13.7 billion years ago and has universal constants that lead to the evolution of our type of life. There is no scientific explanation for why this is so. The scientific position is "we don't know why this happened", not "it was definitely created by intelligence", nor "it was definitely not created by intelligence".
You don't have to go and drag science into it and try to claim that the belief is scientifically valid.
Here I agree with you. And that's exactly what I was saying - a faith in either the existence or non-existence of god is scientifically invalid either way. That doesn't mean you shouldn't *have* a faith, but claiming that science supports your position seems a bit silly.
You have some particular aversion to that descriptor, so you claim another.
I have an aversion to being associated with people who actively believe there is no god. The popular interpretation of atheist is exactly this so I choose a term that doesn't have the same association in the eyes of the populace.
It's not a false analogy. Unicorns are invisible, you see, so you can't observe them. They fly, so they don't leave any footprints, and they are extremely good at avoiding collisions, so nobody has ever accidentally hit one.
Ok, so now you're much more on par with whether a creator exists or not. My answer to you is that I don't know or care whether your unicorns exist, much as I don't know or care whether a creator exists - in both cases you have something unobservable that does not interact with the universe in any way and therefore is of no consequence to me.
I don't care which you believe - what I do care about is people pushing their beliefs upon other people.
You believe there can never be a definitive answer, and you are pushing that belief on others. You are a hypocrite.
At what point did I tell anyone that they should believe that? I stated what I believe (that the existence/nonexistence of a creator is fundamentally not scientifically provable), that I didn't care what other people believed but that I didn't want anyone trying to tell me what I should be believing. This is a contrast to other commenters in this thread who have stated that anyone who doesn't follow their belief is "insane".
You have faith that the creator will not reveal himself (otherwise there would be direct evidence, and you state that can't happen).
No, I have no such faith. It has not happened to me yet, nor have I seen any such revelation documented scientifically. When this happens I will change my beliefs (as is the scientific way).
So you have faith and beliefs, and are pushing those on others as the "truth" despite the fact that your opinions are no more valid than theirs.
No real faith. Of course I have beliefs - everyone has beliefs, even the pure scientist who believes one theory has more merit than another. Nor am I attempting to push anything on anyone - you can believe whatever the hell you want to believe, I just don't want you telling people they are insane for holding a different belief to you.