X Might Be Ready For IPV6

makapuf writes "According to linuxtoday, the X Consortium has published enhancement proposals to let X and IPV6 interoperate. This is surely a relief for the masses here that longed for X support for IPV6. Or the contrary? The proposal can be found here."

Comments

And I was just thinking

[Anonymous Coward]

The only thing holding me back on IPv6 was X. Well, that's solved. IPv6 here I come!!!

Re:And I was just thinking

[obotics]

I think you forgot to end your comment with the extremely appropriate, w00t w00t!

Re:And I was just thinking

[Anonymous Coward]

For starters, it's essential that the old addressing scheme be a straightforward subset of the new one.

You're obviously still lacking in clues.

Go back and read some more.

Never get your opinions from Slashdot. Just becuase some PC technician at "The Wiz" can't see the sense in ipv6 doesn't mean Nortel networks and Lucent don't have a use for it.

Re:And I was just thinking

[blurzero]

And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET. Whowever dreamed up IPv6 needs to be put in a nice padded cell where they can't hurt themselves.

In a day and age when every cellphone, toaster and toilet is gaining the ability to use IP, it's not hard to see use for the ability to address every thumbtack, and then some. How long before RFID tags become IP capable? When IPv4 was thought up decades ago, I'm sure no one ever expected the address space would run out. By making IPv6 large, people a few decades from now won't need to go through the pain of implementing a new standard.

Re:And I was just thinking

[Anonymous Coward]

Do you think before you post or just say what ever come out of your butt?

Sorry, but this post is so uninformed that it is distrubing. IPv6 was designed from the ground up to deal with the existing limitations of IPv4; therefore, you would be an idiot to make things a subset of the existing design, you wouldn't be accomplishing anything because all the inherent problems of IPv4 would still exist. You seem to focus on one aspect of IPv6, the # of addresses, but IPv6 was created to solve much more than just this problem.

The primary design goals of it were to

1) Increase the # addresses available and to have addresses autoconfiguring.

2) Increase security

3) Improve network routing and ease network autoconfiguration

IPv6 accomplishes all these goals and very well. Next time you decide to post check to see if you actually know what you are talking about.

Oh yeah, and while IPv6 is not compatible with IPv4 there are methods available to allow the two to coexist while the transition happens.

Re:And I was just thinking

[GenSolo]

Let's see here:

Current population of Earth: ~6,000,000,000
Total number of addresses with one more octet added to IPv4: 1,099,511,627,776 (little less because you have to take out reserved-for-private blocks)
Some simple math... and... Addresses per person: ~183

Do you need 183 addresses? And please note, this isn't even considering NAT. Nobody said that we will never need a 128bit address, but the only way we'd need that many addresses in the near future is if we start assigning IPs to random kitchen appliances. Quite frankly, I don't want my toaster to have a public IP address, and if it ever gets an address at all you can be sure as hell it'll be behind a firewall. I can see it now, "ToasterVirus v.3.0 unleashed today, burning down the houses of 20 people who didn't know better than to open that email!" Seems a little bit silly, doesn't it?

Re:And I was just thinking

[Kronovohr]

Don't worry -- MIT will get half the allottment up front. We'll be bitching about running out of IP space in 27 more years.

Re:And I was just thinking

[Hellkitten]

I don't want my toaster to have a public IP address

You just wait until they put that IP enabled pacemaker into you. The hospital will be able to monitor the battery easily, and that ungratefule slob of useless trash grandson you put in your will anyway get's to practice his 1337 h4x0rin9 zki115. It's technology, how can it be bad?

Re:And I was just thinking

[GenSolo]

My question is simply, why does every appliance need an IP address? Rather, why do they need a public one. I can see starting the dishwasher from my PC (via a timer or task scheduler or some such), but I don't see any need to start it from outside my house. My complaint is that your toaster doesn't need to be networked. Maybe I'm missing something, but I honestly can't think of 100 things that I own that I'd allocate IP addresses.

I understand adding more addresses, and I understand that network usage is growing, but the 32 bit number didn't cover every human on the planet 100 times over 20 years ago like a 40 bit address would now. Add an octet or two, we need more addresses, but quadrupling the length of the address is just a pain in the ass for anybody who needs to remember a few addresses, and it's overkill.

Re:And I was just thinking

[GenSolo]

Yes... I should definitely make sure I don't have grandchildren. But I just wanted to note that I don't think the technology is bad. I just think there are lots of idiots in the world who will do stupid and wasteful things with it. Plus, with one more octet, I'll have 100 IP addresses (based on being an average person..see above math) so after my pacemaker I've got 99 left. ;)

Re:And I was just thinking

[Erik Hensema]

• For starters, it's essential that the old addressing scheme be a straightforward subset of the new one.
  You can simply run dual stack. No problem in there.
• What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers? No human should ever want to, even in the IPv4 world. We've got a nice little thing called DNS which makes it possible to assign nice and easy names to those horrible numeric addresses.
• And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET.
  We don't need more than 640 K of memory either.

You haven't actually used IPv6 at all, have you?

Re:And I was just thinking

[Hellkitten]

Plus, with one more octet, I'll have 100 IP addresses

Yes but there a still advantages to having an oversized address space. When script kiddies start scanning for targets it'll take a lot longer to find anything

With intelligent distribution if IP addresses routing can be made faster. Since an ISP doesn't have to use all of its address space a network can be set up so that (using ip4 syntax for simplicity) if the isp owns the 1.2.*.* ip range pakets for 1.2.1.* go on network segment1 1.2.2.* goes on segment 2 and so on. You couldn't have done that with ip4 since you would have to use the IP space efficiently. Simple way to do this is combined routers/switch/dhcp server that get's a range of of addresses and assigns them this way (a series of these could be used in a tree structure for large netwoks). Since the r/s/d box decides the distribution if addresses swithcing can be made very efficient since it would need to check only part of the destination address (could be done in hw) and introduce less latency

Re:And I was just thinking

[smittyoneeach]

It's technology, how can it be bad?
is better than
News for nerds, stuff that matters.
You go, boss.

Re:And I was just thinking

[Daniel Phillips]

Yes but there a still advantages to having an oversized address space. When script kiddies start scanning for targets it'll take a lot longer to find anything

So you're advocating security through obscurity?

Re:And I was just thinking

[Daniel Phillips]

"* For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."

You can simply run dual stack. No problem in there.

Glad you think so. Tell that to all the admins that now have to change their setups from "one stack" to "multi-stack". And don't even try to tell me you won't get mysterious glitches.

"* What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers?"

No human should ever want to, even in the IPv4 world.

That is utter bullshit. Either you have never done any admin, or you have Alzheimer disease.

We've got a nice little thing called DNS which makes it possible to assign nice and easy names to those horrible numeric addresses.

Oh, and you've never had your DNS down? You never had to ping your gateway by IP address? You've never had to set up ARP? Track down mysterious problems using ipdump?

"* And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET."

We don't need more than 640 K of memory either.

We are not talking about memory, we are talking about PUBLIC ip addresses (i.e., doesn't include the ones embedded in your stereo).

Let me try to explain this in terms you'll understand: when you were 1 year old, you were only two feet tall, so now you're a million miles high, right? Or to put it in precise terms: public addresses are not memory. They are not like memory. Analogies with memory do not support your argument. At all.

Thank you.

Re:And I was just thinking

[tchuladdiass]

> So you're advocating security through obscurity? Well, I think everyone advocates this. If you don't beleive in the obscurity thing, then tell me, what is your credit card number, bank account, ATM pin code, Slashdot password, etc..., or would you rather keep them secure by making them obscure?

Re:And I was just thinking

[Daniel Phillips]

Do you think before you post or just say what ever come out of your butt? Sorry, but this post is so uninformed that it is distrubing. IPv6 was designed from the ground up to deal with the existing limitations of IPv4; therefore, you would be an idiot to make things a subset of the existing design...

It's hard to see how you got modded as "informative". What I said was: "For starters, it's essential that the old addressing scheme be a straightforward subset of the new one." In other words, you read it backwards, dear Coward.

The primary design goals of it were to 1) Increase the # addresses available and to have addresses autoconfiguring. 2) Increase security 3) Improve network routing and ease network autoconfiguration. IPv6 accomplishes all these goals and very well.

Maybe it does. But it falls flat on its ass on the big ones: compatibility and usability. Unfortunately, that's what you get when a design committee goes to work in splendid isolation, and without the benefit of talent.

Re:And I was just thinking

[mengel]

For starters, it's essential that the old addressing scheme be a straightforward subset of the new one.

Actually, it is. There is a whole block of IPv6 which is the IPv4 address space. So if your IPv4 address is 10.20.30.40 your IPV6 address is :0a14:1e28 (you convert the bytes to hex).

The IPV6 designers spent (and continue to spend) far more time on the migration issues than on the actual protocol changes.

Re:And I was just thinking

[hurtta]

