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."
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?
--
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.
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.
Withdrawal before climax is very ineffective and those who try this are usually called "parents."
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
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.)
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.
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.
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.
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.
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.
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)
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
You can simply run dual stack. No problem in there.
We don't need more than 640 K of memory either.
You haven't actually used IPv6 at all, have you?
This is your sig. There are thousands more, but this one is yours.