Well, the guy (one Serge Humpich) certainly got a lot of media coverage. Some people say he rubbed people the wrong way
And companies that cut costs and win billion dollar contracts through shoddy engineering and threaten your livelihood, safety, or financial health as a consequence don't rub you the wrong way?
Yes, it's a practical fact that one has to be nice and diplomatic in such matters. But the companies and executives that get away with putting out such products are criminals and should be locked up.
The problem is that uploading the information to usenet is exactly what's going to happen. Corporate-types don't read usenet, but hacker-types do. What does that lead to? Some bored kid stealing all of my money, and only THEN is there a reaction from the company.
Unfortunately, that's how people finally recognize that a problem is actually a problem: when people get hurt or start losing money.
Not only can it be used to charge money out of our debit account (called Big Red Bucks), but it can be used to charge however much you want to your parents' bursar bill.
Well, that's no different from other debit cards. You can always try to refuse to pay.
Also, education is a free market and you do have a choice in what university you attend. My impression is that Cornell is somewhat more corporate-friendly than other universities, so this sort of thing seems in character. You can always transfer...
Re:time to tax artists, typists and other humans t
on
DMCA, Auf Deutsch
·
· Score: 1
3) All these residential users should be using their ISP as a relay. That's what the ISP is there for.
Says who? Traditionally, most hosts on the Internet were able to send and receive mail. ISP-based E-mail servers were a workaround for dial-up based networking. Now that we are getting back to having most hosts having always-on connectivity, I don't see why we should keep using ISP-based E-mail servers.
The fact is, SMTP is based on the flawed assumptions that every e-mail sent is one that the recipient wants to see because nobody would ever spam, and that there's no harm in letting the message travel unencrypted because nobody would ever snoop.
There was nothing flawed about those assumptions until the Internet got opened up to the unwashed masses. You can't blame the SMTP designers for not designing a protocol that takes into account AOL, Earthlink, and the Ugandan spam of the week.
It's time for reform in the overall e-mail system, the only problem is that there's a huge installed user base that'd be forced to upgrade in order for a new e-mail protocol to work. It's gonna take something silly like this to get out of hand for that to happen.
It's not clear to me what you want a new E-mail protocol to do that currently existing approaches don't already do. I mean, you can encrypt mail, you can get return receipts, you can validate senders via a "respond to this" message, or you can use web-based contact forms.
So, tell us, what do you actually want a new protocol to do?
Actually, you can. IBM had a pretty complete Windows clone, and there are several partial open source clones. The problem was the same as with Java: as long as Windows and Java are controlled by big companies with their own agendas, it makes no difference whether anybody succeeds at cloning them--by the time they are done, the platform has already shifted under them.
Actually, every other single device driver lives in kernel space
Many device drivers don't live in kernel space anymore--only some core functionality that moves bits back and forth.
so why not the one for what is arguably the highest performance device of all: the screen?
The reason to put stuff into the kernel is not for performance but for access control and interrupt latency. In terms of performance, a well-designed interface will not have significantly more overhead when it lives in user space. And X11 has been optimized for that case for about 20 years. Of course, badly designed interfaces work a little faster when they are move into the kernel, but that doesn't apply here.
So, in short, X11 isn't in the kernel because it wouldn't make much difference.
secondly many groups have take the spec and produced high-quality implementations of some or all of it that range from free to low cost to high cost.
Partial implementations are completely useless: the Java standard is what Sun defines to be in the Java2 platform; anything else is not Java.
Now, forget about all the other stuff, just show me a non-Sun implementation of Swing. The fact is that every single implementation of the J2SE and J2EE platform depends on licensed code from Sun.
In fact I would say that Java2 is the most successful cross platforms GUI framework I have ever worked with.
It is pretty much impossible to write a high-quality cross-platform application in Java, if not for any other reason because Sun's cross-platform toolkit fails to support platform-specific functionality, in some sort of completely confused understanding of what a "cross platform toolkit" is.
If you have real examples of why it does not work then lets here them.
Just check the bug parade. Perennial problems are broken window management, differences in the semantics of transparency, flaky drag-and-drop support, and differences in the meaning of line width, to name just a few.
Of course, more fundamental than plain bugs is the decision of Sun not to support any platform dependent features: no environment variables, little or no desktop integration, etc. A high-quality cross-platform toolkit must support platform-specific functionality, otherwise it's impossible to write good applications in it.
Microsoft is greedy and controlling, but so is Sun. The best thing for open source and customers is to avoid getting involved with either of them.
this effort, unlike Microsoft's, represents a "cross-platform commitment and open, standard J2EE technology."
J2EE is no more open than Microsoft Windows: Sun has patents on many aspects of the system and all the usable implementations are derived from Sun source code (including IBM's). Furthermore, the Java2 GUI implementation has serious problems on non-Windows platforms making J2EE not even a good cross-platform choice for client apps.
A web-based office suite written in Java made sense a few years ago, when Sun was still on track for making Java an open platform that worked well across platforms. These days, it's a curiosity running on a proprietary platform that has significance only on the server.
Sun Java and Swing come preinstalled with many PCs, SWT doesn't. SWT hasn't even been broken out into a separate distribution from the Eclipse IDE. And Swing is secure enough to be run by untrusted applications, SWT is not.
SWT could be a big deal for the Java community. God knows, Java needs something that's better than Swing. But at this point, it's just a curiosity.
The only bottleneck is re-allocating the window buffer (OSX buffers all window contents on the graphics card), event delivery latency is negligible and 2D drawing is mostly negligle... On a fast Mac you can resize windows *almost* as fast as the monitor refresh, and it looks incredibly smooth because the entire window is always double-buffered. It *never* flickers.
All of that is fine, but it's more policy decision than technology. If you like, you can tell X11 to buffer everything on the graphics card as well. Also, you can double buffer every window and tie redraws to vertical refreshes. Yes, that does look incredibly smooth. It also eats up a lot of resources, and X11 historically has not chosen those defaults. Perhaps desktop toolkits and desktop installations should do that now, but that's not a technical issue with X11.
event delivery latency is negligible
No, it isn't. It is negligible only "most of the time", which also the case on X11 and Windows. But when an OS X machine starts paging or gets slowed down in some other way, latency rises and OS X actually degrades less gracefully than X11.
Altogether, Apple hasn't found the holy grail, they have just picked some defaults that look really nice for desktops. Style is something X11 definitely should copy from Macintosh. But for the technology, I'll stick with X11.
Latency in dragging windows can be handled by a call that attaches a window to the cursor so it is dragged around until the mouse is released.
We are not talking about opaque moves--current windowing systems, including X11, handle those just fine by bit-blitting.
I can't think of any good equivalent solutions for resizing,
That is because there isn't any. In the simplest case, which you are thinking about, the user decides how big the window is going to be, by using the mouse. The GUI communicates the new size to the application, the application sends back the updated appearance of the window. One round trip.
I think it should be left up to the program and there will be latency. However as the program can say "resize the window to this" and immediately follow it asynchronously with the new image for the resized window, there will be much less latency than the current version where the window is resized by the window manager and there has to be at least a round trip to the program to get the new drawing.
That doesn't help. The user determines how big the window is going to be and the window has to follow. The application can't just pick a size preemptively and send out redrawing commands for that--if you can see the latency now during redraws, you would see the latency then because the window size wouldn't follow your mouse.
Furthermore, it's a fundamental policy decision under X11 that applications don't get to say "resize to this". That has less to do with usability, and more with being able to use the same programs on a very wide variety of displays: programs simply don't know about all the possible displays and environments to be able to do window management correctly. Putting window management into clients is fundamentally broken, and it would be a huge step backwards for X11 to do that without helping with anything (in fact, I pretty much guarantee it's not going to happen).
Of course, you are free to try this under X11: if you like, your toolkit can resize its own window. You are even free to override the window manager altogether. So, the functionality is already all there, but thankfully, no major toolkit uses it. Just don't expect people to use your application a whole lot if you do that. The few applications that try this (xmms, etc.) are a big pain to use on displays that don't satisfy the assumptions that their author had in mind.
The drawing code definately should support display lists, though I don't think much of the complex structure is needed, because *some* communication is acceptable. A program that draws a hundred buttons of different sizes should be able to send a display list that can draw a button once (keeping it in the server much like an X pixmap) and then send on redraw it just has to send the rectangles and labels of all the buttons and the command to run the display list on each of them.
Well, as I was saying, X11 is getting support for that. That's nice for all sorts of reasons, but it will not solve the problem in general because once you have a round trip, you have latency, even if you only send a little data. What it will do is let the server generate a resized image that's pretty close for normal mouse movements, until the application gets around to redrawing things. It will give the illusion of smooth opaque resizing.
But, then, the server could probably already do that with bitmaps: you resize the window and the server does smooth bitmap scaling to fill in until the update comes from the client. For the 200ms that's going to be on the screen, it's going to look just fine.
But let's keep our perspective here: GUI toolkits are not written for letting animated widgets dance around the screen in real time, they are optimized for mostly static displays. That's a deliberate design tradeoff, and one that meets day-to-day needs well. The only place where that kind of animation occurs during normal usage is with opaque resizing. I don't think it's worth putting a lo
Compare how unresopnsive Mozilla is to Dillo (however, Dillo still flickers--another thing that can be avoided by a reasonably written toolkit).
BTW, not to blow this out of proportion--Mozilla is a bit jerky on resizing under X11, but it still keeps up. Furthermore, Mozilla and IE on Windows are about as jerky as Mozilla on X11 (both 1GHz machines with comparable nVidia cards).
Also, examining redraw behavior in Mozilla and Galeon, they seem to be making some progress: it's not a lot faster (yet?), but recent versions behave better over high-latency links.
Ever tried developing for X? It's a huge, towering bitch that looks like an inside-out Jabba The Hutt.
I have written lots of code for X, and it's really easy--using the right toolkit. Both X servers and clients can be really lightweight and low footprint, and they need not be complex at all.
Perhaps you are confusing X with Xlib and XFree86. XFree86 is a huge, and hugely complex, X server implementation. And Xlib is a 20 year old C language binding. Given their age and scope, they have held up well, but they are showing their age. Fortunately, you have plenty of alternatives, and all those alternatives interoperate because "X" is a protocol, not an API or an implementation.
The solution is to put the window manager into the toolkits like the buttons and everything else is.
That doesn't eliminate the latency. Instead, it will just lead to the same behavior we get on Windows, where busted applications not only fail to redraw themselves properly but also do bad things to the entire desktop. It also makes applications unusable over high-latency links.
it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes)
Under X11, applications have to live with the window size they get. That is absolutely essential; trying to put "complex restrictions" on window size would be a disaster. It is exactly those kinds of design decisions that make Windows so much worse than X11.
I suspect this is a combination of excessively complex toolkit programming and perhaps some basic failures of X such as an inability to deliver or respond to expose events quickly enough.
Pretty much all the visual artifacts you get on opaque resizing on X11 for local applications are due to poor toolkit or application code. Mozilla, for example, is absolutely awful, and so are many KDE applications. Compare how unresopnsive Mozilla is to Dillo (however, Dillo still flickers--another thing that can be avoided by a reasonably written toolkit).
Having said that, however, all major window systems are client/server systems, and for good reasons. No matter how you slice it, there is the possibility of arbitrary latencies in such systems, even for applications running locally. Applications and toolkits should be written to deal reasonably with latency, but most aren't.
The only way to avoid problems with latency is to put actual code server-side. None of the major attempts at that have succeeded, and I think for good reason. A modest compromise is to put structured graphics server-side; Apple has already done that in OS X and X11 is getting server-side structured graphics as part of XRENDER.
So, in practice, a well-written X11 toolkit can easily get good opaque resizing for local applications running on an unloaded machine. And if the machine is loaded or if the application is running remotely, nothing will make opaque resizing look good in general.
Could someone please direct me to a resource that shows me how to reconfigure my XFree86 to get it on par with XP. Currently my window drawing/resizing sucks. As for drivers, i am running NVidia drivers on a TNT2.
I believe TNT2 drivers for XFree86 should be OK; make sure you are actually using the accelerated versions and not the generic drivers.
Now, window drawing and resizing behavior depends on the applications you use. Unfortunately, many common toolkits/environments, including KDE and Mozilla, have serious problems in that department: their redrawing logic is just completely broken: not only is it slow, it's actually not even correct. You can see that X11 is perfectly capable of handling that kind of redrawing by running Dillo and resizing it: it's very responsive (and even Dillo's redrawing logic isn't all that good--for example, it could the bit of flickering it has easily).
The solution? Don't use applications that behave poorly, or complain to the application/GUI/toolkit authors. This is not a problem with X11.
I'm sorry but I don't get your point. Keith's paper is about X network performance. When you use X11 locally, it doesn't go over a network. It doesn't even go through the TCP/IP stack. Instead, it goes through a UNIX-domain socket and shared memory. The whole reason why X11 uses bandwidth fairly inefficiently is because its designers have always considered local usage and usage over a fast network to be of paramount importance: compressing the protocol more would have required more CPU overhead, and hence less efficient local performance.
What Keith is talking about in that paper is very useful, but most of it is not about speeding up local uses of X11. And the things that do apply to local uses of X11 also pretty much apply to XP and Macintosh, because those also use a client/server architecture, just like X11.
Just get the case and mobo from CaseOutlet.com, get your favorite drive and WIFI card, install any standard Linux distro, and you are done. And you get a lot more flexibility on hardware (e.g., an 802.11a card).
Such a setup is nice mostly because it keeps noisy disk drives out of your living room and doesn't require cabling.
However, last I checked, porn was still legal in the US, so there is no reason to hide it. However, if you keep illegal pornography (violating copyright or child pornography laws), just get rid of it--one might argue that US laws are paranoid and silly, but that's an argument to be made in the legislatures, not from behind bars. The FBI may not be at the forefront of technology, but they aren't completely stupid either, and they probably have seen it all before.
Most commercial fruit juices contain enormous amounts of added sugar, and they lack the fiber that causes the sugar in regular fruits to be released slowly. That makes many fruit juices almost ss bad as soft drinks.
Drink water and snack on solid fruit (or raw vegetables) and you should be fine. Another rule of thumb is: avoid all packaged or commercial foods--anything with a label, wrapper, box, or bottle is probably fattening.
Most people probably don't even have to count calories. Just eliminate sugar-containing soft drinks (and, to avoid temptation, their "low-cal" counterparts). And snacking on raw fruits and vegetables will fill you up without a lot of calories, both giving you some relief from feeling hungry and making you eat less at your next meal.
1. Performance. There needs to be some serious performance boosting. Rip out a whole lot of fluff. Honestly, how often do you need remote xwindows? Yes, there is a use for it, but that should be a seperate build altogether.
There is no "fluff" there. X11 runs as a separate user-mode process from applications. That means that commands to it need to go from the user process to the display process. X11 uses an asynchronous protocol and a mixture of shared memory and UNIX-domain sockets. And for games and other applications, there is DRI.
It happens to be the case that the X11 protocol and semantics are well-enough defined that the same protocol works over fast networks, but you don't pay anything for that.
Macintosh (as far a I can tell) works the same way: a display server, user mode applicatins, and some IPC mechanism connecting them. The only reason remote display for the Mac doesn't work like X11 is because it lacks some high-level primitives.
Windows used to start out as a frame buffer library, but it, too, works pretty much like X11 these days: asynchronous communications between user-mode processes and a display server running in a separate address space. The only thing NT/XP do differently is that the display server runs i the kernel. You could put an X11 server in the kernel, but it probably wouldn't make a big difference in performance (and it would be a headache).
When a particular X11 implementatin is slow, it's usually because of bad drivers or bad configuration. With comparable drivers, X11 performance is top-notch--usually better than Macintosh and comparable to Windows. And many X11 applications are slow or inefficient because their developers assumed they were programming a frame buffer--an assumption that is wrong on all major GUI platforms these days.
In short, this "X is slow because of network transparency" is wrong in multiple ways. First, X11 is not slow compared to other popular windowing systems. Second, nobody has ever been able to describe a way in which X11 could be made faster by choosing a different IPC mechanism. People who criticize X11 for using IPC usually assume incorrectly that other systems don't use IPC, but they do.
2. Standardization. Flexibility is nice, but having every damn program do things differently is annoying. It's also a very bad thing if you are trying to break into the mainstream.
X11 is standardized. What is not standardized is GUI environments and toolkits. But there is a reason for that: people are still figuring it out. It's software evolution in action. And it's not like Windows or Macintosh have figured that one out either: on Windows, people use dozens of different toolkits, several of which come from Microsoft Similarly for Macintosh. Gnome and KDE are making an effort to interoperate, and that's all you can ask for.
Also, there are plenty of programs that need to "o things differently". X11 is not just a desktop window system, it's used for scientific and engineering applications, customer terminals, ATMs, banking workstations, embedded systems, and lots of other applications. Those environments should not look like a regular desktop.
3. Easier configuration. It can be a real bitch to get xwindows running properly. Considering the huge amount of differing hardware in the wild, I'm not so sure it would be possible to simplify it too much. Oh, well.
I think people are doing as well as they can, given limited information from manufacturers.
But because X11 is standardized, you can always buy a commercially supported X11 server. Those usually run very well on the latest hardware. If you are using XFree86, you are using something that's both free and experimental.
As far as I can tell, "the split" is over none of these issues. Both branches will remain network transparent window systems, they will remain compatible, and they will continue not to force toolkits or desktop software on users. If they tried to, they would cease being X11 implementations. What Keith probably will do is accelerate bug fixing and bringing extensions into the X11 server. And that's what really matters.
The traditional way of quarantining people is to lock them up somewhere. Frankly, I'd prefer a wrist band and staying at home any day.
And if you think that this is Singapore-only, think again. Every nation, including the US, has public health regulations in place to quarantine people when there is a medical emergency.
You didn't use to be able to get a laser printer for under $1000. If you pay that kind of money for a laser printer today, chances are that you will get a quality product as well. If you buy a $300 special, on the other hand, the PostScript interpreter will run on your PC and the thing will likely fall apart quickly.
Slashdot Mirror
And companies that cut costs and win billion dollar contracts through shoddy engineering and threaten your livelihood, safety, or financial health as a consequence don't rub you the wrong way?
Yes, it's a practical fact that one has to be nice and diplomatic in such matters. But the companies and executives that get away with putting out such products are criminals and should be locked up.
Unfortunately, that's how people finally recognize that a problem is actually a problem: when people get hurt or start losing money.
Not only can it be used to charge money out of our debit account (called Big Red Bucks), but it can be used to charge however much you want to your parents' bursar bill.
Well, that's no different from other debit cards. You can always try to refuse to pay.
Also, education is a free market and you do have a choice in what university you attend. My impression is that Cornell is somewhat more corporate-friendly than other universities, so this sort of thing seems in character. You can always transfer...
I guess that means it's permanent...
Says who? Traditionally, most hosts on the Internet were able to send and receive mail. ISP-based E-mail servers were a workaround for dial-up based networking. Now that we are getting back to having most hosts having always-on connectivity, I don't see why we should keep using ISP-based E-mail servers.
There was nothing flawed about those assumptions until the Internet got opened up to the unwashed masses. You can't blame the SMTP designers for not designing a protocol that takes into account AOL, Earthlink, and the Ugandan spam of the week.
It's time for reform in the overall e-mail system, the only problem is that there's a huge installed user base that'd be forced to upgrade in order for a new e-mail protocol to work. It's gonna take something silly like this to get out of hand for that to happen.
It's not clear to me what you want a new E-mail protocol to do that currently existing approaches don't already do. I mean, you can encrypt mail, you can get return receipts, you can validate senders via a "respond to this" message, or you can use web-based contact forms.
So, tell us, what do you actually want a new protocol to do?
Actually, you can. IBM had a pretty complete Windows clone, and there are several partial open source clones. The problem was the same as with Java: as long as Windows and Java are controlled by big companies with their own agendas, it makes no difference whether anybody succeeds at cloning them--by the time they are done, the platform has already shifted under them.
Maybe you should tell that to Microsoft:
Looks like Microsoft firmly believes that GDI is in the kernel. But what do they know anyway.
See here and here.
Many device drivers don't live in kernel space anymore--only some core functionality that moves bits back and forth.
so why not the one for what is arguably the highest performance device of all: the screen?
The reason to put stuff into the kernel is not for performance but for access control and interrupt latency. In terms of performance, a well-designed interface will not have significantly more overhead when it lives in user space. And X11 has been optimized for that case for about 20 years. Of course, badly designed interfaces work a little faster when they are move into the kernel, but that doesn't apply here.
So, in short, X11 isn't in the kernel because it wouldn't make much difference.
The Windows specs are as well.
secondly many groups have take the spec and produced high-quality implementations of some or all of it that range from free to low cost to high cost.
Partial implementations are completely useless: the Java standard is what Sun defines to be in the Java2 platform; anything else is not Java.
Now, forget about all the other stuff, just show me a non-Sun implementation of Swing. The fact is that every single implementation of the J2SE and J2EE platform depends on licensed code from Sun.
In fact I would say that Java2 is the most successful cross platforms GUI framework I have ever worked with.
It is pretty much impossible to write a high-quality cross-platform application in Java, if not for any other reason because Sun's cross-platform toolkit fails to support platform-specific functionality, in some sort of completely confused understanding of what a "cross platform toolkit" is.
If you have real examples of why it does not work then lets here them.
Just check the bug parade. Perennial problems are broken window management, differences in the semantics of transparency, flaky drag-and-drop support, and differences in the meaning of line width, to name just a few.
Of course, more fundamental than plain bugs is the decision of Sun not to support any platform dependent features: no environment variables, little or no desktop integration, etc. A high-quality cross-platform toolkit must support platform-specific functionality, otherwise it's impossible to write good applications in it.
Microsoft is greedy and controlling, but so is Sun. The best thing for open source and customers is to avoid getting involved with either of them.
J2EE is no more open than Microsoft Windows: Sun has patents on many aspects of the system and all the usable implementations are derived from Sun source code (including IBM's). Furthermore, the Java2 GUI implementation has serious problems on non-Windows platforms making J2EE not even a good cross-platform choice for client apps.
A web-based office suite written in Java made sense a few years ago, when Sun was still on track for making Java an open platform that worked well across platforms. These days, it's a curiosity running on a proprietary platform that has significance only on the server.
SWT could be a big deal for the Java community. God knows, Java needs something that's better than Swing. But at this point, it's just a curiosity.
All of that is fine, but it's more policy decision than technology. If you like, you can tell X11 to buffer everything on the graphics card as well. Also, you can double buffer every window and tie redraws to vertical refreshes. Yes, that does look incredibly smooth. It also eats up a lot of resources, and X11 historically has not chosen those defaults. Perhaps desktop toolkits and desktop installations should do that now, but that's not a technical issue with X11.
event delivery latency is negligible
No, it isn't. It is negligible only "most of the time", which also the case on X11 and Windows. But when an OS X machine starts paging or gets slowed down in some other way, latency rises and OS X actually degrades less gracefully than X11.
Altogether, Apple hasn't found the holy grail, they have just picked some defaults that look really nice for desktops. Style is something X11 definitely should copy from Macintosh. But for the technology, I'll stick with X11.
We are not talking about opaque moves--current windowing systems, including X11, handle those just fine by bit-blitting.
I can't think of any good equivalent solutions for resizing,
That is because there isn't any. In the simplest case, which you are thinking about, the user decides how big the window is going to be, by using the mouse. The GUI communicates the new size to the application, the application sends back the updated appearance of the window. One round trip.
I think it should be left up to the program and there will be latency. However as the program can say "resize the window to this" and immediately follow it asynchronously with the new image for the resized window, there will be much less latency than the current version where the window is resized by the window manager and there has to be at least a round trip to the program to get the new drawing.
That doesn't help. The user determines how big the window is going to be and the window has to follow. The application can't just pick a size preemptively and send out redrawing commands for that--if you can see the latency now during redraws, you would see the latency then because the window size wouldn't follow your mouse.
Furthermore, it's a fundamental policy decision under X11 that applications don't get to say "resize to this". That has less to do with usability, and more with being able to use the same programs on a very wide variety of displays: programs simply don't know about all the possible displays and environments to be able to do window management correctly. Putting window management into clients is fundamentally broken, and it would be a huge step backwards for X11 to do that without helping with anything (in fact, I pretty much guarantee it's not going to happen).
Of course, you are free to try this under X11: if you like, your toolkit can resize its own window. You are even free to override the window manager altogether. So, the functionality is already all there, but thankfully, no major toolkit uses it. Just don't expect people to use your application a whole lot if you do that. The few applications that try this (xmms, etc.) are a big pain to use on displays that don't satisfy the assumptions that their author had in mind.
The drawing code definately should support display lists, though I don't think much of the complex structure is needed, because *some* communication is acceptable. A program that draws a hundred buttons of different sizes should be able to send a display list that can draw a button once (keeping it in the server much like an X pixmap) and then send on redraw it just has to send the rectangles and labels of all the buttons and the command to run the display list on each of them.
Well, as I was saying, X11 is getting support for that. That's nice for all sorts of reasons, but it will not solve the problem in general because once you have a round trip, you have latency, even if you only send a little data. What it will do is let the server generate a resized image that's pretty close for normal mouse movements, until the application gets around to redrawing things. It will give the illusion of smooth opaque resizing.
But, then, the server could probably already do that with bitmaps: you resize the window and the server does smooth bitmap scaling to fill in until the update comes from the client. For the 200ms that's going to be on the screen, it's going to look just fine.
But let's keep our perspective here: GUI toolkits are not written for letting animated widgets dance around the screen in real time, they are optimized for mostly static displays. That's a deliberate design tradeoff, and one that meets day-to-day needs well. The only place where that kind of animation occurs during normal usage is with opaque resizing. I don't think it's worth putting a lo
BTW, not to blow this out of proportion--Mozilla is a bit jerky on resizing under X11, but it still keeps up. Furthermore, Mozilla and IE on Windows are about as jerky as Mozilla on X11 (both 1GHz machines with comparable nVidia cards).
Also, examining redraw behavior in Mozilla and Galeon, they seem to be making some progress: it's not a lot faster (yet?), but recent versions behave better over high-latency links.
I have written lots of code for X, and it's really easy--using the right toolkit. Both X servers and clients can be really lightweight and low footprint, and they need not be complex at all.
Perhaps you are confusing X with Xlib and XFree86. XFree86 is a huge, and hugely complex, X server implementation. And Xlib is a 20 year old C language binding. Given their age and scope, they have held up well, but they are showing their age. Fortunately, you have plenty of alternatives, and all those alternatives interoperate because "X" is a protocol, not an API or an implementation.
That doesn't eliminate the latency. Instead, it will just lead to the same behavior we get on Windows, where busted applications not only fail to redraw themselves properly but also do bad things to the entire desktop. It also makes applications unusable over high-latency links.
it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes)
Under X11, applications have to live with the window size they get. That is absolutely essential; trying to put "complex restrictions" on window size would be a disaster. It is exactly those kinds of design decisions that make Windows so much worse than X11.
I suspect this is a combination of excessively complex toolkit programming and perhaps some basic failures of X such as an inability to deliver or respond to expose events quickly enough.
Pretty much all the visual artifacts you get on opaque resizing on X11 for local applications are due to poor toolkit or application code. Mozilla, for example, is absolutely awful, and so are many KDE applications. Compare how unresopnsive Mozilla is to Dillo (however, Dillo still flickers--another thing that can be avoided by a reasonably written toolkit).
Having said that, however, all major window systems are client/server systems, and for good reasons. No matter how you slice it, there is the possibility of arbitrary latencies in such systems, even for applications running locally. Applications and toolkits should be written to deal reasonably with latency, but most aren't.
The only way to avoid problems with latency is to put actual code server-side. None of the major attempts at that have succeeded, and I think for good reason. A modest compromise is to put structured graphics server-side; Apple has already done that in OS X and X11 is getting server-side structured graphics as part of XRENDER.
So, in practice, a well-written X11 toolkit can easily get good opaque resizing for local applications running on an unloaded machine. And if the machine is loaded or if the application is running remotely, nothing will make opaque resizing look good in general.
I believe TNT2 drivers for XFree86 should be OK; make sure you are actually using the accelerated versions and not the generic drivers.
Now, window drawing and resizing behavior depends on the applications you use. Unfortunately, many common toolkits/environments, including KDE and Mozilla, have serious problems in that department: their redrawing logic is just completely broken: not only is it slow, it's actually not even correct. You can see that X11 is perfectly capable of handling that kind of redrawing by running Dillo and resizing it: it's very responsive (and even Dillo's redrawing logic isn't all that good--for example, it could the bit of flickering it has easily).
The solution? Don't use applications that behave poorly, or complain to the application/GUI/toolkit authors. This is not a problem with X11.
What Keith is talking about in that paper is very useful, but most of it is not about speeding up local uses of X11. And the things that do apply to local uses of X11 also pretty much apply to XP and Macintosh, because those also use a client/server architecture, just like X11.
Such a setup is nice mostly because it keeps noisy disk drives out of your living room and doesn't require cabling.
However, last I checked, porn was still legal in the US, so there is no reason to hide it. However, if you keep illegal pornography (violating copyright or child pornography laws), just get rid of it--one might argue that US laws are paranoid and silly, but that's an argument to be made in the legislatures, not from behind bars. The FBI may not be at the forefront of technology, but they aren't completely stupid either, and they probably have seen it all before.
Drink water and snack on solid fruit (or raw vegetables) and you should be fine. Another rule of thumb is: avoid all packaged or commercial foods--anything with a label, wrapper, box, or bottle is probably fattening.
Most people probably don't even have to count calories. Just eliminate sugar-containing soft drinks (and, to avoid temptation, their "low-cal" counterparts). And snacking on raw fruits and vegetables will fill you up without a lot of calories, both giving you some relief from feeling hungry and making you eat less at your next meal.
There is no "fluff" there. X11 runs as a separate user-mode process from applications. That means that commands to it need to go from the user process to the display process. X11 uses an asynchronous protocol and a mixture of shared memory and UNIX-domain sockets. And for games and other applications, there is DRI.
It happens to be the case that the X11 protocol and semantics are well-enough defined that the same protocol works over fast networks, but you don't pay anything for that.
Macintosh (as far a I can tell) works the same way: a display server, user mode applicatins, and some IPC mechanism connecting them. The only reason remote display for the Mac doesn't work like X11 is because it lacks some high-level primitives.
Windows used to start out as a frame buffer library, but it, too, works pretty much like X11 these days: asynchronous communications between user-mode processes and a display server running in a separate address space. The only thing NT/XP do differently is that the display server runs i the kernel. You could put an X11 server in the kernel, but it probably wouldn't make a big difference in performance (and it would be a headache).
When a particular X11 implementatin is slow, it's usually because of bad drivers or bad configuration. With comparable drivers, X11 performance is top-notch--usually better than Macintosh and comparable to Windows. And many X11 applications are slow or inefficient because their developers assumed they were programming a frame buffer--an assumption that is wrong on all major GUI platforms these days.
In short, this "X is slow because of network transparency" is wrong in multiple ways. First, X11 is not slow compared to other popular windowing systems. Second, nobody has ever been able to describe a way in which X11 could be made faster by choosing a different IPC mechanism. People who criticize X11 for using IPC usually assume incorrectly that other systems don't use IPC, but they do.
2. Standardization. Flexibility is nice, but having every damn program do things differently is annoying. It's also a very bad thing if you are trying to break into the mainstream.
X11 is standardized. What is not standardized is GUI environments and toolkits. But there is a reason for that: people are still figuring it out. It's software evolution in action. And it's not like Windows or Macintosh have figured that one out either: on Windows, people use dozens of different toolkits, several of which come from Microsoft Similarly for Macintosh. Gnome and KDE are making an effort to interoperate, and that's all you can ask for.
Also, there are plenty of programs that need to "o things differently". X11 is not just a desktop window system, it's used for scientific and engineering applications, customer terminals, ATMs, banking workstations, embedded systems, and lots of other applications. Those environments should not look like a regular desktop.
3. Easier configuration. It can be a real bitch to get xwindows running properly. Considering the huge amount of differing hardware in the wild, I'm not so sure it would be possible to simplify it too much. Oh, well.
I think people are doing as well as they can, given limited information from manufacturers.
But because X11 is standardized, you can always buy a commercially supported X11 server. Those usually run very well on the latest hardware. If you are using XFree86, you are using something that's both free and experimental.
As far as I can tell, "the split" is over none of these issues. Both branches will remain network transparent window systems, they will remain compatible, and they will continue not to force toolkits or desktop software on users. If they tried to, they would cease being X11 implementations. What Keith probably will do is accelerate bug fixing and bringing extensions into the X11 server. And that's what really matters.
And if you think that this is Singapore-only, think again. Every nation, including the US, has public health regulations in place to quarantine people when there is a medical emergency.
You didn't use to be able to get a laser printer for under $1000. If you pay that kind of money for a laser printer today, chances are that you will get a quality product as well. If you buy a $300 special, on the other hand, the PostScript interpreter will run on your PC and the thing will likely fall apart quickly.
Why is this in the Apple category? What does Linux running on a non-Apple PPC motherboard have to do with Apple?