Slashdot Mirror
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."
The only thing holding me back on IPv6 was X. Well, that's solved. IPv6 here I come!!!
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 ...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
Abortion is advocated only by persons who have themselves been born.
--Ronald Reagan
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).
Mod me down and I will become more powerful than you can possibly imagine!
I think IP v6 is not ready for IP v6 :)
Consensus is good, but informed dictatorship is better
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).
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.
:1, etc) with the IPv6 address, since both IPv6 and the screen number uses the colon (:) separator.
:1 would be
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,
Thus, the traditional way of denoting 2003:1080:1111:4034:1212:3fdb:1123:0001 with screen
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?
--
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.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
now one standard no one seems to like can use a standard that no one likes to use!
this sig limit is too small to put anything good h
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.
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.
Let's make a difference
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.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
It might not detect any of my mouse buttons, but it sure as hell can address 2^128 nodes!
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.
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.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
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 :)
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
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.
Withdrawal before climax is very ineffective and those who try this are usually called "parents."
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.
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
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
Plausible conjecture should not be misrepresented as proof positive.