nice if the new scheme resembled the old one as much as possible. What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers? Simply grafting on another 8 bit section boosts it to a trillian addresses. THAT'S PLENTY! You'd still have a hope of being able to deal with the raw number when you have to.

Well, purpose of multiply length of address was make routing easier. When address is long enough you can 'encode' routing to address. In other words routing is possible to do more than nowdays just with simple prefixes. This method is nowdays also used, but number if different prefixes what is needed for routing is bigger when address space is more near of full.

Re:And I was just thinking

[Daniel Phillips]

"So you're advocating security through obscurity?"

Well, I think everyone advocates this. If you don't beleive in the obscurity thing, then tell me, what is your credit card number, bank account, ATM pin code, Slashdot password, etc..., or would you rather keep them secure by making them obscure?

It's not a credit card or bank account, it's an IP address. I will happily tell you my IP address, and you will still not be able to log onto my system.

But I've got advice for you: just don't tell anybody your IP address, then you can use your girlfriend's name for your ssh login, in complete confidence :-)

Re:And I was just thinking

[Anonymous Coward]

It's a shame that you have the capacity to breed.

Re:And I was just thinking

[joto]

My question is simply, why does every appliance need an IP address?

It doesn't. But in many cases it would be useful. How about an IP address for each envelope you put in the mail, so you can easily track them without relying on your local postal service?

Rather, why do they need a public one. I can see starting the dishwasher from my PC (via a timer or task scheduler or some such), but I don't see any need to start it from outside my house.

I certainly see a need to control many other things from outside the house. For example, I want to cook my dinner before I arrive, and wash my clothes, ready to be hung up when I get home, without rotting inside the washing machine. And naturally, I want to control my car enginge heater (I'm from Norway), and lot's of other things. How about remotely starting your VCR to record a TV-show? A good argument for the dishwasher is hard to come up with, though... I am quite convinced that we will see a lot of useful applications of this soon, but whether it's going to be IP is certainly debatable. A more likely answer will be something sent over the standard cell-phone net.

My complaint is that your toaster doesn't need to be networked. Maybe I'm missing something, but I honestly can't think of 100 things that I own that I'd allocate IP addresses.

Then think harder. Almost everything I own that is electric (and some things that are not) should be controllable remotely by some means. Forgot to turn off the light? Log in from wherever you are and turn it off remotely. Forgot to lock your door? And so on... Of course, security is important, especially in the last example :-)

I understand adding more addresses, and I understand that network usage is growing, but the 32 bit number didn't cover every human on the planet 100 times over 20 years ago like a 40 bit address would now. Add an octet or two, we need more addresses, but quadrupling the length of the address is just a pain in the ass for anybody who needs to remember a few addresses, and it's overkill.

Yes, but they are much simpler to remember than simply 128 bits. Because for most practical purposes, those bits are there to simplify routing, and so, anyone that has to work with them routinely (i.e. network admins) will already remember the first umpty bits as common for their provider, the next dumpty as common for their company, and the last few bits will be just as hard (or easy) to remember as it is now. And in many cases, you don't even have to type the first umpty or umptydumpty bits, because they are implied...

Re:And I was just thinking

[laugau]

Actually, I am quite relieved. My biggest problem with X was that I could only connect to it from 4 billion different machines. Now, with IPv6, I can connect to it from 16quatrillion machines.

But since I trust all of my users, there is no reason to put it behind the firewall!!!

Re:And I was just thinking

[Daniel Phillips]

"For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."

Actually, it is. There is a whole block of IPv6 which is the IPv4 address space. So if your IPv4 address is 10.20.30.40 your IPV6 address is :0a14:1e28 (you convert the bytes to hex).

You're talking about rfc 2893 ipv4 compatibility? Well, "IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling". Dumb dumb dumb.

The IPV6 designers spent (and continue to spend) far more time on the migration issues than on the actual protocol changes.

That's because they didn't make it enough like the current system, even though that would not have been hard to do. Come on, is this or is this not an observed fact?

If I could just drop in an IPv6 stack and have everything just work, I'd no doubt be running IPv6 right now, and I'd own at least one public IPv6 address. As it is, I don't own any IPv6 addresses because I wouldn't be able to connect to them from outside anyway. And yes, there would still need to be a way of enabling the most significant octet, but with the stack in place at home and at my ISP (because it just works, duh) we're already most of the way there.

Re:And I was just thinking

[Daniel Phillips]

"My question is simply, why does every appliance need an IP address?"

It doesn't. But in many cases it would be useful. How about an IP address for each envelope you put in the mail, so you can easily track them without relying on your local postal service?

Oh, and so my letter can serve me a web page as it crosses the Gobi desert?

How about not doing any such wrong-headed thing, and give your envelope a url instead, if you must. The things you want to do with an envelope just do not resemble the things an IP stack wants to do with a web host. In short, an envelope is not a web host, so does not need a web address, let alone a public one.

Now, go back and read your own post critically.

Which of your ideas requires an IP address and wouldn't work perfectly well with a url?

Re:And I was just thinking

[Daniel Phillips]

Maybe when they start sending nanotechnology to mars they want it all to have different ips?

Boy, you're in luck, because with 128 bits you can address every single atom in the galaxy, individually.

Maybe your identification card will have ip address?

I hope not, and even if it did, we are still far from the 100 IP addresses per person we could have with a 40 bit IP address instead of 128.

People who can't think of uses for advanced technology are definatly lacking in imagination.

People who justify bad designs with bogus arguments are hazardous.

Also there's a lot more to ipv6 than just more addresses...

But we're talking about the stupidity of 128 bit addresses.

So argueing against future proofing the address size isn't even addressing half the advantages of ipv6.

We're not talking about any aspect of ipv6 beyond the type of the address. By making it 128 bits you simply make it user-hostile, which is a fine kind of future-proofing.

Also when you say "MY toaster doesn't need to be networked" That sounds a lot like the visionless dumbasses who said "A laptop? Oh ya who is gonna carry a fricken computer around with them everywhere!" Well not only where those people morons but now we have PDAs that take laptops a whole step farther than anyone was expecting at that time.

OK, you give *your* toaster a public IP address, and call yourself a visionary.

Really you sound like one of those unemployed lamewads who sits around his public housing apartment talking about "Dude! Amiga for LIFE! Assembly is what REAL hackers use! You all suck!"

You should talk, my fine Anonymous Coward. Beyond your rhetoric, there's no substance.

Good thing "640k is enough for anyone" types such as yourself aren't responsible for anything

Excuse me for repeating myself, but we're not talking about memory, we're talking about public IP addresses. A byte of memory is not the same as an IP address. (And argument by analogy is just rhetoric.)

http://nl.linux.org/~phillips

Re:And I was just thinking

[cayenne8]

I'm a newbie to all this, but, isn't this tying of a MAC address to the IP a problem similar to the Intel P3 id number? Wouldn't this make anonymity harder on the network...? Would this not be a number tying information transmitted to a specific machine, and hence a specific person?

Just curious about how this could affect privacy and anonymity on the net....

Re:And I was just thinking

[cakoose]

You have to be reasonable though...

Why not just double it to 256-bits so that every atom in our galaxy can have 100 million addresses?

The parent poster is simply trying to be reasonable, though I'm not sure I would agree that 183 per person is enough. It would be nice to have more addresses so that you can organize things heirarchically (lots of addresses will get lost here). Also, NAT is a hack to get around the 32-bit limit so I wouldn't want to have to rely on it again. But I think that 64-bits is more than enough to handle our needs for a very long time. 64-bits isn't really that hard to type in either (xxxx.xxxx.xxxx.xxxx).

Re:And I was just thinking

[Enry]

Excuse me for repeating myself, but we're not talking about memory, we're talking about public IP addresses. A byte of memory is not the same as an IP address. (And argument by analogy is just rhetoric.)

One thing about disk space, memory, bandwidth, and IP addresses will always be true: growth is going to increase.

It's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of. Once we go to 128 bits there is a very good chance that humanity will NEVER have to deal with this issue ever again.

Look at how long it has taken IPv6 to get to where it is now. It's been YEARS. Imagine doing that every 10 years or so. Go from 40 bits to 64...64 to 96, 96 to 128. Why bother taking baby steps?

Re:And I was just thinking

[joto]

Oh, and so my letter can serve me a web page as it crosses the Gobi desert?

Why not? Now, I agree that it would be completely useless, unless it also had a GPS and a wireless networking connection, and some sensors to see if it had been opened or damaged, so it could send you useful information about it's current state. It was also intended as a farfetched example, in case you have no sense of humor or reality.

How about not doing any such wrong-headed thing, and give your envelope a url instead, if you must. The things you want to do with an envelope just do not resemble the things an IP stack wants to do with a web host. In short, an envelope is not a web host, so does not need a web address, let alone a public one.

I have no idea why you are bringing the web into this. I can't for the hell of it think I've mentioned webservers anywhere. And an url would be completely useless for an envelope. Why would you want an URL for it? So that you could post information about it on a webserver at the other side of the globe. Hell, I can give all my envelopes an URL today, and it would serve absolutely no purpose (just as I could give them a number, which would serve no purpose either).

