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."
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!
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>
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
The latest X is Version 11 Release 7; shouldn't you call it X11R7? I read the manpage: man X.
M etro-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
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
Oops. This is probably Xfree86 specific and has nothing to do with the official X distribution.
The only thing holding me back on IPv6 was X. Well, that's solved. IPv6 here I come!!!
Well put. I have to admit, I'm one of those who got sucked in by the notion that if it has a higher "v" it must be better. Well, that ended today when I did some research and found out how horribly botched the whole IPv6 thing has been from the start, and at this point, I really think it's a lost cause. It would be better to start over again, on a new sensible extension to IPv4.
For starters, it's essential that the old addressing scheme be a straightforward subset of the new one. You have to be able to connect to google and Aunt Mary's homepage from your spiffy new setup. It would also be awfully darn 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.
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.
As far as taking over the internet goes, it's all over but assigning the blame.
Have you got your LWN subscription yet?
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).
Table-ized A.I.
is simultaneous support for Xinerama and DRI.
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.
> 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?