Oh wow, hairyfeet is now running an anti-Firefox campaign.
HEY, EVERYONE -- this is the same hairyfeet that usually pretends to run some kind of computer business while parroting anti-Linux marketing for Microsoft.
As you've mentioned X11 itself and X11 applications don't handle latency well and so using network transparency over a WAN has been less than pleasant.
I said no such thing. Current X11 implementation doesn't work well on high-latency connections -- this is usually not a requirement in the first place (they work great over gigabit LAN), and it can be fixed without breaking X.
Network transparency is not a requirement per application, it's a requirement per use case. If ANY application that user has to use remotely is not usable over the network, then ALL of them are unusable over the network, and the user is forced to use "remote desktop" to run all of them in a pseudo-desktop window.
My whole point is that we should not allow development of applications with sabotaged network transparency. The author won't notice if he used a new whiz-bang toolkit and his application is now "local only", but the user will, and I do not want to be faced with applications built with this kind of sabotaged libraries in toolkits in my work, just because someone used a nice-looking library while being unaware how it hurts users.
...US press would be frothing at the mouth of how US military technology is superior to "rusting and unsecured arsenal of the fallen superpower", and simultaneously how it's a part of some kind of genocide campaign.
Except the whole point Wayland developers are claiming is to avoid supporting X in any form, relegating it to a ghetto of "compatibility mode" that new application won't use. That makes Wayland applications non-network-transparent except through crude kludges that have nothing to do with X, don't work with window management, and lack other features that X currenly supports. I don't think, they would even think of implementing X window management for Wayland applications, so window management would be fundamentally broken.
So if they don't re-invent not only the wheel, but the drive shaft as well, you won't be satisfied?
It doesn't really matter how they implement it as long as it works. There are good engineering practices. This feature-stripping and breaking existing use models isn't one of them.
Wait, so you missed the part where they're working to run X within Wayland so that you can still run your X applications if you'd like and still be able to use your X11 forwarding if you so pleased?
I don't care about X applications per se. I care about making it impossible to produce an application that will not work remotely. With X11 I have this -- anything that works locally will also work across the network as long as latency is reasonable for its use. With "oh, we will support X11 because we heard, someone wrote X11 server in Java, so just use that", I won't.
That being said though, I can hardly read your last few sentences as anything but exaggerated nonsense. Wayland, at the very least, has had a system for tracking surface damage for a while now.
And without having this accessible over the network, network transparency goes to Hell.
The notion that the compositor will require a complete surface copy for some arbitrary reason that you didn't specify is rubbish.
VNC operates in terms of the root window, and thus is completely unusable for this purpose. If Wayland developers designed their own remote protocol (even if it was primarily bitmap-based) and window manager interface, it would at least make their efforts somehow legitimate -- maybe even add support for X on top of this for compatibility. But now it's "we will draw pretty pictures, dirty people who need remote applications should use VNC!" -- that's completely unacceptable.
Additionally, in a remote access context, insinuating that a compete screen copy would be required each time something has changed (for whatever arbitrary reason you also didn't specify) is also rubbish, especially since you already have every client notifying you of surface damage.
I said no such thing.
Step back for a second, Wayland is a *protocol* and Weston is a work in progress for crying out loud.
it's not a protocol if you can't use it across the network. And even if it was, there would be still no reason to use it if it is not at least as efficient as X when used for such purpose. There is absolutely no reason for making a WORSE system.
The fact that you're trying to draw a conclusion at all at this point is ridiculous. Heck, input is still being pulled in raw from evdev devices isn't it?
You are ignorant. X uses input drivers and its own event system. There wasn't even evdev subsystem for most of the time X existed (and there still isn't on systems other than Linux).
Except the company had no intent to file a lawsuit, so there wouldn't be a discovery phase, they would just send you a bill with "settlement offer" with no recourse other than suing them.
If X works "just fine" why does it run worse than loading a window through VNC?
Because you have very high latency, and X protocol is not optimized for that, what is fixable. On the other hand, VNC does not let the user to combine remote and local applications on one desktop with full window manager, and this is pretty much unfixable without a serious redesign.
Because I used it for five years to run VariCAD on a server with no local video acceleration, displaying on client with Nvidia card, both running Debian.
That feature is not a requirement for the GUI in my car or boat.
Oh yes, it is. Automotive companies are working on switching from CAN to Ethernet (with realtime extensions), so there is no good reason to prevent people from implementing remote user interface.
If their implementation was compliant with X standard, it would be possible to just re-use any X window manager. And yes, that would require Wayland window to be manageable from X -- otherwise it's a shit implementation similar to "We formally support POSIX, give us government contracts!" in Windows NT.
Same as how X11 is "implemented" on Android. It's absolutely useless.
I have my Nokia N900 running X11-based Maemo for years -- with compositing, remote X, phone-friendly window management of remote and local applications, etc.
GTK and Qt don't and never will have any network transparency on their own -- they use X for this purpose, and it works JUST FINE. If any project will replace X, it will also have to replicate network transparency provided by it, and no, "let's copy bitmaps of a virtual screen" won't cut it, applications must obey window management on the user's box, and should not produce more network traffic than notoriously "chatty" X.
You are an idiot. "Seamless blending" is the part that works "perfectly" in X already. The problem is with configurations that treat multiple monitors as separate screens, or combine incompatible hardware each with its own proprietary drivers. X users simply have higher demands and longer history of sophisticated multi-monitor suppport than Windows users.
Slashdot Mirror
There is always World Trade Center to treat in a similar manner a century later.
I would imagine the backlash would kill both the ISP and that certificate authority.
No, because fraud charges against everyone involved will do it long before that.
if you're connecting to an unsecured network, I doubt security is much of a priority.
Congratulations, you are an idiot!
The whole point of encryption is that it allows secure communications over insecure network.
Oh wow, hairyfeet is now running an anti-Firefox campaign.
HEY, EVERYONE -- this is the same hairyfeet that usually pretends to run some kind of computer business while parroting anti-Linux marketing for Microsoft.
As you've mentioned X11 itself and X11 applications don't handle latency well and so using network transparency over a WAN has been less than pleasant.
I said no such thing. Current X11 implementation doesn't work well on high-latency connections -- this is usually not a requirement in the first place (they work great over gigabit LAN), and it can be fixed without breaking X.
Network transparency is not a requirement per application, it's a requirement per use case. If ANY application that user has to use remotely is not usable over the network, then ALL of them are unusable over the network, and the user is forced to use "remote desktop" to run all of them in a pseudo-desktop window.
My whole point is that we should not allow development of applications with sabotaged network transparency. The author won't notice if he used a new whiz-bang toolkit and his application is now "local only", but the user will, and I do not want to be faced with applications built with this kind of sabotaged libraries in toolkits in my work, just because someone used a nice-looking library while being unaware how it hurts users.
...US press would be frothing at the mouth of how US military technology is superior to "rusting and unsecured arsenal of the fallen superpower", and simultaneously how it's a part of some kind of genocide campaign.
Except the whole point Wayland developers are claiming is to avoid supporting X in any form, relegating it to a ghetto of "compatibility mode" that new application won't use. That makes Wayland applications non-network-transparent except through crude kludges that have nothing to do with X, don't work with window management, and lack other features that X currenly supports. I don't think, they would even think of implementing X window management for Wayland applications, so window management would be fundamentally broken.
So if they don't re-invent not only the wheel, but the drive shaft as well, you won't be satisfied?
It doesn't really matter how they implement it as long as it works. There are good engineering practices. This feature-stripping and breaking existing use models isn't one of them.
Wait, so you missed the part where they're working to run X within Wayland so that you can still run your X applications if you'd like and still be able to use your X11 forwarding if you so pleased?
I don't care about X applications per se. I care about making it impossible to produce an application that will not work remotely. With X11 I have this -- anything that works locally will also work across the network as long as latency is reasonable for its use. With "oh, we will support X11 because we heard, someone wrote X11 server in Java, so just use that", I won't.
That being said though, I can hardly read your last few sentences as anything but exaggerated nonsense. Wayland, at the very least, has had a system for tracking surface damage for a while now.
And without having this accessible over the network, network transparency goes to Hell.
The notion that the compositor will require a complete surface copy for some arbitrary reason that you didn't specify is rubbish.
VNC operates in terms of the root window, and thus is completely unusable for this purpose. If Wayland developers designed their own remote protocol (even if it was primarily bitmap-based) and window manager interface, it would at least make their efforts somehow legitimate -- maybe even add support for X on top of this for compatibility. But now it's "we will draw pretty pictures, dirty people who need remote applications should use VNC!" -- that's completely unacceptable.
Additionally, in a remote access context, insinuating that a compete screen copy would be required each time something has changed (for whatever arbitrary reason you also didn't specify) is also rubbish, especially since you already have every client notifying you of surface damage.
I said no such thing.
Step back for a second, Wayland is a *protocol* and Weston is a work in progress for crying out loud.
it's not a protocol if you can't use it across the network. And even if it was, there would be still no reason to use it if it is not at least as efficient as X when used for such purpose. There is absolutely no reason for making a WORSE system.
The fact that you're trying to draw a conclusion at all at this point is ridiculous. Heck, input is still being pulled in raw from evdev devices isn't it?
You are ignorant. X uses input drivers and its own event system. There wasn't even evdev subsystem for most of the time X existed (and there still isn't on systems other than Linux).
This all can be done by extending X without breaking it.
Except the company had no intent to file a lawsuit, so there wouldn't be a discovery phase, they would just send you a bill with "settlement offer" with no recourse other than suing them.
There are people that are not Americans. Me, for example.
He learned something when he took office. Something scary.
And false.
Yes, and mplayer offers two solutions to display video on VT100.
If X works "just fine" why does it run worse than loading a window through VNC?
Because you have very high latency, and X protocol is not optimized for that, what is fixable. On the other hand, VNC does not let the user to combine remote and local applications on one desktop with full window manager, and this is pretty much unfixable without a serious redesign.
Because I used it for five years to run VariCAD on a server with no local video acceleration, displaying on client with Nvidia card, both running Debian.
No. 3D local to application is VirtualGL, and it works JUST FINE.
Windows using Xming without a problem
lol
That feature is not a requirement for the GUI in my car or boat.
Oh yes, it is. Automotive companies are working on switching from CAN to Ethernet (with realtime extensions), so there is no good reason to prevent people from implementing remote user interface.
If their implementation was compliant with X standard, it would be possible to just re-use any X window manager. And yes, that would require Wayland window to be manageable from X -- otherwise it's a shit implementation similar to "We formally support POSIX, give us government contracts!" in Windows NT.
Same as how X11 is "implemented" on Android. It's absolutely useless.
I have my Nokia N900 running X11-based Maemo for years -- with compositing, remote X, phone-friendly window management of remote and local applications, etc.
GTK and Qt don't and never will have any network transparency on their own -- they use X for this purpose, and it works JUST FINE. If any project will replace X, it will also have to replicate network transparency provided by it, and no, "let's copy bitmaps of a virtual screen" won't cut it, applications must obey window management on the user's box, and should not produce more network traffic than notoriously "chatty" X.
You are an idiot.
"Seamless blending" is the part that works "perfectly" in X already. The problem is with configurations that treat multiple monitors as separate screens, or combine incompatible hardware each with its own proprietary drivers. X users simply have higher demands and longer history of sophisticated multi-monitor suppport than Windows users.
Don't copy-paste other posts, especially ones that are completely wrong.