What you want is a unique way to address it, and connect to it, and while URL's do that in theory, in practice they work by connecting to a server, and you would still need a unique address for the (proxy-)server to connect to the envelope. This could be an IP-address, a phone-number, or any other such identifier. But it could not be a pathname on a server. So why do you need that (proxy-)server there at all?

Now, go back and read your own post critically.

Which of your ideas requires an IP address and wouldn't work perfectly well with a url?

All of them, with the exception of those inside my house, which could have local addresses, which could be accessed by going through a proxy (or "main pc" inside the house). But nowhere in my post did I single out IP as the solution to everything. IP is one possible address scheme. So is phone-numbers. And there are probably others.

URL's are not a useful alternative. They are for pathnames on a server, and not for addressing individual devices.

Re:And I was just thinking

[Daniel Phillips]

It's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.

Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users.

Re:And I was just thinking

[Enry]

Waitaminute. The reason you say it's bad has to do with the fact you can't remember that many bits anymore. What's all the other reasons that 128 bits is bad? Too much bandwidth consumed to build the IPv6 header??

Re:And I was just thinking

[Daniel Phillips]

it's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.

"Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users."

Waitaminute. The reason you say it's bad has to do with the fact you can't remember that many bits anymore. What's all the other reasons that 128 bits is bad? Too much bandwidth consumed to build the IPv6 header??

