You've got to be kidding me. Supporting Java, even something as simple as applets, across multiple platforms is a nightmare. The number of GUI bugs and inconsistencies is astounding, both in AWT and Swing. Supporting Mac is especially fun, since it has its own Java implementation, with its own set of bugs and oddities. And then there's the fact that different versions of Java, even different sub-versions, have their sets of problems, so workarounds need to be able to work with different sets of bugs. It's really a nightmare. I'm not saying C++ is better, b/c it's not, but Java does NOT shine in any way, shape or form.
My ex-girlfriend wrote fairly male-like code. No comments, not often formatted properly, not always the clearest way of doing things, etc. I, on the other hand, am anal about formatting and logical structure, although I am still pretty light on the comments. And I never try to malevolently write unmaintainable code...quite the opposite, in fact. When I'm writing one-off perl scripts, I will, however, try to be as clever as possible;).
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 1
Windows and Mac OS X may have had calls for scrollbars, but those were exactly equivalent to toolkits on Linux. The server-side stuff is the same as it is with X. What Windows and Mac OS X enforce that Linux doesn't is that the ONLY way to access the GUI is through the standard toolkit (e.g., Cocoa in Mac OS X). This is what enforces a common look and feel.
It's not inefficient to push pixels over the wire since that's going to have to be done a lot of the time anyways, with images, custom widgets and fonts. A lot of times pixmaps with SHM are used, which are really pretty efficient. The problem with X is NOT being able to push things fast enough over the wire. People need to get over this.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 1
> People would be free to create their own widgets; the API would certainly have to be backwards-compatible. But the > back-end, which is now largely a forgotten playground, would become alive with the creation of new widgets just as well. Or > so I imagine it at least.
Mmm, no. Right now, I can, in a program, subclass an existing widget in a few lines of code and it just works. It can even be painted differently, behave differently, etc. Server doesn't know. Server doesn't have to care. It's all client side. Under your system, I'd either have to create a whole new widget program and install it on my target systems, or have some way of uploading a.so file to the X server, but only when my program is running. Both solutions are absurd. This is the problem with server-side widgets. Also of interest is that no GUI system that I'm aware of does anything like what you propose. There's a reason for that. Splitting up the work between client and server for widgets is overkill and leads to a host of problems.
> With regards to your fonts-in-the-backend disaster; that cannot be blamed purely on its placing; fonts were then, are > now, and will always be, an intellectual-property-shrouded very difficult hurdle to overcome. And that was one of the > main reasons it failed; at the time, the (open source) availability of good fonts and presentation (anti-aliasing) > technology were simply way behind the times and/any/ new approach to fonts would have failed. I still think having them > in the backend would still be a good idea. As long as the package comes with a good standard app to select and expand > them. Currently, xfontsel won't do, really. And them I'm being generous.
Intellectual property wasn't the problem with server-side fonts. The problem was that server-side fonts were opaque and hard to manage from the client side. The client had little control over the rendering of the fonts, but even then, there was already a large swath of protocol devoted to giving the client at least some control over the fonts. It was a mess. If a client wanted to do special rendering of fonts, or anti-aliasing (the main reason why the old font system was dropped), it was impossible. Clients would just have to do their own rendering to pixmaps and send that to the X server, which completely went around the entire server-side font system, negating what value it had. Rather than add more hooks and hacks so that the client could try to manipulate fonts and rendering over a wire protocol, the X developers had the bright idea to move it mostly to the client side, where it could be handled by client-side libraries.
The trend has been to move things to client-side. Toolkits, fonts, advanced rendering (Cairo) and so forth. Please don't ask for this very useful trend to be reversed, with no benefit, but an increase in complexity and ugliness.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 1
Until people want to have custom widgets or themes, or want to use older X servers (or non X.org X servers), or any number of other problems with this system. They already tried this with fonts and it was an unmitigated disaster. Let's not repeat history.
The calls to the X server are simpler, they would become much more complex. All that stuff that you think would be handled silently by the X server would actually have to be reported back to the client (scrollbar movement, for example). And instead of having the client telling the X server to draw a shape, it would have to start talking about scrollbar details and there's no way an X server could implement all those details for every possible client. Instead of a simple protocol, you now have a complex one with no flexibility (just like the server-side font disaster).
The fact is, the X server isn't going to be any faster or simpler because it knows about scrollbars. The speed problems with X are not related to the fact that clients manage scrollbars. By putting some aspects of widgets on the server and some remaining on the client, you have a very strange split that requires specialized communication between the server and the clients, making the protocol ugly and cumbersome and not easily expanded upon.
Again, all major windowing system have client-side widgets. It just makes sense.
Compositing? Speedy rendering? Proper multi-head support? You think client applications can do this?
Re:Haven't really noticed any reduced quality ..
on
The State of X.Org
·
· Score: 1
I've been watching the mailing lists and the git commit logs and...there's not a whole lot going on. It used to be considerably busier. Now it's pretty dead. Not unsubstantiated. And then, of course, there's the fact that they've missed a release by 5 months, which has to tell you something.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 2, Insightful
The only place such a system might be of benefit would be over slow network connections, which is precisely the scenario where uploading server-side binary blobs to draw widgets would be an absolute nightmare. The idea of server-side widgets has been discussed and deemed to be a bad idea. The fact that none of the major windowing systems (Windows USER/GDI and Mac OS X Quartz/Aqua) use such a system should also indicate to you that everyone else thinks it's a bad idea too.
I apologize. Your misinterpretation was because of a bracketing problem. "(academic discussions over color specs) and (other pointless things)". In any case, I don't disagree with you. But they've been barely discussing the issue for many weeks now. There's no proposal for a solution, there's nobody taking charge, just more and more discussion that's going nowhere and probably won't ever go anywhere unless things change.
Re:Slow release cycles aren't bad for core project
on
The State of X.Org
·
· Score: 1
But user-level applications need features in the kernel and the windowing system to do a number of modern things. We can't just have X go into maintenance mode if we want user-level applications to progress.
Furthermore, if we take your approach of having downstream do all the hip new features, we end up in distro hell. Each distribution with its own special implementations for new features, all incompatible with other distros (or nominally compatible), all requiring huge distro-specific patchsets, that have to be maintained independent of upstream. Yeah, that's been done before and it was universally agreed to be a bad idea. Most people these days would prefer that most stuff goes and stays upstream, to prevent gratuitous incompatibilities between distros and forks and such.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 4, Informative
No windowing system has anything resembling widgets on the server-side. It's all done in client-side libraries, where that kind of stuff belongs. The server-exposed interface just provides the mechanisms needed for implementing widgets. That part is fine and doesn't need to change.
As for the protocol, only a few parts are actually poorly designed. Grabs need to be reworked as they can result in subtle race conditions and lock-ups. There's a lot of old cruft that nobody uses that could go away, but isn't really causing a problem by remaining in the protocol. The main historical problem was Xlib, which did a lot of stupid things with the protocol, resulting in reduced performance, especially over the network. XCB fixes that, although no toolkits have been ported to pure XCB yet (and it may be a while).
Ultimately what's going to be happening is the move towards Composite/EXA, OpenGL and DRI(2) for everything, which should negate a lot of the existing problems with X's rendering infrastructure. Again, the lack of manpower is going to prevent these projects from making much forward progress.
Re:Haven't really noticed any reduced quality ..
on
The State of X.Org
·
· Score: 4, Informative
It's not that they missed their date because they were busily fixing bugs and adding new features; they missed it because they're just not doing that much right now. There's no management, there's very little direction, and there's really not that much going on at all. That's not a good thing.
Aside from Keith Packard and Dave Airlie, and maybe one or two others, how many paid full-time X developers are there? Watching the mailing list, it seems like there's a couple of volunteers, some people who submit the occasional patch but otherwise work on Qt, or GNOME or whatever, and then the core listed above. I think there just isn't enough manpower right now and the distros, instead of fixing that problem, just maintain their own patchsets and do a "good enough" job to make X work smoothly for their releases, and leave it at that. Clearly, nobody wants to make X a priority and it shows.
The Wiki is almost never up to date, it's nigh on impossible to build a working X system from git, even with the couple of half-arsed build scripts available from the mailing list (for my part, I have never been able to get it to build completely, and not for lack of trying or ability). The mailing list is full of academic arguments over color specs and other pointless things, or people asking for help. There used to be a lot of discussion on how to improve X and also, how to get things done. That no longer happens.
What the distros and Linux companies need to do is get more people working directly on X and get serious about making X a serious project. It's not just some option piece of software that nobody has to care about. It's only one of the most important aspects of desktop Linux. And it just makes no sense to me that no distros are really spearheading X development. If they don't take the time to make this an issue, X will continue to atrophy, further limiting Linux's potential in the market.
There is/was TWin, which is pretty functional for having been developed and maintained by only one guy. It had an API to write programs that directly accessed the text windows, but there were only a very few programs (all included in the TWin distribution) that did that. Mostly, it just gave you a bunch of terminal windows and the ability to attach and detach sessions, something X still lacks.
I mostly agree, but it happens that their HTML doesn't validate. Also, their CSS is a little weird for the three column layout. They have a float: right for the rightmost column (the one that overlaps on this guys site), but position: absolute as well. I don't know what that's supposed to mean, but it can't be good.
You sure that's all in the kernel? I have a feeling that's mostly, if not entirely, in userland APIs, which is not uncommon to happen on Linux either. Witness X and the toolkits.
That's not any better. Instead of blindly trusting a company, you are blindly trusting some hackers in mom's basement, many of whom have personality problems (Theo de Raadt, RMS, Hans Reiser, et al).
Again, unless you are actually looking over the source code yourself, you have no reason to trust one over the other.
And if you really care about whether data is being sold, you can always use monitoring tools, to see, for example, where packets are going, etc. The software doesn't need to be open source for you to do that. There's also strace and even gdb could be useful to an extent.
Damn straight! I've had exactly one girlfriend to date, and somehow I feel like she'll have been my last. Certainly nowhere near procreating, that's for damn sure.
No. Life is a mix of passionate exertion, love and recreation. Sometimes, you just have to have fun and it doesn't have to be this great work of skill or talent. That's all. Elsewhere in my life I most certainly apply myself greatly and am justly rewarded. I don't, however, care to do that with a guitar. But Guitar Hero is fun all the same and I don't think you can fault me for occasionally coming home from work and playing a couple of songs I like on a stupid game.
Maybe I don't want to learn how to play the guitar, but I do want to have some fun? Is that allowed? Or does everything I do have to be a fucking chore?
Man, they REALLY should have picked a different name for this release. Of course a headline like this would come along, and of course I'd misread the title, again. At least this time it's sort of appropriate.
Slashdot Mirror
You've got to be kidding me. Supporting Java, even something as simple as applets, across multiple platforms is a nightmare. The number of GUI bugs and inconsistencies is astounding, both in AWT and Swing. Supporting Mac is especially fun, since it has its own Java implementation, with its own set of bugs and oddities. And then there's the fact that different versions of Java, even different sub-versions, have their sets of problems, so workarounds need to be able to work with different sets of bugs. It's really a nightmare. I'm not saying C++ is better, b/c it's not, but Java does NOT shine in any way, shape or form.
Nah, I've just come to hate women. Personal reasons.
Damn straight!
My ex-girlfriend wrote fairly male-like code. No comments, not often formatted properly, not always the clearest way of doing things, etc. I, on the other hand, am anal about formatting and logical structure, although I am still pretty light on the comments. And I never try to malevolently write unmaintainable code...quite the opposite, in fact. When I'm writing one-off perl scripts, I will, however, try to be as clever as possible ;).
Windows and Mac OS X may have had calls for scrollbars, but those were exactly equivalent to toolkits on Linux. The server-side stuff is the same as it is with X. What Windows and Mac OS X enforce that Linux doesn't is that the ONLY way to access the GUI is through the standard toolkit (e.g., Cocoa in Mac OS X). This is what enforces a common look and feel.
It's not inefficient to push pixels over the wire since that's going to have to be done a lot of the time anyways, with images, custom widgets and fonts. A lot of times pixmaps with SHM are used, which are really pretty efficient. The problem with X is NOT being able to push things fast enough over the wire. People need to get over this.
> People would be free to create their own widgets; the API would certainly have to be backwards-compatible. But the
.so file to the X server, but only when my program is running. Both solutions are absurd. This is the problem with server-side widgets. Also of interest is that no GUI system that I'm aware of does anything like what you propose. There's a reason for that. Splitting up the work between client and server for widgets is overkill and leads to a host of problems.
/any/ new approach to fonts would have failed. I still think having them
> back-end, which is now largely a forgotten playground, would become alive with the creation of new widgets just as well. Or
> so I imagine it at least.
Mmm, no. Right now, I can, in a program, subclass an existing widget in a few lines of code and it just works. It can even be painted differently, behave differently, etc. Server doesn't know. Server doesn't have to care. It's all client side. Under your system, I'd either have to create a whole new widget program and install it on my target systems, or have some way of uploading a
> With regards to your fonts-in-the-backend disaster; that cannot be blamed purely on its placing; fonts were then, are
> now, and will always be, an intellectual-property-shrouded very difficult hurdle to overcome. And that was one of the
> main reasons it failed; at the time, the (open source) availability of good fonts and presentation (anti-aliasing)
> technology were simply way behind the times and
> in the backend would still be a good idea. As long as the package comes with a good standard app to select and expand
> them. Currently, xfontsel won't do, really. And them I'm being generous.
Intellectual property wasn't the problem with server-side fonts. The problem was that server-side fonts were opaque and hard to manage from the client side. The client had little control over the rendering of the fonts, but even then, there was already a large swath of protocol devoted to giving the client at least some control over the fonts. It was a mess. If a client wanted to do special rendering of fonts, or anti-aliasing (the main reason why the old font system was dropped), it was impossible. Clients would just have to do their own rendering to pixmaps and send that to the X server, which completely went around the entire server-side font system, negating what value it had. Rather than add more hooks and hacks so that the client could try to manipulate fonts and rendering over a wire protocol, the X developers had the bright idea to move it mostly to the client side, where it could be handled by client-side libraries.
The trend has been to move things to client-side. Toolkits, fonts, advanced rendering (Cairo) and so forth. Please don't ask for this very useful trend to be reversed, with no benefit, but an increase in complexity and ugliness.
Until people want to have custom widgets or themes, or want to use older X servers (or non X.org X servers), or any number of other problems with this system. They already tried this with fonts and it was an unmitigated disaster. Let's not repeat history.
The calls to the X server are simpler, they would become much more complex. All that stuff that you think would be handled silently by the X server would actually have to be reported back to the client (scrollbar movement, for example). And instead of having the client telling the X server to draw a shape, it would have to start talking about scrollbar details and there's no way an X server could implement all those details for every possible client. Instead of a simple protocol, you now have a complex one with no flexibility (just like the server-side font disaster).
The fact is, the X server isn't going to be any faster or simpler because it knows about scrollbars. The speed problems with X are not related to the fact that clients manage scrollbars. By putting some aspects of widgets on the server and some remaining on the client, you have a very strange split that requires specialized communication between the server and the clients, making the protocol ugly and cumbersome and not easily expanded upon.
Again, all major windowing system have client-side widgets. It just makes sense.
Compositing? Speedy rendering? Proper multi-head support? You think client applications can do this?
I've been watching the mailing lists and the git commit logs and...there's not a whole lot going on. It used to be considerably busier. Now it's pretty dead. Not unsubstantiated. And then, of course, there's the fact that they've missed a release by 5 months, which has to tell you something.
The only place such a system might be of benefit would be over slow network connections, which is precisely the scenario where uploading server-side binary blobs to draw widgets would be an absolute nightmare. The idea of server-side widgets has been discussed and deemed to be a bad idea. The fact that none of the major windowing systems (Windows USER/GDI and Mac OS X Quartz/Aqua) use such a system should also indicate to you that everyone else thinks it's a bad idea too.
I apologize. Your misinterpretation was because of a bracketing problem. "(academic discussions over color specs) and (other pointless things)". In any case, I don't disagree with you. But they've been barely discussing the issue for many weeks now. There's no proposal for a solution, there's nobody taking charge, just more and more discussion that's going nowhere and probably won't ever go anywhere unless things change.
But user-level applications need features in the kernel and the windowing system to do a number of modern things. We can't just have X go into maintenance mode if we want user-level applications to progress.
Furthermore, if we take your approach of having downstream do all the hip new features, we end up in distro hell. Each distribution with its own special implementations for new features, all incompatible with other distros (or nominally compatible), all requiring huge distro-specific patchsets, that have to be maintained independent of upstream. Yeah, that's been done before and it was universally agreed to be a bad idea. Most people these days would prefer that most stuff goes and stays upstream, to prevent gratuitous incompatibilities between distros and forks and such.
No windowing system has anything resembling widgets on the server-side. It's all done in client-side libraries, where that kind of stuff belongs. The server-exposed interface just provides the mechanisms needed for implementing widgets. That part is fine and doesn't need to change.
As for the protocol, only a few parts are actually poorly designed. Grabs need to be reworked as they can result in subtle race conditions and lock-ups. There's a lot of old cruft that nobody uses that could go away, but isn't really causing a problem by remaining in the protocol. The main historical problem was Xlib, which did a lot of stupid things with the protocol, resulting in reduced performance, especially over the network. XCB fixes that, although no toolkits have been ported to pure XCB yet (and it may be a while).
Ultimately what's going to be happening is the move towards Composite/EXA, OpenGL and DRI(2) for everything, which should negate a lot of the existing problems with X's rendering infrastructure. Again, the lack of manpower is going to prevent these projects from making much forward progress.
It's not that they missed their date because they were busily fixing bugs and adding new features; they missed it because they're just not doing that much right now. There's no management, there's very little direction, and there's really not that much going on at all. That's not a good thing.
Aside from Keith Packard and Dave Airlie, and maybe one or two others, how many paid full-time X developers are there? Watching the mailing list, it seems like there's a couple of volunteers, some people who submit the occasional patch but otherwise work on Qt, or GNOME or whatever, and then the core listed above. I think there just isn't enough manpower right now and the distros, instead of fixing that problem, just maintain their own patchsets and do a "good enough" job to make X work smoothly for their releases, and leave it at that. Clearly, nobody wants to make X a priority and it shows. The Wiki is almost never up to date, it's nigh on impossible to build a working X system from git, even with the couple of half-arsed build scripts available from the mailing list (for my part, I have never been able to get it to build completely, and not for lack of trying or ability). The mailing list is full of academic arguments over color specs and other pointless things, or people asking for help. There used to be a lot of discussion on how to improve X and also, how to get things done. That no longer happens. What the distros and Linux companies need to do is get more people working directly on X and get serious about making X a serious project. It's not just some option piece of software that nobody has to care about. It's only one of the most important aspects of desktop Linux. And it just makes no sense to me that no distros are really spearheading X development. If they don't take the time to make this an issue, X will continue to atrophy, further limiting Linux's potential in the market.
I don't know why you chose to take his correctly spelled "fuel" and then misspell it in the quote and in your own text. Baffling.
There is/was TWin, which is pretty functional for having been developed and maintained by only one guy. It had an API to write programs that directly accessed the text windows, but there were only a very few programs (all included in the TWin distribution) that did that. Mostly, it just gave you a bunch of terminal windows and the ability to attach and detach sessions, something X still lacks.
I find that girls often describe themselves as dorks with increasing frequency and I think it's some sort of attention thing.
I mostly agree, but it happens that their HTML doesn't validate. Also, their CSS is a little weird for the three column layout. They have a float: right for the rightmost column (the one that overlaps on this guys site), but position: absolute as well. I don't know what that's supposed to mean, but it can't be good.
You sure that's all in the kernel? I have a feeling that's mostly, if not entirely, in userland APIs, which is not uncommon to happen on Linux either. Witness X and the toolkits.
That's not any better. Instead of blindly trusting a company, you are blindly trusting some hackers in mom's basement, many of whom have personality problems (Theo de Raadt, RMS, Hans Reiser, et al). Again, unless you are actually looking over the source code yourself, you have no reason to trust one over the other. And if you really care about whether data is being sold, you can always use monitoring tools, to see, for example, where packets are going, etc. The software doesn't need to be open source for you to do that. There's also strace and even gdb could be useful to an extent.
Damn straight! I've had exactly one girlfriend to date, and somehow I feel like she'll have been my last. Certainly nowhere near procreating, that's for damn sure.
No. Life is a mix of passionate exertion, love and recreation. Sometimes, you just have to have fun and it doesn't have to be this great work of skill or talent. That's all. Elsewhere in my life I most certainly apply myself greatly and am justly rewarded. I don't, however, care to do that with a guitar. But Guitar Hero is fun all the same and I don't think you can fault me for occasionally coming home from work and playing a couple of songs I like on a stupid game.
Maybe I don't want to learn how to play the guitar, but I do want to have some fun? Is that allowed? Or does everything I do have to be a fucking chore?
Man, they REALLY should have picked a different name for this release. Of course a headline like this would come along, and of course I'd misread the title, again. At least this time it's sort of appropriate.