Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
X GUI The Internet

X Might Be Ready For IPV6 249

Posted by timothy from the bajillions-and-bajillions dept.
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."
This discussion has been archived. No new comments can be posted.

X Might Be Ready For IPV6 More

X Might Be Ready For IPV6

Comments Filter:

  • And I was just thinking (Score:5, Funny)

    by Anonymous Coward on Tuesday May 06, 2003 @08:01PM (#5897371)
    The only thing holding me back on IPv6 was X. Well, that's solved. IPv6 here I come!!!

  • You are short-sighted (Score:4, Insightful)

    by Rosco P. Coltrane ( 209368 ) on Tuesday May 06, 2003 @08:06PM (#5897404)
    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 ...

    • Perhaps (Score:5, Interesting)

      by fireboy1919 ( 257783 ) <(rustyp) (at) (freeshell.org)> on Tuesday May 06, 2003 @08:14PM (#5897454) Homepage Journal
      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 (Score:4, Interesting)

        by Phil Karn ( 14620 ) <karn@@@ka9q...net> on Tuesday May 06, 2003 @09:00PM (#5897738) Homepage
        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.

        • 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.

      • SSH tunnels, the "nazi analogy" of slashdot (Score:5, Informative)

        by coyote-san ( 38515 ) on Tuesday May 06, 2003 @09:08PM (#5897779)
        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.

        • 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.

      • Re:Perhaps (Score:2, Insightful)

        by evilviper ( 135110 )

        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 t

        • Re:Perhaps (Score:4, Informative)

          by Wumpus ( 9548 ) <IAmWumpus AT gmail DOT com> on Tuesday May 06, 2003 @11:30PM (#5898532)
          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 (Score:3, Informative)

            by ColaMan ( 37550 )
            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)
      • 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 cli
      • 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 m
      • 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.
      • 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 daemo
      • 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.

      • 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 cr

    • Verry wrong. (Score:5, Insightful)

      by Anonymous Coward on Tuesday May 06, 2003 @08:22PM (#5897507)
      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).
      • 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 ex

  • Prediction (Score:3, Funny)

    by Pres. Ronald Reagan ( 659566 ) on Tuesday May 06, 2003 @08:07PM (#5897407)
    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.
    • 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.

  • I think IP v6 is not ready for IP v6 (Score:4, Funny)

    by stonebeat.org ( 562495 ) on Tuesday May 06, 2003 @08:18PM (#5897483) Homepage
    I think IP v6 is not ready for IP v6 :)

  • Higher Priorities (Score:2, Interesting)

    by Bonker ( 243350 )
    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

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Tuesday May 06, 2003 @08:26PM (#5897531)
      Comment removed based on user account deletion

      • Re:Higher Priorities (Score:2, Informative)

        by ahaning ( 108463 )
        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 peo

        • Re:Higher Priorities (Score:5, Insightful)

          by alienw ( 585907 ) <alienw@slashdot.gmail@com> on Tuesday May 06, 2003 @09:21PM (#5897849)
          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 (Score:3, Informative)

            by ahaning ( 108463 )
            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
          • 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

    • Re:Higher Priorities (Score:4, Informative)

      by Anonymous Coward on Tuesday May 06, 2003 @08:36PM (#5897591)
      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.
      • 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 (Score:5, Informative)

      by dbarclay10 ( 70443 ) on Tuesday May 06, 2003 @09:23PM (#5897857)
      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.

    • 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 [kde.org].

      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

    • <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. Pixma

  • Problem... (Score:5, Informative)

    by yehim1 ( 462046 ) on Tuesday May 06, 2003 @08:24PM (#5897517) Journal
    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?

    --

  • cool! (Score:3, Funny)

    by VAXGeek ( 3443 ) on Tuesday May 06, 2003 @08:27PM (#5897540) Homepage
    now one standard no one seems to like can use a standard that no one likes to use!

  • ahem.. (Score:5, Funny)

    by glenkim ( 412499 ) on Tuesday May 06, 2003 @08:28PM (#5897555) Homepage
    This is surely a relief for the masses here that longed for X support for IPV6.



    Yeah, all 3 of them.

  • Comment removed (Score:3, Funny)

    by account_deleted ( 4530225 ) on Tuesday May 06, 2003 @08:34PM (#5897583)
    Comment removed based on user account deletion
  • IPv6 is simply a new addressing convention for web addresses and securty fixes... how does this have anything to do with X? X is the window manager right?

  • X, lameness filter don't like 1 letter subject (Score:5, Insightful)

    by rice_burners_suck ( 243660 ) on Tuesday May 06, 2003 @08:55PM (#5897711)
    This is just a long thought... since I am sure that a lot of people will post anti X sentiment. I think X is second most bashed piece of software in the world. (The first is Windows.) And I think the bashing is not deserved.

    The X protocol incurs some overhead. Nowadays, most users want a single, consistent user interface. And there are plenty of other arguments. But when it comes down to it, X is a really innovative piece of software design. Consider this: Back in the day, it wasn't an Intel world. There were so many different types of computers that every single action you could perform had a high cost. But combined with the other powers of Unix, X makes possible an environment where you can access applications on any number of different computers on a single desktop.

    Oh, you don't need these wonderful capabilities on your desktop, I can almost hear you say. But I have seen these benefits at work in many places. A very large aerospace manufacturing company, to which I had the privilege of going on several occasions, uses four different high end CAD systems. Each starts at just 20 grand, USD that is. And each was running on its own server, as these pieces of software are real resource hogs. The engineers were using Windows NT on their desktop, where they ran some low end CAD systems, which they used for printing and other boring tasks like that. But their awesome applications were running somewhere else in the building and were being displayed in an X server on Windows.

    I can think of many other examples where something like this would be very valuable. Configuring the Linux kernel "from Windows" by running it on a Linux box and viewing the configuration program on a Windows box is one of them. Another is the ability to keep all of your company's personnel on Windows, which they recognize, but running all of your critical things on Unix of one sort or another. Heck, keep a couple of reserve Windows boxes in storage, configured and ready to go. When someone hoses their desktop, you've got it back up and running with a reserve box in the time it takes to unplug five cables and plug them into another box. Then, reinstall the hosed system. The possibilities are endless and your users don't even need to know.

    So let's talk about those arguments I mentioned in the beginning... Overhead? With multigigahertz processors and so much RAM that you could park grampa's Buick there, who gives a hoot? Besides, who said that a "light" X can't be built for people who don't need the multicomputer capabilities? It could be a compile option if someone desired it badly enough. Want a consistent user interface? Use skins on the widget sets that support them and modify the ones that don't to use controls that look the same. Even if you don't do this, nobody will notice, or care, that the button in this application looks a little different than the button in that application. Most people are computer literate enough to just click on it and figure it out on their own. Heck, if my mom can use a computer, anybody can.

    I agree with many people that X is definitely not perfect. But heck, it is good enough, reliable enough, and flexible enough to be extremely useful and provide real benefits in many ways, and that makes it good enough for me. Besides, it gets better every day... Heck, Windows can't do much of this stuff. Sure, there is PC Anywhere, but that is slow and choppy. And some feature that Microsoft implemented in XP does something similar but only between Windows boxes, as I understand, and not as cleanly and conveniently as X. Bash all you want, X makes life easier for many tasks. (Yes, that previous sentence has a double meaning for folks, like me, who like the CLI. I like the best of both worlds, though.)

    • Yeah, a post about X is offtopic in a discussion about X. Taco, your moderation system sucks.

      Those who want to get rid of X seem to want to start over from scratch -- if you ditch X, then you also ditch virtually every graphical program written for Unix and Linux. And you make life impossible for those of use who use it remotely on a regular basis. (Despite the multitude of people who claim that people don't use the network capabilities, that's only true of home desktop users. Every time I see X used i
      • My understanding is that XFree86 and some other X servers, with matching X libraries, forgo socket connections to localhost and use shared memory. I may have been lied to. In any case, it would be a pretty simple and non-invasive code change. Quake II frame rates between Linux and Win2k on the same box don't show much difference, IIRC (assuming you're using an accelerated X server).

        Maybe X should use a more efficient binary representation of the datastream, but the client-server model is great. WinVNC

        • WinVNC (and Windows Terminal Services, I believe) do not allow multiple users to be logged in with remote GUIs simultaneously.

          VNC doesn't allow multiple sessions at once (other than sharing the single remote desktop), but that's kind of the whole point behind Terminal Services - multiple people can be logged on to the server at the same time, and they each get their own private desktop.
    • X is a piece of genius. A flat out piece of genius. I never cease to be amazed at how durable it has been given the orders of magnitude changes that have taken place within the realm in which it's problem domain(s) lies.

      I recall seeing a video presentation back in about 1989 (IIRC correctly recorded much earlier) by one of the designers of X11, and it just reinforced what I felt at the time and what I have come to see in the last 15 years or so. That X is a piece of genius.

  • X Rules (Score:5, Funny)

    by Anonymous Coward on Tuesday May 06, 2003 @09:12PM (#5897805)
    It might not detect any of my mouse buttons, but it sure as hell can address 2^128 nodes!

  • Need GUI's over HTTP (Score:2, Interesting)

    by Tablizer ( 95088 )
    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 [geocities.com], 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 cli
    • 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

  • More IPv6 Support, Please (Score:4, Insightful)

    by serial frame ( 236591 ) on Tuesday May 06, 2003 @09:52PM (#5898034)
    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 :)

  • 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.

  • X and IPV6 (Score:3, Informative)

    by Anonymous Coward on Tuesday May 06, 2003 @10:51PM (#5898387)
    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
  • is simultaneous support for Xinerama and DRI.

  • 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...
  • 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

Slashdot Top Deals

Every cloud has a silver lining; you should have sold it, and bought titanium.

Close