Slashdot Mirror
The XFree86 Fork() Saga Continues
Mortimer.CA writes "An article up on OSNews about the XFree story
mentioned earlier. Included is: replacing fontconfig with Sun's stsf; XFree86 co-founder David Wexelblat saying that XFree is today obsolete and should be changed; Keith Packard replying, and more."
fork(), you mean.
From the slashdot.org 'Post Comment' page:
(Use the Preview Button! Check those URLs! Don't forget the http://!)
http://www.osnews.com/story.php?news_id=3090.
Not http://slashdot.org/TheXFree86Fork()SagaContinues
I am TheRaven on Soylent News
http://osnews.com/story.php?news_id=3090
Attack of the Spoons
Time for Fresco?
I can't help myself...
;^)
"The saga continues..."
"Use the fork() David"
(BTW, expect to bring about introduction of new post-rating: +5 Lame!
I have a bad feling that this is goint to be one of those situations where *every* party involved is both right and wrong on some level. Even uglier is the possibility that this could occur on the *same* level. The fact that situations like this could arise in the first place tells me that maybe the architecture of XFree86 (the ideas underlying the code itself) is overly complex for today's needs.
Or another possibility: maybe the way XFree86 is currently implemented by the major *nix vendors is overly complex by default.
Either way, both the situation and the implementation are starting to look really messy.
C|N>K
Now, that was an interesting reading in the XFree86 forum mailing list. We get individuals, companies like Sun, SciTechSoft, Red Hat etc. 'fighting' for issues varying from what XFree86 really needs, down to replacing fontconfig with Sun's stsf, XFree86 co-founder David Wexelblat saying that XFree is today obsolete and that needs to be replaced with a direct-rendered model (by retaining backwards compatibility), Keith Packard replying as to why a new organization to handle X is needed, and more.
Our Take: One thing is clear after reading all these messages: a lot of people are not happy with what's happening with the development of XFree86. It is obvious that more discussion is needed to decide what's going to be implemented and what not, and from these emails there, it seems that there was no real/common direction discussed between the interested parties until yesterday. No real communication seemed to exist!
Let's hope that this open forum list will show what people want and need and will 'open' the XFree86 organization in a way that will allow more CVS commits, as the project seems kind of stagnant and doesn't move as fast as it should have, as some Red Hat employees also noted (for example, direct changing of resolution was introduced just a few months ago with RandR extension, while Windows 95 could do that in 1995).
The XFree86 project always looked a bit conservative to me while more development and openess is needed. There is no need for a "new XFree", but there is a need for more development and 'fixing' on the existing codebase.
--------
Free your mind.
If this leaves the XFree86 project as a more flexable, open, and more modular project, then so be it. I'm all for anything that can improve performance for *NIX GUIs.
From everything I see, it's too late in the game to make a new graphical interface - unless it has a compatability layer to work with X apps. But even then, we'd need to develop it FAST to make sure *NIX doesn't fall behind in the OS game.
I am a filthy pirate.
Do you people recall the Armageddon textfile that got post on /. several times ? Here a little quote from the text.
well you could easily come up and tell me to simply not use GNOME and let them do whatever they like. Well, you are right with that but things are more complicated nowadays. GNOME is influencing a lot of third party projects such as XFree86 which recently added a lot of GNOME components into their CVS repository. Please know that with the next coming XFree86 version you get a lot of GNOME components without even knowing it. code like, GNOME-XML, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into GNOME development. Also the GIMP is maturing more and more into getting the look and feel of a native GNOME application. The CVS version of the GIMP has a lot of GNOME pixmaps inside and they are heavily working on integrate the GIMP into GNOME. If not today but the direction is sure and i fear the day this gonna happen.
And this will happen with an Forked XFREE. It matures more and more into a GNOME dependant piece of Software. Exactly that guy who's responsible adding all sorts of GNOME material to it will now make XFREE mature into some GNOME dependant component.
Havoc Pennington (GNOME) works on XFREE,
Owen Taylor (GTK+) works on XFREE,
Jim Gettys (XFREE) and GNOME FOUNDATION president,
Keith Packard (XFREE) and GNOME developer.
Psssshht! I mean really! Who wants to setup a thin-client model at their business anyway? I mean saving millions of dollars? What's up with that?!
and it has ugly ass fonts....
Damn straight! Anyone who has zero knowledge about X knows that the fonts are hard coded into the display manager. And that there's no way you can add new fonts to it.
and it has shit write to hardware through TCP ports...
Like, I'm saying, yo! There ain't no client/server interface. When you be sending them X packets to the other computer, you're talking directly to the hardware! That's why every X command is "add ax,bx" and sh*t like that! It's pure assembly, bro!
Everyone knows that the only way to do it is to build a gigantic motherf*cking graphics subsystem into the kernel so that your system resources are halved and your OS crashes every week. Like, that's the ONLY way it should be.
I looked at some of the screenshots for stsf and I think that it's pretty sweet. The standard Motif font menu labels are hilarious though, the selectable fonts look awesome and the old motif fonts in the menus look terrible.
Here's some links to the screenshots of stsf running on Solaris 9:
xclock -digital -fg yellow -bgpixmap SolarisLogo.pm -fga 0.5
LANG=zh_CN.UTF-8 xclock -digital -bgpixmap RicePaper.pm
My blog
The concept of the community voting for membership in the leadership of the project is an almost, if not totally, non-existant concept in the Open Source world (feel free to show me examples). I'm not talking about advocacy groups, like Linux International. I'm talking about development projects. XFree86 has no interest in this, as far as I can tell.
I can think of one right now. So can he, since he mentions it a few paraghraphs later. The FreeBSD Core team is elected. To be core on FreeBSD you have to be an active developer, and have not pissed too many other developers off recently (or at least pissed them off less than most other people). Sounds like a good idea to me...
Oh. Wait. Sorry, I forgot. FreeBSD is dead. I really should stop using it sometimes soon. Can't be using a dead OS on my desktop...
I am TheRaven on Soylent News
Whatever happened to choice in this debate?
We can choose between various window managers, various linux flavors, and even office suites. Why don't we have a choice with our window system?
Why would it be any different for a fork of X for a choice between client/server and direct rendering, if backwards compatability was kept?
Would that not help the the people who only use Linux on their desktop, while allowing people with networks to use the tool, as it is now, that works for them?
How this got modded up is beyond me. Not only is it not insightful, it's downright wrong!
When communicating to local hardware, there is no TCP/IP anywhere. It communicates over a local socket. It has been implemented with shared memory, and guess what? It didn't perform any better than over a local socket! That's why you don't see shared memory in XFree today.
And i dunno about you, but my fonts look just fine. They're probably the same TrueType fonts you've seen a million times on Windows.
b.c
I recently saw somebody try to contribute a new driver to XFree86. He was told that he was welcome to contribute the driver, but that he wouldn't be allowed write access to it once he had handed it over. What a ridiculous policy!
The thing is, drivers can be released independently of X itself. For ATI Radeons, for example, there are at least 3 different drivers they can use. It would be nice if somebody set up a website with a page for each video card (or family of cards) that had links to all of the available video drivers for that card. Even better would be if such a website could act as a catalyst for uniting these independent driver developers so that, for example, the GATOS radeon driver developers and the DRI radeon driver developers could combine the best aspects of their drivers. This could possibly help route around the blockage that the XFree86 project too often represents.
Actually, I think that such "hardware-centric clearing houses" would be useful for all kinds of hardware, not just video cards. Look at linuxprinting.org to see how well it can work.
-DA
all I could picture was "The Swedish (chef) Programmer" saying:
Ya booor skay, ska boo ske-deeke-skeee Fork()!Fork()!Fork()!
.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
X really needs to standardize itself. Copying and pasting is a bitch....X is heavy at times too and somewhat bloated. Change would be greatly welcomed...or a new X-Windows engine...
As David W points out, XFree86 is around 11 years old. I was around when the project was started and was a low-key member (my name was all over the documentation for many years afterwards and may still be, I haven't checked for a long time).
Anyway, one thing that rarely gets mentioned is how XFree86 itself was a fork. A fork from a recalcitrant developer, namely Thomas Roell. Roell went on to be a principal (probably founding) engineer at Xinside, later renamed Xi Graphics. Roell was the primary author of X386 which was the only freely available X server for x86 systems (typically SVR3 and SVR4 unices from a handful of companies like AT&T and Dell - yes Dell actually had their own Unix distribution and it was pretty kickass too). X386 had limited chipset support (IRC, Tseng Labs ET4000 was the faster chipset it supported) and little if any support for hardware acceleration.
Anyway, the story gets a little murky here, because I wasn't in on all the background machinations, but a couple of developers who are now in the core group (DavidW for one, and I'm thinking David Dawes and Tsilias, but don't quote me) got together and forked their version of X386 to add support for more chipsets and more OSes, kinda leaving Roell (unhappily) in the dust. It didn't help that Roell's got an ego (which he *mostly* deserves) and that DavidW had a kind of angry-young-man online persona at the time either.
It appears that Roell eventually got over it, but never enough to join in the fun. Instead he went on to do commercial X server development, ultimately at XiG.
But, the moral of the story here is that XFree86 itself (even before it had a name, I remember the vote on the mailing list, I didn't vote for it, thought it was kinda dorky, but I guess my own suggestion was even dorkier since it didn't win) is a fork of code that was floundering and not being developed fast enough for the tastes of some people. People who were willing to put their code where their mouthes were and to improve the situation, and who didn't really care too much who they pissed off in the process as long as the end result was a big improvement - and that it definitely was.
I've been out of the loop on XFree86 for many years, but from the outside looking in, this current spat has the ring of history repeating itself to me. It is just more public since the userbase is a couple of orders of magntitude larger than it was the first time around, and there was no slashdot back then either...
I still remember the transition from X10 to X11.
However, version 11 is almost 15 years old and we
never saw any version 12 (not that I beleive version numbering is any important).
Although I saw some nice extensions being added to the X protocol, there are many parts of the X window system that are now obsolete.
For instance the standard X11 font rendering system looks like it has been kept in the stone age (only recently the Xft extension solved part of the problem).
I really like the network transparency of X and the client-server model, because of all it's advantages and, if you look at it in detail, you will be surprised that it doesn't impose any performance penalty: because of the way the X protocol is implemented, commands are queued by the client and are sent to the server in batches, in order to minimize client/server context switching.
However, in the last 12 years we have seen the graphics hardware improove a lotm but the core X system didn't improove almost anything.
Now we have hardware capable of displaying full motion video, hardware video decompressing, anti-aliasing, alhpa-blending and transparency, 3D, etc.
Meanwhile, X got some extensions to support some of these features, but there are no "standard" APIs and the evolution has been very slow.
X is great, and many of the complaints about X that I regularly read here in
I spent a brief time working as a contractor for a Linux distributor (now defunct). During that time, I was given the task of maintaining portions of XFree86's XInput and DRI code. What I saw, I didn't like.
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
as long as it isn't $EDITOR im fine. don't want to start any flamewars between Emacs and Vi.
John Carmack fan, browsing at +5 since 1999.
and it has ugly ass fonts
>>>>>>>>>
Check out this and this. The letter shapes, even on the complex Kaufmann font, are incredible. They'll probably look color fringed on a CRT, because I took these with subpixel AA enabled.
hardware through TCP ports
>>>>>>>>>>
Um, XFree86 uses UNIX domain sockets (very fast on Linux) for local connections, not TCP sockets!
A deep unwavering belief is a sure sign you're missing something...
you put the graphics close to the metal and then abstract that instead. That's why DirectX is the darling of game developers.
>>>>>>>>>
That's hilarious. Graphics hardware has gotten so advanced, that direct access actually *hinders* performance because it prevents the graphics card from optimizing things as well (a developer for the BeOS Radeon driver once told me this). DirectDraw has been getting significantly more abstracted, to the point where it was put on top of Direct3D which, like OpenGL, is a quite high-level abstraction. Look at the way current graphics cards are designed to run:
Making individual calls to the graphics hardware (over the AGP bus) to draw each element is hideously slow. Instead, graphics hardware is designed to take a pointer to a memory region containing a big batch of drawing commands. The CPU fills the command buffer, sets up a DMA on the graphics card, and waits for an interrupt for the GPU to finish processing. As a result of this, OpenGL implementations work the following way: the OpenGL library (in userspace) creates a command buffer from the OpenGL calls the application makes. When the command buffer is large enough (or the application does a flush), it makes a (expensive) call into the kernel driver, which sets up the DMA and drawing operation and returns control back to the app. Notice, that because of the batch-orientation, the performance bottleneck is not in the communication between the application and the hardware. Even if having a client server model makes the flush stage 10 times slower (it's more like 2x or 3x in reality) there won't be a significant performance difference. Given that OpenGL libraries live entirely in userspace, with a small kernel driver responsible for setting up DMA operations and responding to interrupts, there is no reason to believe that putting things "close to the metal" will make things appreciably faster.
A deep unwavering belief is a sure sign you're missing something...
The key issue here, as far as I can tell, is whether the XFree86 guys were correct to kick Keith Packard out.
On the one hand, David Wexelblat has strong words about Keith Packard's actions:
What Keith has done is among the most low-class, unprofessional, and tactless things I have ever experienced in my professional career.
For Keith to blatantly lie to the Core Team about what he was doing is utterly unacceptable.
But what Keith is doing, at least how he's handled it, is just flat out wrong. It's literally dishonest, and morally repugnant. Doesn't mean that there aren't some valid issues to work, or that there is no need for branching, but (a) it remains to be proven, and (b) I'll be damned if I'll quietly accept it being done by someone who is lying to my face.
Whew. On the other hand, here's what Keith Packard has to say:
Some have suggested that this was a secret attempt to undermine the XFree86 project: this was not my intent. I have tried as hard as I can to work within the existing XFree86 structure.
It's hard to think that this is some kind of misunderstanding. Either Keith has been lying, or else he hasn't. It's impossible for us to really decide for ourselves, since the emails containing the alleged lying are not public.
David Wexelblat said:
There is an email thread documenting this. Some members of the BOD wanted to post the email, or quotes therefrom, with the announcement. I and some of the others were utterly uncomfortable doing that. I don't think anyone on the BOD or Core Team would have any issues with an independent audit of this email thread, if there are concerns about the veracity of what I say, but airing that in public isn't appropriate, IMHO.
I'd like to see someone I trust given the job of auditing those emails, and judging whether Keith Packard has in fact been lying.
P.S. A fork might be a good thing, in the end. Keith Packard says he believes his fork can attract more developers and improve more quickly than the status quo. If he can pull that off, we will all be better off. But unless he can clear his name, he may have trouble attracting developers.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
As I can see, the "fight" is between having very flexible, transparently remote thin client GUI and localy optimized fast workstation GUI. First case is X11 and the second are a couple of new projects like SVGAlib, directfb, DDI, GGI etc... But with such a fragmentation or (calling it another way) variety of projects we are still in troubles missing good gfx card drivers (full MPEG-2D-3D acceleration, tv-ins/outs, for all new chipsets and a few or older ones)... So my question is if it's posible to separate X11 from it's drivers and having those as separate project... and then build on them whatever GUI API you want including development of X11... but having hardware driver building effort focused on one project... like you have only one kernel project that takes care of your hardware and many apps that may duplicate their functions...
Just some thoughts anyway...
There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.
Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.
Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?
Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.
That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?
The reality of it is that NT's graphics system and X11 are not all that different. It's just that at a higher level, there is no support for remoting applications in NT.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
There are many possible reasons for that. Maybe you are running Gnome or KDE, for example. But X11 isn't at fault.
Get rid of X and you have a desktop OS that can actually compete. You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead.
The graphics is close to the metal in X11: you send the server a bunch of high-level operations you want it to execute and it does it for you, using hardware acceleration and highly optimized drawing routines. X11 is really like Apple's Quartz in that regard, only that X11 uses a more efficient binary protocol (server-retained vector graphics is an extension for X11).
By your argument, we should all be programming in framebuffer libraries running in user mode. We had that. It's slow, it's unsafe, and it's very inconvenient. Trust me, I have been there.
That's why DirectX is the darling of game developers.
And how many application developers do you know who program in DirectX? There is a reason why we have DirectX/DRI on the one hand and GDI+/X11 on the other.
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
The notion that there is anything "direct" about Windows GUI rendering is silly. And for the Mac, it's even sillier, given that it uses a PDF-based system derived from DisplayPostscript. The world has moved to an X11 model, it's just that most application programmers haven't figured out yet that the world has shifted under their feet.
X11 needs major work, things like transparency, rendering, server-side vector graphics, etc.--and that is happening. But one thing it doesn't need is turn into a pretend-frame-buffer library. The other thing it doesn't need is to have a lot of junk and policy hard-coded into the server (widgets, window management, etc.), like some would-be competitors are trying to do.
X is the single biggest obstacle to Linux becoming a usable desktop OS. It's absolutely fantastic at doing what it was designed to do, but it has no place in a desktop environment.
:) Anecdotal evidence! The very thing that Linux users are always criticised for. What's your hardware? Video card? Kernel version? Distribution? Did you compile X for yourself? You mention "my Linux box" - so is it another box entirely? My anecdotal evidence: X has always outperformed Windows 2000 on the same hardware for me (easy to test since I dual-boot) - an entirely unfair comparison since I've always compiled it from source with lots of optimisations turned on.
.plan as being a "waste of time." It's only recently that it's evolved and improved to what it is now.
X does just fine in a desktop environment, despite being designed the way it is. It runs on a wide variety of hardware from Onyxs right down to my iPAQ, provides more than enough flexibility for window manager authors and works transparently over a network.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
Tsk Tsk
The recent Slashdot story about kernel tweaking (kernel tweaking!) to make X more responsive underscores this perfectly. First you start tweaking the kernel... and then you realize that you have to move the graphics subsystem closer to ring 0 to make the thing work at sufficient speed. The very thing that Windows has been criticized for since NT 3.51 came out.
What's so surprising about kernel tweaking? Any large software layer that uses kernel functions is going to be helped by making those functions run faster. Linux treads a middle road by design here - it's impractical and stupid to move a graphics subsystem into the kernel - but graphics apps could use more speed so you use things like the DRI and kernel tweaks.
You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead. That's why DirectX is the darling of game developers.
Not quite sure what you mean here. X and GL are two different architectures with two vastly different requirements that have evolved independently and only fairly recently have worked nicely together. Not everyone who needs X needs 3d graphics - and the 2D accelerated functions of X are pretty close to the metal anyway. When the performance of GL became an issue that needed to be addressed, a solution was found (the DRI) that didn't need to move graphics into the kernel but still provided an acceptable enough solution for GL users. This is the real world: X is there, it works and it's not going away. GL is there and also immensely popular. Could both be better designed from the ground up to work better and work better together? Of course. But that's entirely impractical. And your comparison with DirectX conveniently forgets that DirectX was a crappy and unusable API for a long time - famously spurned by Carmack in his 1996
--- Hot Shot City is particularly good.
Something that David Wexelblat posted bothers me. I'm sort of confused by his stance, because while he admittedly does not use X, he is at the same time airing his criticisms of it, yet refusing to let Keith Packard fork gracefully. Anyway the bit that bothers me:
"- There is no reason for Core Team matters to be public. This is the
leadership forum, not a public forum."
What is the difference between Core Team members keeping their plans secret and not allowing the public to participate, and Keith Packard keeping *his* plans secret and not letting the Core Team know about them, which he is getting lambasted for? Sort of hypocritical. If the X license is an Open Source license, the Core Team doesn't have any special rights with regard to modification and distribution than Joe Hacker who wants to fork it does. X (X11R6) hasn't changed in a hell of a lot of time (relative to most opens source projects), so what is the purpose of shielding XFree from the public? Some panties need to be untied.
It's 10 PM. Do you know if you're un-American?
...after reading your long message, and also reading David Wexelblat's message, and reading all the stuff that came before, it's pretty clear to me: the X Core Team doesn't want to talk. They don't want outside input, they've deluded themselves into thinking that other Open Source projects are just as closed as they are, and they really don't see where all these outsiders get the right to have an opinion. They ask why you (Keith) didn't open a discussion with them, but then act hostile to nearly everything that is discussed.
I don't know how to write a driver for X, but I do know people. And you're banging your head against a wall as long as you try to work within their system. Good luck with whatever you decide.
My Greasemonkey scripts for Digg &
Hmmm. Someone should clue in the Debian project that they're somehow doing a nonexistent thing by holding regular elections for their leaders.
- pluggable implementations (on Linux alone, there's XFree86, MetroX, Accelerated-X,
...)
- better opportunity for security (though I grant it's not often taken)
- cleaner interaction between applications displaying on the same desktop-- most of the "hacks" won't let applications running in different places share a desktop transparently
For that matter, most desktops released within the last 8 years are so slow and bloaty themselves they can't afford a wire protocol abstraction layer between them and the display driver! Try something truly lightweight, like twm or one of the early incarnations of fvwm with something better than those miserable default configurations, and watch your desktop scream, even with X's supposed weight....when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
I was appalled at how many folks jumped on Keith after the initial /. article. I mean, they were basing their responses on a one-sided tale.
I knew Keith back in the X Consortium days, before anyone was even attempting a serious port to X86 boxes - because they were just too pathetic. Keith has always had an excellent attitude, and cared deeply about the technology, the developers, and the user community.
If Keith has problems with the way something is being handled, only a *fool* would refuse to listen. And that doesn't say much for the folks at Xfree86 who kicked him out, with essentially no notice.
If you've paid any attention at all, XFree86 has been slowing down. Releases get slower and provide less. The driver issue is well documented already.
The X Consortium did far more with far less than XFree86 has been doing the last couple of years, and (IMO) did it much better.
I haven't been involved in XFree86 (I haven't even tried to for several years), so I don't know what the underlying problem is. But I would definitely listen to Keith, and to David Wexelblat, as well.
Maybe, just maybe, we'll get something that works.
[And for those who want to chuck X, well, go use Windows, or suggest a better alternative. To date, I haven't seen anything close. And if you didn't have to live in the pre-X11 world, you have *no* idea what you're proposing - unles syou have that alternative handy.]
i was optimizing my mandrake system for audio use, which meant installing a pre-emptible and low-latency patched kernel source package and recompiling it for my specific cpu / architecture
and that meant X turned from snappy enough to blisteringly fast
what is the problem with X then?
the problem is that the linux kernel is optimized on most distibutions NOT for low latency but for high throughput, due to its being used mostly for server boxes.
so if you actually take the time to either pick a kernel that is suitable for desktop use or compile one yourself (which I duly recommend, I learned a LOT from doing so) you have a high-latency/high-througput server kernel. X being slow has nothing to do with X itself, but on the kernel that is running underneath.
your comment about kernel tweaking is sort of like playing quake 3 on a p66 and complaining that its slow and ID software told you to (gasp) TWEAK YOUR COMPUTER! Unthinkable!
Jag pratar lite svenska.
There are other costs. Encoding/Decoding are the big ones. Context switching is another.
The real question is, if you removed these two sources of inefficiency, what would be the actual speedup in terms of graphics performance. For 3D it was lots, therefore the creation of the DRI to provide direct rendering. For 2D? Best guess is almost no improvement at all; the hardware is not capable of going faster. The only exceptions are bandwidth beasts like video that have been solved in other ways.
If somebody wanted to prove the point they could write DRI/X11 as a complement to DRI/MESA.
I was initially skeptical of Keith Packard's fork but after reading his email, I support it. He addressed the issues that I have been complaining about for years.
KeithP is one of the few people who could make a fork work.
I have a hard time with David Wexelblat who doesn't work on XFree86 and doesn't even believe in it, insulting one of the key developers.
Just as Linux, BSD, SCO and a few others all provide implementations of (more or less) the "UNIX" specification on i386 hardware, there are multiple implementations of the X11R6 standard on i386-based unixes.
If you don't like XFree86, the folks at XiG would be happy to sell you a copy of AccelX. MetroLink systems still offers Metro-X (which was the bomb back in the RedHat 4 days...dunno about now), and if you don't have any money to spend, you can still download, compile and use the honest-to-god MIT/XConsortium X11R6.6 server.
If you want a windowing system that's not based on X11, your options are a bit more slender, but they're there. The Fresco project (formerly "Berlin") looks promising, as does PicoGui.
News for Nerds. Stuff that Matters? Like hell.
99% is an absurdly high estimate. If you remove network transparency, you destroy X for hundreds of users here who use it every single day.
At which point it would no longer be X, in which case you might as well just start a new project (or fork).
It's 10 PM. Do you know if you're un-American?
Well - one thing for sure I think after reading the article..
'Wexelblat shouldnt have anything to do with XFree86 or X anymore..
He very obviously doesnt believe in it anymore - if he ever really did.
This isnt the kind of attitude you want having ANY control over XFree86 or X.
Ex:
"client-server display systems are utterly irrelvent to the majority of real-world computer users.."
are you kidding me?!?
what a dick!
Perhaps Keith Packard wasnt trying to 'subvert' anything..
Perhaps he was trying to start a revolution - that looks like it might be needed.
-- NeTMoNGeR
Well, what do you imagine would be the alternative to "sending commands over the wire"? X11 and NT do pretty much the same thing when you run them locally.
Under NT, the window system lives in the kernel, and graphics is usually drawn by a co-processor. If you call that "local native API" on Windows, be it for 2D graphics or 3D graphics, it enqueues your request in some buffer somewhere, eventually it switches to the graphics subsystem, the graphics subsystem enqueues the request with the graphics co-processor, and eventually, it gets executed and you probably get an acknowledgement.
Under X11, you call an Xlib function and it enqueues your request somewhere. Eventually, the system switches to the X11 server, which gets the request out of the queue, enqueues it with the graphics co-processor, and eventually it gets executed and you get back an acknowledgement. X11 servers on UNIX/Linux usually happen to use unix-domain sockets as the mechanism by which to get the enqueued requests from the clients to the display server (in addition to shared memory for bulk data transfers); that's because unix domain sockets are pretty much as efficient as you can get for this purpose. If NT had invented some mechanism that was faster (and I don't think it has), one could use that with X11; then, you might connect to maybe "super-duper-comm/:0" as your display, instead of ":0".
Note that if you use "localhost:0" instead of ":0", your X11 server will run much slower, because "localhost:0" really does have to go through parts of the TCP/IP stack. But ":0" really does use a very efficient IPC mechanism.
Now, both X11 and NT, and I mean both, give you some additional hooks (DRI, DirectX) that let user-mode programs ask nicely and get some "direct" access to the hardware. But that is obviously not a tradeoff many non-game programs make, and for good, practical reasons.
Note in particular that for 3D rendering, all of this has been worked out and happens transparently under X11 *:
Basically, X11's capabilities and performance are a superset of those of NT's graphics system: X11 handles the local case as efficiently as NT, using shared memory and "direct" hardware and memory access where possible, but falling back to other communications channels when needed.If you're really afraid of all this change, then feel free to continue running X11R5 or something that will keep you back in the dark ages where fonts are jagged and your modelines are fixed.
Just to point out. If you are using the large paper white XTerm monitors from the late 80's early 90's Xfonts look wonderful. PC monitors are generally not 75 or 100 dpi. Take your windows system and change the dpi to an X setting and you'll get the same problems.
The issue with jagged fonts on clients is clients not having the right font sets.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
I don't think the original poster is talking necessarily about moving the whole of X11 into kernel space. I think rather what s/he is talking about is moving the graphic sybsystem into kernel space and letting whatever else draw to that.
Example that I like to use: Darwin/OS X. The kernel contains the framebuffer driver, and provides a CoreGraphics API to applications. XFree86 has even been modified to use this interface on Darwin, with the benefit that it doesn't have to maintain its own drivers, it doesn't have to run as a privileged user, and, quite frankly, it won't blow shit up like it tends to on Linux.
I think this makes a lot of sense. Put the low-level stuff like video *drivers* into the kernel, then export a standard API that people can use. Let Berlin or XFree or an SVGALib wrapper or whatever use those calls on different virtual terminals, and switch between them. Have the kernel keep track of who's doing what, and ignore whoever isn't front and centre.
It would certainly remove the mess, but it wouldn't help the 'other' distros that weren't the ones that got the driver support (i.e. someone writes Radeon driver for Linux kernel, under GPL, someone else has to write one for *BSD).
--Dan
Misconceptions. Flexibility and modularity do not imply performance costs. In fact, they imply the possibility to optimize performance. If something is inflexible, you get what you get, even if you don't need all of it's superflous features. That's an unnecessary performance hit. If something is modular, you're free to mix and match parts to choose the best performing ones.
I think alot of people have the misconception that having more layers between applications and the hardware slows things down. That is not the case. Those formal layers (as introduced by the X11 protocol) are just abstractions of what would have to be there anyway. They end up reducing bloat and memory consumption, as well as saving programmers time, so that every programmer who wants to make a 3D visualization program doesn't have to reinvent the wheel by recoding into his application how to access and manipulate the graphics-card/monitor.
social sciences can never use experience to verify their statemen
People need to stop complaining about X's fonts. Just use the same TrueType fonts you would use on OS X or Windows (some of them are free as in beer). RTF Font Deuglification HOWTO, for heaven's sake. Open Source fonts are a very, very difficult deal, as fonts need to be coherent from script to script, and have a single artistic vision behind them to be satisfactory.
While I agree with most of your post the idea that we shouldn't care about people who don't use KDE or GNOME because they are a small minority is a very dangerous attitude to hold. Linux and XFree for that matter have always been about configurability, even if there aren't that many people who choose to use something else these days they should still have that choice. I mean by that logic we should all be running Windows because that's what the majority runs, right?
I guess my opinion comes from the fact that I'm very happy with BlackBox, run it at home because I have an old machine and KDE or GNOME is just too much bloat for it. But I like it so much that I run it at work even though I have a decent machine. I do want a unified desktop but I will really rejoice the day that my apps look and act the same no matter what window manager I use!
The Anti-Blog
It's wrong to blame X for slowness. The real problem is the incredibly bloated and slow GUI apps and window managers, and possibly the modern GUI toolkits. Blackbox/Fluxbox/IceWM are very fast. Properly made X applications like xfig are very fast. The Mozilla family of apps has something pathologically wrong with it - nothing should be that slow. The Gnome/KDE stuff seems to me just barely acceptable on a fast machine, but clearly it's bloated and inefficient.
Quit blaming X. That's not where the speed problem is. As for difficult and complicated - your right. But mature technologies that properly handle a wide variety of cases tend to be that way.
I'd like to see DirectFB take off. ... ha! I don't know what most people are whinging about. X is incredibly fast on my computer. I run Enlightenment-0.16.5 and Enlightenment-0.17. And yeah I use network transparency a little. That's cool too. And my games run swift as lightning. Direct Rendering is sure working. Is X really that bad that people need to dump it and start again? I'm not convinced.
It looks pretty cool and is quite fast.
Don't know how practical it is or what issues are involved, but anyway if the X ship is sinking, I'm voting for DirectFB.
Of course the X boat is not sinking though.
All those who are sick of X can just stop using X, and see how you go
Quite frankly, the whole stink with XFree86 reminds me very much of ICANN. Technological snobs who won't listen to anyone else, have closed off public participation, aren't transparent, and now are defaming someone who rightly criticizes them. Furthermore, they are blundering. Why should Xfree86 drivers not be modularized? I only have one fucking video card. I don't need to download the drivers for every video-card Xfree86 supports. Xfree86 has also done an atrocious job of integrating the latest drivers from graphics chip corporations, like ATI. Their failure to promptly incorporate these drivers has alienated hardware developers. Why should ATI spend millions of dollars to make drivers for XFree86, if it takes them so long to incorporate them?
The actions of XFree86.org convince me that they want to restrict user choice in the GNU/Linux world, and prevent anyone else from running any X11-implementations other than XFree86. Their refusal to modularize drivers is one thing convincing me of this.
I can not think of any major projects which are as poor as XFree86 in regards to including the community and being accountable to the community. Many of the people within that "organization" are in fact figureheads who don't even believe in XFree86, like one of the founders linked to. If you don't use XFree86 at all, and only use Windows, then imo, you have no business being part of an XFree86 team.
Keith is right to fork off XFree86. He has tried to address his concerns from within the organization, and has been unable to do so. Just like Auerbach. There is only so much one crusader within an organization can do when the rest of the organization is bent on corruption.
XFree86 is proof that even a project covered under a license approved by the OSI and the FSF can be corrupt and non-transparent.
social sciences can never use experience to verify their statemen
It seems to me that all parties involved need to cool down and then come back to the table with a reasonable attitude and work out these issues. Keith has some valid points about the sluggish response of XFree86 development in certain areas, although I disagree with his means of protest. A fork would likely only cause chaos and be detrimental to the cause of unified desktop standards and Open Source acceptance. It is my opinion that there are times when standards and compatibility are far more important than performance and eye candy.
Keith, if you are listening, may I suggest that you formally and thoroughly document your objections to current XFree86 development and provide constructive criticism on how it might be improved? If there are technical complaints, such as relating to performance, perhaps you can write code to prove the need for change.
XFree86 team, if you are listening, may I suggest that a patch tracking feature be added to the official web site? For example, if a patch is submitted to support a new XRender feature but not yet committed to CVS, show this and offer the patch for download right there. As a user, it greatly frustrates me to not have any idea when new features and support will be added and you must admit, the XFree86 release cycle is rather slow. As a user/developer, it would be greatly beneficial to me if I could see precisely where the work is being done. And if extra help is needed in some area, advertise this openly. Relating specifically to driver patches, may I suggest that driver changes be added with far less caution than changes to core libraries? I personally believe that if someone like responsible like ATI submits a patch to support their latest hardware, there is absolutely no need to sit on that patch. Get it out there and get it tested ASAP.
Before I start this, I have to make sure that people reading it actually "get" what XFree86 is. A lot of people who complain about X (in the generic sense) think that it IS the GUI. They see that X shaped cursor and the 50% gray background and think "ewwww!" But what they don't understand is that the "GUI", as they perceive it, is really an environment like KDE or GNOME. Assuming we are talking KDE... you need X for KDE to run and vice-versa. They are interdependent. I can't tell you how many times I've heard people say "I like KDE better than X Windows". With that said:
After reading some of the comments on the OS News board, it seems to me that there are two needs arising out of the discussions:
-Continuing development of XFree86 and it's robust feature set (many of which are sadly lacking in Windows unfortunately)
-A completely new non-networkable direct rendered system (more like the Windows approach)
First of all, to make my case, I will tell you to think of it in terms of a standard console vs. a framebuffer console. They both have their place for two different types of users. In the same way, a system like XFree86 and some new direct rendered display system will have acceptance with certain kinds of users.
I, personally, love XFree86 and all it has to offer. It performs very well for me on a local workstation as well as over my home network and at my place of employ. Displays are easily exported on a per application or per session basis as needed. And with the LBX proxy, I can use it when VPNed into my workplace.
It's VERY flexible: I typically run 3-4 X servers on my workstation and laptop so that I can dedicate full screens for certain things at different resolutions or run under different users simultaneously on each display. (To those in the know: How's that for fast user switching? XP cough cough... :) Ctl-Alt-F8 and you are one user, Ctrl-Alt-F9 and you are another, etc...)
For example, if I am playing a game (Sierra's Lighthouse for instance) under Wine, I like to do it full screen, with no desktop environment at all. Just the game. What's even nicer is that I can actually make the display large enough the Lighthouse isn't a small window with black space around it, it almost becomes full screen. Same thing with Riven. All this while I still have IRC downloading the latest episode of Enterprise in another session as another user. All I need to do to check on my download progress is the Virtual Console key combo.
Now... I will say that if a project starts up to provide a direct rendered system. This could actually be a good thing. It would probably meet the needs of the generic home user fairly well, and remote desktop services could be provided by something like VNC or an RDP clone. I do admit that Joe Average is probably going to have little use now and in the future for X type capabilities. So, this new system should be packed with other "consumer" features. Specifically, the 3D support for games, DVD and MPEG acceleration where applicable and TV in/out support for cards that have such features. A project like this would do a lot to make Linux more palatable to the average consumer. All a distro would have to do then is break down their distros into categories (RedHat for example):
-RedHat "Lite" - A distro for the average consumer that is rypically pre-installed on new systems. No X, no devel tools, no servers, just a very basic OS that allows them to safely get on the Internet, run some productivity apps and play some games.
-RedHat "WS" - As it exists currently. With X (just the direct rendering system that people are alluding to), devel tools, basic servers and some of the enterprise features that power users crave.
-RedHat "Collection" - Capable of installing every distro from one set of disks. You just choose which distro combo you want.
So... don't bash X because you don't understand it. It's a great system with a great feature set. It would be nice to see 3D acceleration networkable or even clusterable though...
Un-news
Reading Wexelblats email where he basically tells people that this is none of their business, is like hearing an echo of the argumentation launched against new bylaws in the FreeBSD project.
If David is not actively contributing to XFree86, he has no business telling anyone how to run the project.
I think the active developers of XFree86, both committer and non-committers, should grab a copy of the FreeBSD bylaws and elect a new core team.
The FreeBSD bylaws are far from perfect, but it would be enough to get started and once the dust has settled, a revision to more closely match the needs of the new project can be made.
Poul-Henning Kamp -- FreeBSD since before it was called that...
XFree is probably not the problem. I'm running debian unstable with kernel 2.65 (preemptible + linus desktop improvement patch), kde 3.1 with mosfets high performance liquid style engine, optimized nvidia drivers and Xfree 4.2.x atm and it is incredibly fast on my machine.
:)
ok, it's an athlon xp 1800+, but it is way smoother that windows XP running on the same machine, and i would describe the "feeled" improvements as follows:
XFree 4.2: can't recognize any speed differences
nvkernel: opengl support, no differences for ui
preempt: avoids glitches on heavy load, a must
2.5.65 kernel: ui stays responsive even on heavy load, very cool.
liquid style engine: incredible performance boost.
the whole kde ui gets rocket fast and responsive after switching to it. just try it!
sure, it's bleeding edge system, but i have no stability problems atm and kernel 2.5/2.6 will be in distributions soon, too...
David Wexelblat is in the Xfree BoD. He's also a core-developer. He flamed Keith Packard because of what he has done. What has Keith Packard done for Xfree recently? Among others:
a) Fontconfig
b) RENDER-extension
c) Xft
d) Work on transparency
What has Wexelblat done recently? According to his owns words:
a) He hasn't hacked Xfree in years
b) He uses Windows these days
c) If he will code something (unlikely), it will be for Windows
d) Only thing he does related to Xfree is to lurk in the core-devel mailing-list
And here we have Wexelblat flaming Packard! Hello!?! Of the two, it seems that Packard cares ALOT more about Xfree than Wexelblat does! He actually works on it and improves Xfree, while Wexelblat plays Myst on Windows! Looking at their recent activities, Wexelblat should just shut the hell up. He hasn't done a thing, who the hell is he criticizing Packard!?
Wexelblat should be kicked out of the BoD and Core and replaced by someone who wants to work on the project and improve it! It's no wonder Xfree has stagnated if there are core-members like Wexelblat who haven't contributed to the project in years! Ironically, it was he (if I remember correctly, could have been someone else as well) who kept reminding that "Xfree is a meritocracy". If it's a meritocracy, why are there useless deadbeats like Wexelblat in Core? Because of their past accomplishments? Maybe Wexelblat was an uber-hacker 10 years ago, but TODAY, he contributes nothing to the project.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
My hardware is a G400 (I like the dual display) and Athlon 1800+. I get virtually identical results. At first I assumed (because a G400 shouldn't be anywhere near a Radeon!) that it was CPU-bound, but then I tried a remote-invocation as well, and got virtually the same results (see below). There's a 100mbit link between the two machines, if that matters...
:0.0
This implies to me that there is a limitation on the number of requests per second that the X-server (irrespective of driver) can do, and that perhaps should be addressed. Either that, or a G400 really is the same speed as radeon 8500... The link to 'tanelorn' is via ssh as well (so it's encrypting and decrypting everything in the protocol stream...)
[simon@atlantis ~]$ x11perf -eschertilerect500
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on
from atlantis.mythology.gornall.net
Sat Mar 22 11:03:29 2003
Sync time adjustment is 0.0537 msecs.
8000 reps @ 0.6795 msec ( 1470.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6850 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6794 msec ( 1470.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.7947 msec ( 1260.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6966 msec ( 1440.0/sec): 500x500 tiled rectangle (216x208 tile)
40000 trep @ 0.7070 msec ( 1410.0/sec): 500x500 tiled rectangle (216x208 tile)
[root@tanelorn denyaccess]# x11perf -eschertilerect500
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on localhost:11.0
from tanelorn.mythology.gornall.net
Sun Mar 23 11:10:28 2003
Sync time adjustment is 1.1608 msecs.
8000 reps @ 0.6954 msec ( 1440.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.7964 msec ( 1260.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6852 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6833 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6844 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
40000 trep @ 0.7089 msec ( 1410.0/sec): 500x500 tiled rectangle (216x208 tile)
One other thing. I *like* X. I really couldn't live without the network transparency - editing files in co-located facilities via ssh with X-forwarding is just *so* much nicer than using 'vi'...
Simon.
Physicists get Hadrons!
This thread is really exciting with lots of agression being worked out. I need to point out that XFree86 has been really fabulous for me. I have used Linux since 95 (Caldera, Redhat, now Suse) and I could not be as productive as I am without it. I have never had a problem with the windows. (I use KDE). I read my mail (kmail), browse the web (Mozilla/Konqueror). But mostly I use xterm/kconsole. I may not be in a majority, but I am one of a sizable number of users (English speaking) who don't experience any of the problems described in this thread. I don't want to go on, but You guys have done a fantastic job. Work it out. As dogbert would say, 'try to separate the personality from the problem'.
You're talking out your arse. The DRI is a direct rendering infrastructure. It applies just as well to 2D as 3D. For example, from the DRI website
The DRI provides a direct rendering path. It's a mistake to think that the only library that could use that path is Mesa. Xlib (aka 2D) currently goes through a slow path; encode to socket to decode to DIX to XAA to DDX to hardware. A DRI/Xlib implementation could go straight from the client to the hardware. Practically you'd only use DRI/Xlib for bandwidth intensive requests. For everything else there's no real value in bypassing XAA.
Your misunderstanding actually highlights a deeper problem. So many people are calling for XFree86 to be scrapped in favour of a direct rendering windowing system. That windowing system already exists and it's called XFree86.
Explorer/shell replacements are in no way analogous to an X server. You might call them "window managers" if you like, but that's as far as it can go.
I agree. In my previous job my main working machine was a Win2k box with PuTTY and a commercial X server installed. It's actually a very nice environment to work in -- I could use Explorer to administer and manage files on my remote linux server, editing PHP code with my favourite Win text editor (ConTEXT) and at the same time using Outlook (not my fave, but the company standard), and develop Win32 code. Best of both worlds. Plus I got to wow all my surrounding Windoze-only colleagues with impressive looking KDE themes!
Without X's network transparency, I'd be upstairs on the linux box half the time, separated from colleagues, and reducing my efficiency.
The only downside -- having to walk upstairs to change CDs occasionally!
However, I also see the need for a slimmer, leaner, meaner X, with a fast (perhaps even kernel-level?) direct rendering system, with less cruft. I have a lowly PIII 550 256Mb at home, and X is a bit of a pig; whereas Win2K's GUI just whizzes along nicely.
I don't necessarily think that network transparency + a fast GUI are mutually exclusive. Surely it's possible to come up with a high-speed rendering and input API that could be controlled remotely via a swappable
I can envisage something like an OpenGL-like pipeline, with a serialised command input, that could be streamed to a specialised hardware accelerated layer on the local machine, or via network to a remote display server? The remote server could afford to be quite minimal in this scenario - a glorified video driver with support for input devices. Surely most of the code necessary for a prototype of this system is already out there?
the number of ppl who wish to kill X while MS is struggling to get remote windows and multi user right. If X was such a disaster, then some group would spring up with lots of backing and take over (think KDE/GNOME). This forking is normal in the course of things. I suspect that Keith's work will shake up X and for a time, there will be 2 projects, but they will either merge back or work together.
I prefer the "u" in honour as it seems to be missing these days.
The AtheOS get_msg_x(), send_msg_x() IPC has a much lower overhead than UNIX sockets, thats for certain. However, that is not the deciding facter in making the GUI more responsive than X; the kernel, appserver and libatheos are all heavily threaded, and the OS is tuned to suit a desktop user (E..g low latency at the expense of more context switches).
;D I would certainly be interested in seeing some real objective comparisions between Message Ports and UNIX Sockets, though.
As I'm posting this from a Syllable box with ABrowse, I can only really say that it feels much faster and more responsive than X. I am subjective and heavily biased however, so please take that with as many sacks of salt as you require
Syllable : It's an Operating System
You have the misconception that just because those layers aren't explicitly stated in other cases that they aren't there. All those layers do is provide a resource for programs to call upon, so that programs don't have to have information coded into them about how to access and manipulate devices, drawing the UI to the screen. Having separate layers allows separate projects to work on optimizing those gritty details, and allows many programmers to ignore them, which is good. If every programmer had to program into his program how to access and manipulate devices, programs would be very large, and take up much more RAM. Hard-drive space would also be wasted. And every programmer would have to reinvent the wheel for no reason.
Think of these separate modular layers as the computational equivalent of the assembly line, which created interchangeable parts, and modularity, and also allowed for the faster creation of products.
social sciences can never use experience to verify their statemen