You can't remember that many bits either, or I will eat this disk. Nobody can, so that's already a big, fat (that's "big", "fat") problem.

It's not just that, of course. Will you ever have to type in all those, eh, "bits", as you call them? Yes you will. Sometimes you will have to do that. It takes 4 ("four") times as much typing to type in 128 (ehm) bits, as 32.

Current ip address notation, using decimal digits separated by dots, it's human-friendly. Push it to 128 bits and its just evil. However, at 5 bytes its still fine. Note: going to hex notation for 5 byte addresses would be a good idea. It saves typing and is easier to remember the addresses, if anything. On the downside, it could conceivable become easier to confuse a host name with an IP address. A little.

Did you ever set up WEP? Setting up WEP is painful. It wasn't meant to be done by humans. The numbers you have to type in are just too long, and you have to try many times, usually, because there are quite a few settings to tweak before you get it working. (Hey! Just like setting up a machine on the net!) Now, there's an excuse in the case of WEP. You do need a cryptographic key. But public net addresses are not cryptogrpahic keys. The shorter the better, from the point of view of usability.

Suppose postal codes had 35 digits. Do you think anyone would bother?

Now I don't expect you to understand the next point, but: give programmers an easy way out, and they get lazy. Let them route by indexing on a simple prefix of the net address, and they won't bother thinking up indexing algorithms for routers that work just as well, and don't rely on simple prefixes, but are a little harder to design.

In summary: going to 128 bits was just plain stupid, given that the problems are real and the benefits imaginary. Going to 40 bits would have been smart, it does the job with minimum fuss. For bonus points, write the RFC so that going to 48 bits later is painless, even though it's pretty obvious we won't be needing more than a trillian public addresses until we start colonizing the galaxy.

Anyway, we'll get another chance to do it right, because ipv6 is going to fail - it's never going to be widely deployed on personal computers. People will just keep using ipv4 with NAT, because ipv6 has too many problems.

Not just theoretical problems, but actual nasty, time wasting problems that get in your face. (And we didn't even talk about the way they dropped the ball on IPv4 address compatibility, or did we.)

Re:And I was just thinking

[Enry]

It's not just that, of course. Will you ever have to type in all those, eh, "bits", as you call them? Yes you will. Sometimes you will have to do that. It takes 4 ("four") times as much typing to type in 128 (ehm) bits, as 32.

Whine whine. That's why we have DHCP, among other things. You seem to think that entering an IP address has to be done every day. It doesn't. You set it and leave it until you need to change.

Suppose postal codes had 35 digits. Do you think anyone would bother?

It already had 9 in the US. To dial a phone number, you typically need 10.

In summary: going to 128 bits was just plain stupid, given that the problems are real and the benefits imaginary.

Nice troll. You've proven nothing. Your only problem is that you can't remember 128 bits, which is not my concern.

Not just theoretical problems, but actual nasty, time wasting problems that get in your face. (And we didn't even talk about the way they dropped the ball on IPv4 address compatibility, or did we.)

You didn't enlighten me with your knowledge. But that's okay. IPv6 and IPv4 work just fine together and have for years.

You are short-sighted

[Rosco P. Coltrane]

This is surely a relief for the masses here that longed for X support for IPV6. Or the contrary?

I don't care about IPv6, you don't care about IPv6, my grandmother doesn't care about IPv6 and 99.99% people don't care either. And even fewer care about X supporting IPv6 (hi guys). But one day in the future, you may care, when IPv6 spreads out, and if you happen to want X working that day you'll be glad.

Some dude at Microsoft, echoing what many people thought at the time, said nobody needed more than 640K in their computer. Just look at how much RAM you have today ...

Prediction

[Pres. Ronald Reagan]

My prediction:

There will be two posts that, without base or thought, recommend replacing X with a different default windowing system on Unix for every one post that discusses the article.

Re:Prediction

[WindBourne]

hummmmm.
You are wildly exagerating how many posts and you are forgetting that no real relavance will be given to those posts unless you are doing something about it.

You may be the Ex-Pres afterall.

Re:Prediction

[budgenator]

(e.g. "ive never neieded 2 use xwindows over the network, y would any1 ellse!!??").
I'm not a network guru or anything but x over lan was a life saver until I figured out that ip forwarding in linux. I did that to share a dialup connection that was rarely faster than 33K.

yup x windows sucks, it sucked before windows95 was released and it'll suck after they quit supporting windowsME

Perhaps

[fireboy1919]

I can think of what that will be like.

"Hey...X doesn't work with IPv6. I'll just tunnel it through an IPv6 ssh tunnel. Problem solved."

I guess I won't have to worry much about that day.

Besides, if you're using X over the net WITHOUT ssh (the only place where IPv6 is necessarily needed, since everywhere else you can use private addresses), what are you thinking?!!!

It's WAY to slow without compressing, which means sending it through some kind of tunnel. Personally, I think it's way too slow anyway. RealVNC beats it for bandwidth usage and it's just a framebuffer, even compared to dxpc and lbxproxy (at least that has been my observation).

Re:Perhaps

[Phil Karn]

I agree, X is one of the less compelling applications for native IPv6 support given that just about everyone I know already tunnels it over an SSH connection. SSH has had IPv6 support for some time, so you can easily SSH into a machine with IPv6 and invoke an X session with the IPv4 connections on each end that never leave the local machines.

SSH tunneling works so well for X that I wouldn't even mind if all IP support were removed, as long as there was still a way (e.g., UNIX domain sockets) to connect the SSH daemons to the X server and client on each end.

That said, it's still a good thing for X to support IPv6, just in case someone wants to use it. Every Internet application should support both IPv4 and IPv6.

Re:Perhaps

[evilviper]

what are you thinking?!!!

IPSec does the encryption you know... It's not that crazy.

The problems with X need to be addressed by X developers, not by more hacks. Tight/RealVNC work fine for now, but they absolutely suck compared to the better methods out there.

It's pretty amazing really. Very often it seems that Linux/BSD is far ahead of every other OS out there, except when it comes to X, which is in quite a sorry state.

If you'll excuse me, I have to reboot so I can change my resolution now. After that I think I'll swap videocards, and just sit back and watch as XDM tries to restart X every second for hours at a time... Then I'll spend a week trying to get TV-out on my video card to work, and end up throwing my computer through the window instead.

Re:Perhaps

[Wumpus]

The problems you mentioned are fixable (and by that I mean working out of the box in some current Linux distributions, available now, and running on my machines).

Changing resolutions works with xrandr now.

As for XDM being brain-dead, I recently broke my XF86Config on a RedHat 8.0 system, and then had the brilliant idea to try and log out. Sure enough, XDM did its "X didn't start - must have been cosmic radiation. Let's try again!" thing, but after a couple of times of that, SOMETHING in the system decided to put a stop to this, dropped me to the command line with an error explaining what happened, and some helpful hints how to proceed.

I've read and hacked X server code. It's ugly, but it isn't the bloatfest people seem to think it is. Moving to glibc 2.3 did more for desktop responsiveness on my machine than any amount of twiddling with X could have done. It isn't X that's slowing things down.

Re:Perhaps

[iabervon]

IPv6 has a class of addresses for ad hoc networks (i.e., you have three friends with laptops and an ethernet hub, sitting in a cafe. You plug the cables in. You have a working network, with addresses), and other such special-purpose addresses. So it would be a good mix with IPv6 for some situations, at least. First thing that comes to mind is a modern X terminal: display box with a SA1110, a high-end graphics card, a keyboard, a mouse, and a gigabit ethernet card, running an accelerated X server for any client on the local network using its IPv6 ad hoc address. You plug it in, give it network, and you have an extra display for any computer in the house with no need to interact with the display box at all.

Re:Perhaps

[ColaMan]

SOMETHING in the system decided to put a stop to this

init will get the shits if a restarts a process too often in a certain period of time and will kill it off.

(init being the "master" program that the linux kernel loads as boot... it loads everything else. It's normally the first process if you type 'ps ax' at a prompt)

Re:Perhaps

[zurab]

It's WAY to slow without compressing, which means sending it through some kind of tunnel. Personally, I think it's way too slow anyway. RealVNC beats it for bandwidth usage ...

You are comparing apples and oranges. You need to learn the difference between X client/server vs what VNC does. In the former case, X client is running on the client machine and X server on the server machine; in the latter case, X server, client, and VNC server are running on the server machine, and only VNC client on the client machine. They each have different capabilities, pros/cons, and different uses as well.

Re:Perhaps

[listen]

You have to try NX.

www.nomachine.com

It beats the pants off of any other remote desktop in terms of speed. Fully X based.
Bits are GPL (proxy), bits are BSD (x lib patches) and bits are proprietary (gui) - if the proprietary bits are reimplemented it could be a killer app.

Re:Perhaps

[caluml]

I agree, X is one of the less compelling applications for native IPv6 support

Not at all.
Think about full screen X logins, a la X -query w.x.y.z. I've never worked out how to tunnel a fullscreen login over SSH.

Re:Perhaps

[tom.allender]

IPv6 has a class of addresses for ad hoc networks.

IPv4 has these as well. 169.254.*.* ?

Re:Perhaps

[Ed Avis]

Quite. Rather than adding more features/kludges to X11's authorization to cope with IPv6 addresses, might it not be better to abolish it altogether?

All this xhost / xauth / MIT_MAGIC_COOKIE stuff really needs to die. I can see the point of keeping it around for compatibility, but nobody is requiring 'compatibility' with some mythical Sun3 or MicroVAX using IPv6. Why not have the X server accept connections only on a single Unix socket, and then if you want remote connections you can use a separate daemon (such as sshd) to handle the authorization?

Or in the worst case they could use Kerberos.

(And why yes, I did recently read the appropriate chapter of the UHH... but I knew this stuff was a crock even before then. Ssh tunnelling is great. Plaintext X traffic with half-baked 'authentication', xdm protocol and so on is not.)

Re:Perhaps

[iabervon]

Yeah, but you have to then assign the addresses in the block. The IPv6 version uses the device's MAC address so that each device has a unique ad hoc address out of the box. Handy for groups where nobody's running DHCP and the people don't want to negotiate the addresses themselves.

Re:Perhaps

[MikeVx]

If you'll excuse me, I have to reboot so I can change my resolution now.

Hmmm... When I set up my X server, I define all the resolutions I might want ahead of time, then I can cycle through them with a multi-key sequence.

After that I think I'll swap videocards, and just sit back and watch as XDM tries to restart X every second for hours at a time...

Well, if you actually use a graphic mode boot you deserve that one. If it is critical that the user get a GUI, that should be done in the appropriate profile script after a text log-in. If X barfs on a video problem, the script can check for an errorlevel and not log out as you might normally want to do. I flinch when I see a graphic login screen as I know that I'm in for one whale of a headache if a video problem develops.

Then I'll spend a week trying to get TV-out on my video card to work, and end up throwing my computer through the window instead.

Now I can understand the frustration here, but when you go out of the Windows world, you have to put up with this sort of thing. Only a relatively few companies see fit to offer non-windows options for thier hardware.

Re:Perhaps

[linhux]

Actually, private RFC1918 adresses is a menace and should not be used anywhere except in extreme situations. They create more problems than they solve.

Re:Perhaps

[Crispy Critters]

Besides, if you're using X over the net WITHOUT ssh..., what are you thinking?!!!

X forwarding with SSH is fundamentally broken. It is a kluge.

Here is the problem. If I am sitting at localmachine and running an X app through ssh on foreignmachine, the X resources used are those stored on foreignmachine. The purpose of .Xdefaults is so I can set the parameters of programs to fit the local display, and these files are going to be different on a laptop with a small screen, a desktop at 1600x1200, and a crappy old X terminal, because things like the size of the window the app opens, whether to limit color usage, what colors are usable as background behind black text, and so on are going to be different for these displays.

In some circumstances, using .Xauthority is better and easier. If you often do work using a set of servers that share home directories, all you need to do is copy .Xauthority from your local machine to the server if you restart X. It is also possible to use xhost with relative safety. A machine only needs to be xhosted to start the X connection, so you "xhost +foreignmachine", start app, "xhost -foreignmachine", use app for as long as you like. In both cases, the programs use the correct X resources.

This avoids another annoyance with ssh's X forwarding. If you ssh to a machine and start an X app, the logout hangs until all the apps using the X forwarding are exited. (This can be avoided somewhat by using "ssh foreignmachine command&", but requires full pathname for command and any files. Or the "~&" command will allow you to logout leaving X apps behind, but you have to remember to do it before hitting ^d.)

I use ssh with X forwarding often, but it is not a replacement for all the other security methods X has evolved. Obviously there are times when encryption is important, but usually it isn't. It hardly matters if someone can spy on me while I am editing my public web page as long as they don't have direct access to my X server.

Re:Perhaps

[Phil Karn]

Thanks, I've never had to do a full-screen remote X login so I didn't know that.

I think IP v6 is not ready for IP v6

[stonebeat.org]

I think IP v6 is not ready for IP v6 :)

Higher Priorities

[Bonker]

Yeah, it'll be nice to have ipv6 in place when we need it, but I think a higher priority would be to speed up X's abysmal performance when compared to most other modern windowing subsystems out there, including Aqua and Windows' GUI.

The guy up above noted that there would be discussions on X needing to be replaced. I don't think X needs to be replaced it just needs to be more efficient. <blatant lack of application engineering knowledge> If *everything* has to go through a tcp/ip stack before it goes to the monitor, there should at the very least be some speed improvedments.</blatant lack of application engineering knowledge>

Re:Higher Priorities

[HBI]

Everything doesn't go through a tcp/ip stack.

Are you using DRI?

If you were, you'd probably not be complaining about performance.

You might want to consider compiling Xfree86 + DRI modules for your arch also.

Re:Higher Priorities

[Anonymous Coward]

Clue1: X uses UNIX domain sockets when run locally. This is actually quite efficient.

Clue2: X is fast when used correctly, as some toolkits seem to not do.

Re:Higher Priorities

[ahaning]

DRI (when it works; it's flakey on my Radeon VE) is fast at OpenGL stuff and playing video through the xv extension. I don't notice any change in 2D speed (window moving and such) with DRI loaded as opposed to without it loaded. I don't know about most other people, but this is what's most important to me.

However, it could just be that Mozilla's use of XFree86 is really slow. Other programs (abiword, gnumeric, dillo, netscape 4.7, xmms...) are faster.

Okay, so that wasn't too helpful. But, really, when people complain about poor performance, they aren't always talking about GL and video playback.

Re:Higher Priorities

[alienw]

It works poorly with the Radeon because ATI makes shitty drivers. Get a real videocard (nvidia) and you'll appreciate the sudden disappearance of flakiness.

As for the rest of your complaint: take the beef up with application or toolkit developers. X sure seems faster than Aqua for me, even for Mozilla. Mozilla is pretty slow by itself. Also, the desktop doesn't run in double-buffered mode, so the windows don't exactly move smoothly. This is not an X problem, it's a toolkit/desktop environment problem. If KDE doesn't use XRender and Xv to render faster, it's not an X problem.

X certainly has its inherent problems. Slowness is not one of them.

Re:Higher Priorities

[dbarclay10]

Yeah, it'll be nice to have ipv6 in place when we need it, but I think a higher priority would be to speed up X's abysmal performance when compared to most other modern windowing subsystems out there, including Aqua and Windows' GUI.

Yeah, I know, you're trolling, but hey - why not use this as an opportunity to enlighten others? :)

Many people, unfortunately, misunderstand what X is. Basically, X is a hardware abstraction layer. Each app doesn't need to code specifically for each video card, nor do they code specifically for a given output device.

Instead, X exports a fair number of "primitives" which applications use. The X server then renders these primitives. Normally to a screen.

How does the X server get these instructions, for lines, pixels, polygons, bitmaps, and what have you? That primarily depends on the task at hand; there are a number of extensions and modules that are used when they're needed. There's DRI, which allows a very, very thin abstraction layer. There's TCP, which lets apps talk X over a network. Loads of other ones. Shared memory and UNIX domain sockets are used for general local communications, just as fast as any other platform.

"Wait! You're describing a video driver!" you might say. Indeed, you'd be right; XFree86 is you're computer's video driver. But instead of each driver needing to be 20M full of duplicated code, we have small driver-modules, which share a common code base (the rest of XFree86). XFree86 also includes the libraries apps use, a (very) basic GUI toolkit, the tools to control your video drivers, etc., etc.

Is XFree86 slow? No. I'd like to see some benchmarks where XFree86 is more than 1-4% slower than a similarily-functional Windows or Mac driver. You might have trouble though, since none exist.

Last time I booted into Windows 2000 and tried to run a game, it came out at about 62 frames per second. The same game under XFree86 ran at about 64.5 frames per second. Why such a little difference? Because XFree86 with a decent video card is just as fast as any video drivers you'll find under Windows. The differences in speed I saw had nothing to do with XFree86 and everything to do with what I was running it on; CPU-intensive programs I run under Windows 2000 which don't do *any* graphics whatsoever are almost exactly 4% slower than under Linux; the same difference I saw when running that game.

Re:Higher Priorities

[ahaning]

Heh. You need to be a little more informed.

It works poorly with the Radeon because ATI makes shitty drivers. Get a real videocard (nvidia) and you'll appreciate the sudden disappearance of flakiness.

ATI doesn't write (many of) the drivers for XFree86. They've started to write some, but AFAIK, there are none from ATI for XFree86 for the Radeon VE. The ones I'm using are written by the DRI developers and are opensource/free software.

As for the rest of your complaint: take the beef up with application or toolkit developers. X sure seems faster than Aqua for me, even for Mozilla. Mozilla is pretty slow by itself. Also, the desktop doesn't run in double-buffered mode, so the windows don't exactly move smoothly. This is not an X problem, it's a toolkit/desktop environment problem. If KDE doesn't use XRender and Xv to render faster, it's not an X problem.


I admitted that certain programs (generally GNOME 1.2 stuff, since I don't have KDE libs or GNOME 2 libs installed) are fast, and that maybe it's just Mozilla that is slow. This seems the most likely, since they really don't have time to go trying to get it to work perfectly on a little-used platform (XFree86 as compared to Windows). I don't know where KDE comes in here. I use FVWM2, myself.

Re:Higher Priorities

[nathanh]

<blatant lack of application engineering knowledge> If *everything* has to go through a tcp/ip stack before it goes to the monitor, there should at the very least be some speed improvedments.</blatant lack of application engineering knowledge>

It's not clear if you're being sarcastic or serious but you've been moderated Insightful and Interesting. So it'd be best if everybody is clear that with XFree86 your local X11 does not go through the TCP/IP stack; it goes through a UNIX socket. Pixmaps can optionally go through SHM. And if you're very lucky then your client can write directly to the hardware using DRI or DGA.

Re:Higher Priorities

[Alien Being]

Clue1: X uses UNIX domain sockets when run locally. This is actually quite efficient.

It's efficient networking, but it's not an efficient graphics system. The app still needs to stream the data to X which must wake up, read it, and write it to the hardware.

Fortunately, XFree86 provides connectivity at 4 levels.

• network (full protocol stack over the wire).
• UNIX sockets (no wire, shorter stack).
• local shared memory (less copying)
• direct rendering (no copying, no context switching)

Re:Higher Priorities

[IamTheRealMike]

Mozilla is pretty slow by itself.

To be more accurate, Mozilla is fast, but the Mozilla X/GFX module is not tightly optimized. I once saw a trace (a long time ago now) that indicated it drew the same things 3 times in a row.

Also, the desktop doesn't run in double-buffered mode, so the windows don't exactly move smoothly. This is not an X problem, it's a toolkit/desktop environment problem.

Ah, no, it's an X problem. GTK2 does in fact double buffer everything (i assume Qt does too but I don't know for sure). Tearing is caused by the latency between an application getting its windows damaged/resized and repainting them. What you mean by "double buffered desktop" is actually a desktop where the display engine repaints damaged areas synchronously without waiting for the apps to catch up, so the movement/repaint takes place at the same time.

X provides something that lets you do this, called backing stores/save unders (terminology depends on whether you're speaking from context of client or server). Unfortunately, they are broke. They ship on XFree disabled by default for various reasons, but if you're curious enable them then try scrolling a text view in GTK. You'll see the memory usage of X go up and up, because it treats the scrolled area as one big window and tries to save huge amounts of garbage, never freeing it (or something).

If KDE doesn't use XRender and Xv to render faster, it's not an X problem.

XRender is cool, and has a lot of potential, but right now it's not heavily optimized and is quite slow. Not all drivers accelerate it, in fact I'm pretty sure most don't. Xv is a bit left field, I assume you're talking about fast scaling - Xv requires pixel data to be in video colourspace, it's not particularly suitable for desktop usage. XRender provides the opportunity for accelerated scaling, but again, XRender isn't finished and it's not optimized.

Re:Higher Priorities

[FooBarWidget]

Tell that to all those animation studios who use SGI or Linux boxes and X to produce/edit their animations.

Hmm... so for some reason X works for animation studios but doesn't on the "normal" desktop? Either there's something wrong with your reasoning or it's the *implementation* of X that's at fault, not the entire interface/system/design.

Verry wrong.

[Anonymous Coward]

You are so wrong, my presription glasses had to be wiped clean.

The purpose of IPv6 is: fix some flaws within the design of IPv4 and expand network addressing.

If you think IPv6 is a waste of time, you wait when the global networks start using IPv6 for the same strengths they needed and IPv4 did not provide.

If you think IPv6 is a waste of time, you wait when you need an IPv6 X client to connect to your server and VPN is not an option.

If you think IPv6 is a waste of time, you wait when even streaming media or realtime data requires IPv6.

LOOK: IPv6 has strengths that IPv4 doesn't have and never will be able to have, with exception to workarounds on the application layer. Don't knock IPv6, it is a Good Thing(TM).

Re:Verry wrong.

[fbroooooz]

If you think IPv6 is a waste of time, you wait when the global networks start using IPv6 for the same strengths they needed and IPv4 did not provide.

If you think IPv6 is a waste of time, you wait when you need an IPv6 X client to connect to your server and VPN is not an option.

If you think IPv6 is a waste of time, you wait when even streaming media or realtime data requires IPv6.

Exactly: when I need IPv6 to view streaming media in new and improved uberquality, or when I need it to connect to my machine at work, THEN i will take a look at it. Until that time, I will resign myself to reading emotional discussions about it on /.

Re:Verry wrong.

[alonsoac]

You got it nailed, you wait and wait and wait and someday you will need to care. Or in my case I hope by the time IPv6 is widely used I'll be long over with this computer-geek crap I'm pulling now.

Problem...

[yehim1]

IPv6 support for X seems to be a logical move, since the only way IPv6 would be embraced by the masses would be the support by the applications. After all, it takes but a few changes to the network layer socket code for the different packet structure.

However, the applications layer is important as well. For example, the X team has to consider changing XDM-AUTHORIZATION-1 to XDM-AUTHORIZATION-2 since the earlier could not support the longer packet structure.

Another change of mindset for X users that is required is the way of specifying the display number (:0, :1, etc) with the IPv6 address, since both IPv6 and the screen number uses the colon (:) separator.

Thus, the traditional way of denoting 2003:1080:1111:4034:1212:3fdb:1123:0001 with screen :1 would be

2003:1080:1111:4034:1212:3fdb:1123:0001:1 !!

For the clients, the X team has suggested the use of strrchr or rindex in their code so as to maintain compability.

For the human users, we need a DNS (most probably, since the address is too long to remember), or, well, we can all use an extra octet in the address, can we?

--

Re:Problem...

[nsayer]

The fix for this is to specify IPv6 literal addresses inside [], which is the solution for IPv6 literals in URLs. For example, the IPv6 equivalent to 127.0.0.1:0 is [::1]:0.

cool!

[VAXGeek]

now one standard no one seems to like can use a standard that no one likes to use!

Remove head from ass

[Anonymous Coward]

The latest X is Version 11 Release 7; shouldn't you call it X11R7? I read the manpage: man X.

X is not from MIT. There is an MIT X CONSORTIUM that designs and publishes the standards for X.

To my understanding, there are many implementations of X:

X86
XFree86
XDirectFB
TinyX
Accelerated-X
M etro-X
WeirdX
PicoGUI (yes, PicoGUI provides X services too...server)

That's all I can remember. All trademarks have been infringed by me. I 0wn all commercial X servers unlawfully. Have a nice day :)

Re:Remove head from ass

[WindBourne]

Actually, it was developed by Jim Getty while at MIT.

Re:Remove head from ass

[Sique]

Actually, it was developed by Jim Getty while at MIT.

The same one that is spawning all those getty-processes at my box?

Re:Remove head from ass

[nexex]

Xsun

Re:Remove head from ass

[jimfulton]

Not to be too pedantic, but there *was* (past tense) an MIT X Consortium from 1988 through the mid 90s. However, the X Consortium moved out of MIT and became an independent organization. After an abortive attempt to have it run by somebody else, Bob Scheifler (the original lead architect on all versions of the X protocol, 1 through 11 and a true leader of the X community for many years) stepped back in and run the independent organization for several more years.

Eventually, the X Consortium faded away and transfered control of the standards into The Open Group, under whose auspices x.org now operates.

As mentioned, various implementations of the X standard, particularly XFree86, came to overshadow the standards organization. Now, the xwin.org effort looks like it will be taking up the mantle.

Jim Fulton
X Consortium staff member many, many years ago

Re:IPv6 is just a backbone technology

[toasted_calamari]

I don't understand why IPv6 would ever catch on as anything but a backbone protocol

I'm afraid I have to disagree. Maybe we don't need IPv6 *right now*, but networks are growing at an alarming rate. it would not be hard to see a future in which almost EVERYTHING is attached to a network, your PDA, desktop, laptop, car, appliances, watch, etc.

while you could just stick everything behind a NAT, why do it when you can give everyone (and everything) an IP, why add that extra level of complexity.

Whenever a new development comes out, people always claim that it will never catch on, because the current system works fine. However, they are usually wrong. "this will never catch on" is broad statement to make. "never" is a big time range.

Re:IPv6 is just a backbone technology

[Phil Karn]

There are a few important situations where IPv6 is already The Right Answer.

First on the list is accessing servers behind a NAT. Wouldn't you like to connect directly to the multiple Linux boxes behind your NAT box without having to first log into the NAT and out again, or having to set up ad-hoc port forwarding kludges? Configure 6to4 on your NAT (easy if it's a Linux box) and you can establish a direct logical end-to-end IPv6 ssh connection even if the path in the middle is IPv4 only. Works great for me. I have been maintaining my parents' network in exactly this fashion for some time now.

Also on the list is VoIP. Look at all the hassles involved in running H323 from behind a NAT. (SIP may be more NAT-friendly, I haven't investigated it yet.) If only H323 supported IPv6, life would be so much easier.

But the real killer app for IPv6 will be cell phones. If cell phones are to implement true VoIP, there is simply no alternative to IPv6 because there are simply far too many cell phones in the world for the number of available IPv4 addresses.

Basically, IPv6 is all about wiping out the NAT plague and restoring the end-to-end model that originally made the Internet great. That's exactly opposite to the claim you make in your subject line. If you don't use NATs, or if you're unimaginative enough to think that you'll never need to do what they make difficult or impossible, then you probably won't be excited by IPv6. But eventually you'll probably discover why IPv6 is inevitable, even though it will have to coexist with IPv4 for a very long time.

Re:Great!

[Anonymous Coward]

Oops. This is probably Xfree86 specific and has nothing to do with the official X distribution.

SSH tunnels, the "nazi analogy" of slashdot

[coyote-san]

It's time to declare a discussion over whenever somebody suggests SSH tunnels as the answer to all of the world's problems. Security, authentication, fresher breath and bedmates with big breasts! It's as predictable as a flame war escalating to the inevitable comparison to Nazi Germany.

If you knew half as much as you think you do, you would know that SSH tunnels are a clever ad hoc tool but they suck as a real VPN solution. They also don't give you nearly as much authentication as you think, since that information is not available to the user. In contrast my Unix socket code and SSL-aware applications always pull strongly authentication information about the peer as the first thing they do.

If you want to learn more, check out the documentation on CIPE... and try to write a tunneled application that can provide strong socket-level authentication of the peer's identity.

Re:SSH tunnels, the "nazi analogy" of slashdot

[aurelian]

on the other hand he loved SS tunnels

X Rules

[Anonymous Coward]

It might not detect any of my mouse buttons, but it sure as hell can address 2^128 nodes!

X's speed

[Phantasmo]

I'm running KDE 3.1.1 without DRI on a Pentium 2 running at 233MHz with 128MB of RAM.
Overall, I have to say that the speed is okay.
It's not as fast as, say, Windows 98, but it's still useable and sure looks a hell of a lot better.

I was showing off my machine to a Windows-using friend. I hit the power button and he sat there, watching the text fly across the screen. "Does it always take this long to boot up?", he asked. After KDM appeared and I typed in my password we had to endure another long wait as KDE started ITS services.
So, X is fine, but how about better startup times?

Re:X's speed

[datadictator]

Here is yet another nice trick to cut boottimes.

At the cost of a (slightly) slower initial runspeed at least.

I am asuming you have allready DISABLED/UNINSTALLED all the services you don't actually need.

Now head into /etc/rc.d/init.d and edit the files for the services you do actually use.

Be carefull here, this should ONLY be done for daemons that you run like mysql or httpd not system processes. For one thing, leave /etc/rc.sysinit alone for this one.

Now you are in the startup script for your first server 'k. Go the section for start. If it calls a function, go to that function. Find the line that actually calls the server process.

Stick an ampersand(&) at the end of it.

I hear you ask: why on earth put a service in the background, isn't it there allready ?

Yes my friends services RUN in the background, but they don't normally start there. And your distro patiently waits for it to finish starting before going on. What you are doing here is to put it in the background right from the getgo. The server initializes as a background process now. That way the system can keep going, running the next bootup script - until eventually it fires up your terminal/display manager.
The catch is that because you put service startup in the background, you may not actually be able to access mysql or whatever for a few secconds after bootup. And your first few secconds after the login comes up, some resources may still be busy starting servers, but that should end very fast.

One big hint, never do this with XFS or a display manager. If you try to start X without XFS fully loaded it buggers (this is especially likely with display managers running) and dm's hate to launch from the background (don't ask me why).

Need GUI's over HTTP

[Tablizer]

I have concluded that it is best if the GUI goes over regular HTTP. The red tape to get non-HTTP thru many companies is too great.

Although HTTP may not be the ideal protocol for GUI transport, I have concluded that it is satisfactory for most B-to-B biz forms if you "tune" it right.

My own pet draft GUI protocol, SCGUI, is an attempt to define such a standard. There is also XWT, but it is more fat-client than SCGUI, which attempts to define a non-Turing-complete protocol for improved security (although client-side T.C. scripting could be added).

Re:Need GUI's over HTTP

[Minna Kirai]

The lack of Turing completeness will be an useful feature of a protocol like that.

Eventually those same paranoid companies who run tight firewalls will get burned by application exploits over SOAP/XML-RPC, and will want all HTTP traffic cleansed for their safety.

As long as the messages are non-TC (meaning their results can be evaluated in a reasonably bounded time), it will be possible for proxy rules to be added to permit some GUI traffic. Otherwise, reactionary IT directors will want to ban it entirely.

Re:Need GUI's over HTTP

[Tablizer]

As long as the messages are non-TC (meaning their results can be evaluated in a reasonably bounded time), it will be possible for proxy rules to be added to permit some GUI traffic.

The protocol just uses XML, not binary stuff. Thus, the firewall admins shouldn't have to normally do anything different.

Do they filter by tag now? I have not seen that. Do many companies filter out JavaScript, by chance?

Re:Need GUI's over HTTP

[makapuf]

Turing completeness has nothing to do with security, I suppose.
It's the available API (or functions exposed by the OS given the rights the daemon has) that counts.
The lack of buffer overflows has some advantages. Sure they are TC, but that's not the point.
The "format c: when pinged" protocol is not turing complete.

Re:Need GUI's over HTTP

[Minna Kirai]

The guys I'm talking about, overly-restrictive IT directors, don't only want to protect their computers from outside people.

They also need to "protect" their employees from outside computers. That means things like restricting what content they can view, and being able to log or investigate any traffic that goes in or out. TC could undermine this- the data can do arbitrary things, meaning it could do some things the watchmen won't like.

Specifically, it could bootstrap an encrypted tunnel to let arbitrary unsnoopable data pass in and out. (Either completely protected if the end-user typed in his own local decrypt key, or otherwise just prohibitively expensive for the spy code to execute all the data to find out if it's contents are really allowed)

My megacorp employer, for instance, is very fearful of this. They block the SSH port (22), but not FTP or telnet(23). Being able to monitor their employees is actually more important than protecting their employees from being spied upon by others on the internet. (Additionally, their proxy parses HTTP and SMTP traffic, although IDK just what it's looking out for).

The actions that typical corporate infosec people will want to permit outside software to run are very limited. A non-TC language restricts what a program can do, making it's behavior easier to prove. (Thus, they can feel safe about allowing a strong language with a restrictive API, or a weak "language" with somewhat more powerful local permissions)

Re:Need GUI's over HTTP

[Minna Kirai]

I haven't seen much HTML-reading by filters, but I'm just a user.

However, one of the benefits you stated from using HTTP is that it will allow applications to run across firewalls. The people who installed the firewall, of course, will claim you're circumventing their protections. I predict that if executable or heavily interactive HTTP messages become more popular, firewalls/proxies will start to be instructed to filter out "dangerous" content (meaning anything that's more complex than a static page with CGI forms, or other traditional web-browser things)

Many corps need javascript for their "intranet" applications, but don't want to allow it for websites. However, I think they use security zone settings in Microsoft IE to do this.

Re:Need GUI's over HTTP

[Tablizer]

Many corps need javascript for their "intranet" applications, but don't want to allow it for websites. However, I think they use security zone settings in Microsoft IE to do this.

Stopping all outside JavaScript could be a headache for firewall managers. Many B-to-B forms use it heavily, meaning they would have to manage it URL by URL if they disallow it as a default for non-internal stuff.

Re:Need GUI's over HTTP

[Tablizer]

Turing completeness has nothing to do with security

I disagree. It not only makes the client more complex (needs run-time language or exe engine), but provides more ways to poke around by running stuff on the client.

Re:Need GUI's over HTTP

[Tablizer]

SCGUI is a good idea, but XWT is much more practical for a wide variety of situations.

Yes, but it does not appear to have a usable non-Turing-Complete protocol (or protocol subset).

I suppose that is the tradeoff: Scripting versus TC-safety. But that also means that XWT competes with the likes of XUL. I don't know of any other Non-TC competition for SCGUI over HTTP.

More IPv6 Support, Please

[serial frame]

We need to get this fucking ball moving. Look, people, face it, IPv6 is the future, has been tested and has very many stable implementations. It's already in Windows XP, so there's no reason to begin porting programs over to the more modern address resolution code. getaddrinfo() is much neater and lives up to POSIX ideals of code beauty. There is no reason your application-level code shouldn't be able to handle both IPv4 and IPv6, which is a result of using getaddrinfo().

We shouldn't stop at just X Window. Many other vital network-able applications should be on the list. VNC would be a prime candidate for IPv6 support; many programs such as ssh and standard utilities in the major BSD's already prove themselves in terms of IPv6 support. Instant messengers, online games, etc. should also be next on the IPv6 support bandwagon.

Honestly, there is no reason why we shouldn't take advantage of functions that make IPv6 transition (as well as IPv4 compatibility) trivial. IPv6 provides many clear advantages as to why it would be the next de-facto Internet protocol, thus I am able to say with certain confidence that IPv6 will be next up on the plate, and therefore applications should support IPv6 early on for the quickest, most painless transition. If you're interested in seeing why for yourself, just hit www.faqs.org/rfcs/ and search for RFCs on IPv6. They will tell you everything you may need to know as to why I'm ranting.

If you're interested in trying out IPv6 for yourself, I highly suggest using freenet6.net if you are running a flavor of Unix. Otherwise, on Windows XP and similar, simply type 'ipv6 install' on a command line, reboot, and test your connection with a simple ping6 www6.netbsd.org. Oh yeah, if you do join the IPv6 world, make sure your webserver supports IPv6--I'll be sure to visit :)

Re:More IPv6 Support, Please

[serial frame]

> there's no reason to begin porting programs over
> to the more modern address resolution code.

Whoops. I meant to say, there is no reason NOT to. *stops licking the caffeine rock paperweight*

Re:IPv6 is just a backbone technology

[ghostgum]

H.323 does support IPv6, it is just the implementations that don't. The 1996 release of H.225.0 (part of H.323) includes the following ASN.1 syntax.

ip6Address SEQUENCE
{
ip OCTET STRING(SIZE(16)),
port INTEGER(0..65535),
...
},

Other suported choices for TransportAddress are ipAddress (IPv4), ipSourceRoute, ipxAddress, netBios, nsap, nonStandardAddress, and "..." to allow extensions.

Re:X? X?!?

[zCyl]

Don't call it X.

Can I call it X2?

Re:IPv6 is just a backbone technology

[nexex]

agreed, with NAT, the internet just becomes the worlds largest star topology network, its no longer a 'web.'

when im work, it is the biggest pain to have to make all my connections to one box, then out from there, it makes needlessly complex. people complain X forwarding is slow over the net, try it going through multiple ssh sessions...

This would help me.

[YoungHack]

Every can keep going on about how this only helps 3 people in the whole world, but it would help me. I guess there must be 2 other people who would really like to see this come about.

Re:This would help me.

[caluml]

Yep. Me too. So who's the other one? :)

X and IPV6

[Anonymous Coward]

It already does support it. Guess it must not be official, but debian has an IPV6 aware X server in their ipv6 packages.

# ipv6 support
deb http://debian.fabbione.net/debian-ipv6 sid ipv6
deb-src http://debian.fabbione.net/debian-ipv6 sid ipv6

Re:X and IPV6

[uhoreg]

but debian has...

Please do not confuse Debian with unofficial sources. Just because you can apt-get some .deb packages does not mean that it is part of Debian. If it is not in the official repositories, Debian does not have it yet.

Re:Cool, right?

[mlk]

When then Windowing system is "widely" used for dumb terminals, yeah :)

Re:X is a thing of the past

[Erwos]

Would you like to inform us what exactly makes you knowledgeable enough about the subject to lecture us all about the need to dismantle X?

And, even ignoring your lack of credentials, your criticisms don't even seem to make sense.

"Whos runs X apps over the network?" I do, and I've seen _many_ places where people should as well. Quick example: my girlfriend does finite element analysis using ANSYS. She has to trudge up to the Linux lab every so often. If she was running ANSYS using remote X, she wouldn't have to do that. How much time could be saved by not making people waste an hour of their day walking to labs on the other side of the building?

How about embedded apps? Wouldn't it be simpler to move processing to a server somewhere, and just run a simple X server on the device? It certainly seems more efficient and less expensive than trying to stuff ample hardware onboard each one of them. But, hey, let's ignore that obvious use for X, and claim "no one uses it anymore!"

XF86 _DOES_ have DirectX. We call this "DRI", and if you combine it with SDL, there you go, DirectX for Linux. DRI is a local interface. It has none of the supposed problems X has with regards to performance. Even casual benchmarking of games in Linux and Windows reveals that any impact X has is minimal. There's also nothing preventing you from doing a hardware-accelerated GUI - the architecture is all there.

In other words, I'm calling bullshit on you. Prove yourself. It's easy to talk smack about something you obviously don't understand.

-Erwos

What happened here

[fireboy1919]

When did I say ssh was the best?

Surely, it's not the answer to all the worlds problesm, but ssh has a built in option for X forwarding. It's built in!

Maybe they suck as a vpn solution, but they provide two kinds of public key encryption (the same kinds used by SSL), they come with built in compression, and most importantly, forwarding pretty much just works when you turn it on.

Also, with ssh, the end user doesn't have to worry about the cookie passing process or know what makes up an .Xauthority file. It's all done automatically.

By the way, the information is available to the user, though they don't authenticate on a per socket level - only once for the ssh client. At least, it is if you're using a *nix ssh client - there's a listing of public keys under .ssh, or if you use putty (search through the options).

So I'd say it works pretty well for X forwarding.

As far as VPN, my personal experience (which cannot be argued because it is not fact) is that it's much more flexible than anything else for VPN apps. My work only provides pptp for VPN, and that is incredibly slow, crashes A LOT, and provides no compression. SSH forwarding, on the other hand, is fast, never crashes (thanks to autossh), and compresses everything so much that it seems comparable to actually using the LAN.

If you have the luxury of getting apps that come with SSL, then by all means, use those.

Re:X? X?!?

[ctr2sprt]

I know, don't feed the trolls, but... From X(1):

The X Consortium requests that the following names be used when referring to this software:

• X
• X Window System
• X Version 11
• X Window System, Version 11
• X11

Pay special attention to the first option. IHBT, IHL, but HTH, HAND.

All I want for Christmas...

[tupshin]

is simultaneous support for Xinerama and DRI.

Re:IPV6...pah!

[bazmonkey]

If that's all you need, go play with DirectFB. It's even 3D accelerated if set up correctly, and has GNOME working.

two questions to the networking folks

[Maimun]

disclaimer: I do graph algorithms, not networks... 1. Isn't the networking "layered"? IP is below TCP, right? Then, the applications see only TCP and do not interact with the underlying IP, be it IPv4 or IPv6. How come that X cares about IP(v6)? 2. Several years ago, I was hearing a lot about something called ATM, a revolutionary new protocol, substitute of both TCP/IP and the underlying Ethernet/WAN, that has very sophisticated features like guaranteed bandwidth, etc. Plus, ATM is ... how do they say, connection- oriented, rather than `each packet is routed separately' as IP. So why didn't ATM replace the TCP/IP thing altogether?

Re:two questions to the networking folks

[Anonymous Coward]

1. Not quite, TCP/UDP still need the ip addressing plugged into them to pass on to the layer below. The TCP layer adds things like flow control to the application
2. ATM hardware is expensive, we are using it on our backbone at work but just about to rip it out and install Gigabit ethernet. Also ATM addressing is at the Data Link layer, below the ip layer, so it wouldn't remove the need for IP addressing.

Re:Great!

[Fembot]

Hint: If the problem and solution are so obvious get off your arse and fix it

Re:IPv6 is just a backbone technology

[Jonner]

I couldn't agree more about NAT. NAT is a great technique for getting around restrictions like too few addresses (whether there's a real shortage or whether it's artificial isn't clear), but it is a kludge that I hope will one day be unnecessary.

Re:Great!

[*coughs loudly*]

if(FTGetName(face, nid, TT_PLATFORM_MACINTOSH, FT_MAC_ID_ROMAN, &name)) {
len = name.string_len;
if(len > name_len)
len = name_len;
memcpy(name_return, name.string, name_len);
return len;
}

That's the only place memcpy is called from FTGetEnglishName, and that would seem to be fine. If, on the other hand, srcpp contains the name of a font, and its length is less than name.string_len, that would cause the problem you're seeing; that would be a problem with FreeType, though, and not specific to XFree86.

Re:IPV6...pah!

[Jonner]

Where did you find GNOME running on DirectFB? At least some of Gtk+ is working, but DirectFB is a thin hardware abstraction layer. I haven't seen any evidence it allows multiple processes to safely share the display.

IPv6 not a waste of time, but why 6 bytes ?

[master_p]

This situation reminds me of what happenned to hard disks. After they had a problem with addressing for capacities more than 512 MB, they chose 28 bits for the next sector addressing scheme. Now that they have reached the limit of 128 GB ((128)*512 = 137438953472 bytes), they are going to expand it.

The same situation with using 6 bytes for the network address. Why not go directly to 8 bytes ? someday, and with networking all appliances from refrigerators to watches, the 6 byte addressing scheme might be exhausted. Then we will have IPv8. I don't believe that these 2 bytes will make a difference in speed anyway.

Re:IPv6 not a waste of time, but why 6 bytes ?

[urbi]

Actually, IPv6 addresses have 8 bytes... 6 is just a version number.

Re:IPv6 not a waste of time, but why 6 bytes ?

[Anonymous Coward]

6 bytes? What 6 bytes are you talking about?

The 6 in IPv6 is the version number (part of the IP header), not the number of bytes in an address.

An IPv6 address has 128 bits, i.e. 16 bytes.

Re:IPV6...pah!

[tjansen]

I guess transparency without applications is not enough for him :)

Re:IPV6...pah!

[bazmonkey]

I've never tried it, I just looked and saw screenshots of GNOME, like, the panel and whatnot. If those are just doctored up shots, my bad.

I'd give links if I could, but directfb.org appears to be down right now...

More Important Things...

[miketang16]

I think X should concentrate on making itself a better windowing system, instead of IPv6, which will take 5-10 years to be fully implemented...

slight OT: TightVNC

[whovian]

TightVNC, IMHO, was a bit easier to use with ssh tunnels since all it needs is a command line option (eg, -via localhost). With other VNC projects, it was a two step process: set up tunnel and then run vncviewer pointing to the tunnel.

pardon my ignorance...

[themusicgod1]

...but if my isp does not feature v6 then do i have to wait until they do? thnx

Re:IPV6...pah!

[dinivin]

DirectFB has "fusion" support now (that's what they call it). It allows multiple directfb apps to access the display.

Dinivin

Re:IPV6...pah!

[CaptnMArk]

I've wondered how this works. Because without reliable isolation of one process from another, the thing is useless for me.

Re:IPv6 is just a backbone technology

[Lumpy]

some facts for you....

99.9997% of all computers do not need to be directly on the internet with a real IP address. only servers that are giving out multiple services.. and even then it isnt needed. Behind a firewall and nat box I can have 60 servers all accessable from the net with one ip address without a problem and zero difficulity in setting this up.

the fallacy of "we are running out of IP space rapidly" is a cry I heard cince 1997... funny. if it's so rapid just like the impossibility to get a domain name that was anything but random letters in the .com and .org space was supposedly to happen 3 years ago also...

It's an issue yes... ipv6 has good merits and is needed in about 10 years. it is not desperately needed like many of you think. hell in 10 years I'm betting that it still will not be needed and I will still be able to get a domain name in the .com tld that isnt only line noise like q7uyasdba6mzpula.com

I'm not knocking ipv6.. but I am knocking the prevalent attitude that it's really really needed because address space is so horribly limited is going to be use up completely any second now!

no it's not... and no it's not... calm down and worry about important things like the erosion of your civil liberties or the fact that Guiness prices are going up.

(offtopic)Re:And I was just thinking

[PhilHibbs]

The reply was not related to the comment that it was attached to. When someone tacks their opinion onto the top-rated comment, especially when it's a Funny, they deserved to be oblivioned regardless of the merits of their arguement. When I moderate, I sometimes go through the first two or three screenfuls and prune them down to keep the threads consistent, after all, this is the stuff that the majority of visitors are going to see first.

It's not that hard, dammit!

[elvstone]

I see people in previous posts saying "Why 128 bit addresses, they can't be remembered" and getting answers such as "You are not supposed to remember them, that's why we have DNS". Really, IPv6 addresses aren't that hard to remember. Having used IPv6 for all my machines at home (>10) for about 6 months I have no trouble remembering all their addresses, eventhough I normally use DNS. Get your prefix, put up some machines, and you'll see it's not that hard.

whats the point?

[anythings-possible-b]

i don't get it? why to show your screen on a remote computer?
if i want to publish info i make a webpage or write a program or make "prntscreen" and mail it.
if you only have one screen but lets say six computer, why not make the gui like a cube.
each cube face would represent a computer and the progis running on it.
now click the desktop and move the mouse right, and the desktop.1
would zoom back a bit and turn to the desktop.2 (like taking a dice and turning it 90 deg. around ...
something like that ...). copy-paste/ drag-drop would be a problem though.
would be cool though. computer.1.desktop.1 all the networksecurity related stuff. computer2.desktop.2 all the games.
computer3.desktop.3 programming stuff. computer4.desktop.4 all the p0rn you can imagine. computer5.desktop.5 my web-server with all the docus. computer6.desktop.6. all my nasty ha++ker progis. just a suggestion ...
all six computers ARE MINE! go get your own ...
i've seen in KDE (and other) these 4 buttons that each represent a new desktop. cool!
and: somehow it just sounds fishy if a gui makes use of networkprotocols.
i think some kind of "network"protocol-say-communication in gui/server-whatever is probably necessery,
but to use the same like what you would use for the NETWORK/internet (hence the name NETWORK-protocol)
is just, how to say, silly-funny.
what happens in X when MY maschine has 2048 resolution and the other guy wants to see my screen on a
640 resolution. i don't get it.
so let's be silly. how about sharing a keyboard over the network? X-keyboard.
and: why not make a progi cabable of communicting over the network instead of my gui?
so if your doing something finite-analysis, why not programm the PROGRAM to use the network, instead of the gui?
like say pirch or irc or explore or mozilla, etc..., you can see what i see, right?
i really don't get it ...
-
greetings.

Re:X is a thing of the past

[Realistic_Dragon]

Bulshit to you too, I am running Xine remote forwarded via SSH/X over the network (from a PC with a 250gb hard disk to a PC with a BFO screen) and it's consuming just 2mb/sec of bandwidth (on a 1.6mb/sec encoded file), and the thing is playing back very smoothly indeed.

X forwarding is very simple indeed to set up (just insert a couple of -X switches into SSH/SSHd) - only a complete fool could f^ck it up. You seem to fit the bill nicley.

Re:IPV6...pah!

[fireboy1919]

XDirectFB is an X server. I'm currently using it with Gnome to send this to you. The only requirement is that the apps are capable of communicating with an X server.
It works.

X was designed to be transport-agnostic

[per unit analyzer]

It really doesn't surprise me that X11 will be made to work on IPv6 since X was originally designed to run across a variety of network types. Am I the only one here that remembers that X ran over DECnet? IIRC there may have been an OSI implementation as well...

--zawada

Re:IPV6...pah!

[Jonner]

I am aware of XDirectFB, and I think it's a good idea, but I think the person who first mention DirectFB was talking about using DirectFB instead of X.

I'm using the regular XFree with the Nvidia driver. You're using DirectFB as the video hardware layer. All you've proven is that you can use an X server to display X clients. Great!

This issue in question is the communications layer of X. There are some people who think it would be better to avoid all communication abstraction, limiting GUI apps in the same ways they are on Win32.

Re:IPv6 is just a backbone technology

[Phil Karn]

Thanks, I didn't know that. I wonder if/when OpenH323 will support it, or if it's time to just switch to SIP.

Sounds good!

[fireboy1919]

You know that nothing needs too be reimplemented, right? They are GIVING away their proxy client and server, which is the crux of all they have created. You don't need all the rest.

I'll give it a shot.

Re:HTTP has one way notification

[Tablizer]

HTTP sux when client needs to be notified by server. The connection is one way- client sends requests to server, gets response. In real GUI, communication must go both ways. That means client must also be a server, or that HTTP is not suitable for GUI transportation.

You can do auto-refreshes using the (I forgot HTTP command). IOW, polling. Perhaps not the ideal, but it works for all but subsecond-instant-real-time stuff.