X Consortium Announces X11R6.5.1 118
cthulhubob writes "X11R6.5.1 is available for download from X.Org. This update has over 200 enhancements, including a large revision to XPrint, the unified X printing service. Press release is avaliable online." It was announced back on the 15th, but it's now availible for download - time to clog some bandwidth pipes!
Re:The REAL Question... (Score:1)
At any rate, the AT&T demands were accepted, so 5BSD became 4.1BSD, what would have been 6BSD became 4.2BSD and so on. There's nothing after 4.4BSD because it was the last new version of BSD released before the CSRG disbanded (with the Lite and Lite2 revisions addressing copyright issues with AT&T).
True see-thru windows (Score:1)
Then, a window would really be a like a window, not like an opaque peice of paper.
BSD Version Numbers (Score:1)
-Dom
Re:Question: (Score:1)
Re:Network code ripped out? (Score:1)
There are some cards where XFree86 has been given full specifications and so the 2D and 3D speed is faster than the corresponding Windows driver. I'm not kidding. Check out the Matrox cards.
Also don't mistake Microsoft. They have some of the world's most talented coders and they work on this fulltime. I wouldn't be surprised if their rasteriser is light years ahead of everyone elses.
Re:differentce between X11R6.5.1 and X4.0.1 (Score:1)
differentce between X11R6.5.1 and X4.0.1 (Score:1)
Forget that... (Score:1)
*That*'s going to be the version to last...
--Lenny
Three DAYS? (Score:1)
Takes me half an hour.
And that includes the time taken to eat the pizza.
--
Re:Software Announcements on /. -- A Plea (Score:1)
Re:Why? (Score:1)
Re:Software Announcements on /. -- A Plea (Score:1)
As the previous two people who replied didn't bother to read what you wrote and tried to slam you for complaining, I'll step in and tell you what X is.
Under Unix, the display for a GUI is handled by a user level process. This program is called the 'X server'. It runs on the small box on your desk, and so it seems unintuitive for it to be a server, but that's what it is. It serves up access to your display to the various programs that want to use it.
One major defining feature of X is that it uses a stream protocol that can go over a network. This means the program that displays stuff doesn't have to be running on the same computer that displays it.
Another defining feature is that X is all about 'mechanism not policy'. It provides a way for programs to put up windows on your screen and things but doesn't say much about how they should act or look. Some people like this, some people don't. I fall in the first camp. It means that there isn't a 'standard desktop environment' for Unix, but it also means that we're free to switch desktop environments without breaking all of our programs.
Too cool! (Score:1)
I wish more focus would be put on projects like this rather than desktop environments at this point,
as these advanced graphics extensions would benefit every project greatly, including the desktops.
I know I'd love to have my X fonts antialiased, antialiased/alpha'd icons, and maybe a translucent GTK theme...
--K
8=^`=`^=D
Re:Maybe not, but they code rings around you (Score:1)
_joshua_
Re:what does the is mean for Xfree86 ? (Score:1)
AFAIK, XFree86 takes the code that the X Consortium has developed and changes it in such a way as to make it x86 native. I'm not sure if that's the way it is.... is it?
Either way it's nice to know that a new version has been released and it's exciting even if it doesn't directly effect XFree86, yet.
Re:differentce between X11R6.5.1 and X4.0.1 (Score:1)
Quick, register slashdotfordummies.org (Score:1)
Re:Maybe not, but they code rings around you (Score:1)
Like you know anything about me...
Re:Maybe not, but they code rings around you (Score:1)
He just wanted to get a rise out of people by saying something completely stupid and inflamatory. Something like that. I've been to the x.org site many times looking for news or interesting stuff. It just never happens. They don't fix typos and as trivial as that is, it fits in with the overall impression the site gives - X is dead, it's all over. Compare this with the hotbed of activity at sites like XFree, UtahGLX etc. Then of course there was the attempt to take X11R6.4 proprietary, everyone should laugh at them for that. A friend of mine said it was a way to stop all the freeloading of those free software types who never had the decency to cough up for the Motif license all X users were supposed to need. Needless to say he and I don't see eye-to-eye on these issues.
Of course since I've only been working full time on X apps for 6 years maybe I don't understand the true subtlety and greatness of x.org's stealth approach, unlike all you X programming demigods hanging out here flaming on slashdot (heh).
Re:Too cool! (Score:1)
Who gives a fuck about transparent windows and menus? Frigging useless eye candy for arts graduates.
Exactly My Point (Score:1)
You hit the nail on the head. A couple of the other posts suggest that I don't know what X is. Of course I know what X is! (I'd have a hell of a time using Linux if I didn't!) But does "X11R6.5.1" mean the same thing as just plain "X"? And what about "XFree86"? Just a couple technicalities that your average, casual Linux user (i.e. myself) might not know by default.
Cheers,
IT
Re:Network code ripped out? (Score:1)
Couldn't a kernel be designed to split the
processes of server and client software between
2 or more processors? For example, one processor
handles all the server requests and another
processor handles all the client requests within
the same system?
If we are SO Client/Server oriented, then is it
not worth having a system designed to where it
embraces that design philosophy down to the
hardware level?
This is already done as far as having seperate computers act as servers to seperate computers acting as clients. But now that alot of software on a SINGLE computer interacts in a Client/Server way on a single CPU... perhaps its time to have
more then a single CPU and or data bus lines?
-Matthew
Why wait? (Score:1)
-grendel drago
Re:Maybe not, but they code rings around you (Score:1)
He just wanted to get a rise out of people by saying something completely stupid and inflamatory.
Re:Maybe not, but they code rings around you (Score:1)
Oh, wait a minute. You were serious?
X11 (Score:1)
Re:Why? (Score:1)
Re:Usable? (Score:1)
Only the hardware specific parts of the X server (the rest of X is not hardware dependant) must be adapted to a particular platform (this is, for the PC architecture, what XFree86 does). The rest is 99% the plain release from X.org.
Also for many HW platforms, support is in the X.org release. I used to get their releases and recompile it myself on Sun, AIX, SGI etc for years.
Seperating the Men from the Boys (Score:1)
Does anyone have a better Slashdot example of where so many people don't know what is going on?
Re:Network code ripped out? (Score:2)
Now this is an interesting point. Putting the video drivers into the kernel (ala GGI/KGI) is a stability gain, but it unfortunately reduces the overall performance.
The reason why is obvious. Not only do you still have the overhead of user space context switches between X clients and the X server, you now also have a kernel context switch for every syscall that the X server makes to the kernel driver. Previously the X server ran as root so it could just diddle on the hardware.
And there's another problem. Modern video cards are not simple framebuffers. They have all sorts of 2D accelerated operations built into their high speed GPUs. In many cases these GPUs are extremely sensitive to the commands you send: it is trivial to lockup a GPU so it won't receive further commands. So you have two choices:
The first method is slower than just putting the acceleration features into the X server and running the X server as root. The second method is what Linus is deathly afraid of: hundreds of video card drivers, each with 10-20kilobytes of acceleration code, all very specific to a video card series, each one of them API incompatible with all the other video card drivers.
Now a good solution is fbcon. The kernel does know enough to initialise the video card and change video modes but refuses to deal with acceleration features. This way it can handle all virtual console changes, even between graphics and non-graphics consoles. This ensures the fbcon driver is small. You also avoid all the common lockups. The X server then lets the kernel handle mode switches, but the X server takes over the GPU and bangs on it like crazy.
It is unlikely GGI/KGI will ever be officially adopted. The fbcon drivers do 99% of what people wanted but with 1% of the code and complexity. It is a difficult problem on UNIX because of the distinction between user/kernel space and because of memory protection between applications. Lesser platforms can cheat and get faster results. To solve this problem neatly on UNIX is hard, and it is taking time, but Linux/XFree86 are slowly but surely getting there.
Re:X Xand XFree (Score:2)
Re:Network code ripped out? (Score:2)
Maybe so, maybe not. But what about those of us that do? Networking is the biggest strength of X as far as I'm concerned. I couldn't do my job without it. I support an application running on a server in the USA from here in the UK. More mundanely, it lets me run apps on a server in our machine room, and display them on my desktop machine. I do this all day, every day. You may be correct in saying that most home users don't need X to have networking capabilities, but corporate users certainly do...
Re:Software Announcements on /. -- A Plea (Score:2)
Better technology to better advance technology. That's what its all about! Slashdot puts the N in Nerds!
Re:Network code ripped out? (Score:2)
And I was talking about the person who said:
who may or may not have been talking about the Windows 9x GDI.
Re:Network code ripped out? (Score:2)
Was the person who spoke of the Windows drawing code having been put into the kernel speaking of the Windows OT drawing code, or the Windows NT drawing code? If the latter (i.e., the move, from NT 3.x to NT 4.x, of the drawing code from, err, umm, a server process to which the gdi32.dll library sent messages to kernel code to which the gdi32.dll library made system calls), then that code isn't 16-bit code, as far as I know - the Windows OT GDI code may, as I have heard, be 16-bit, but I rather doubt the Windows NT code is.
Re:Network code ripped out? (Score:2)
Not true of X as originally envisioned. X is supposed to buffer possibly thousands of calls into a single context switch. This can reduce the context switches considerably below the one-per-call required by a kernel implementation.
The biggest problem with X is the huge number of calls requiring synchronization because the program has to get a response before doing the next call. For instance to draw in red, the program has to send the "allocate a color cell with red" call, wait for the response with the number of the color cell, and then use that number. This introduces a synchornization that can slow it down by several orders of magnitude. There is no reason the interface could not be "allocate a color cell with red and I will call it N from now on" and that can immediately be followed by a "use N as the color call". Some intelligent design like this would solve a lot of X's problems.
Buffers do have a few problems:
Although very fast at throughput, they have latency problems, as nothing is drawn until the buffer is filled and sent. Trying to solve the latency loses the advantage of buffers in the first place. But I think latency problems will show up in the code anyway, so I would prefer that the graphics not try to solve this at all, but concentrate on fast throughput. Also check interactive net games, which have been fighting real latency problems for years, for better solutions.
The other problem is the overhead of filling the buffer and then parsing it. But this is a completely false assumption. The savings of being able to send a pre-filled buffer (ie a canned sequence) with a single call, and the amazing simplicity of sending possibly millions of graphics calls to a coprocessor, greatly outweigh any overhead of buffering.
Re:Network code ripped out? (Score:2)
I think everybody else here equates "kernel implementation" with "lots of different little calls to the kernel" while "not in kernel" typically means "buffered". You may be confusing this with NT where "not in the kernel" meant "many little calls that do 2 context switches" (or as I have argued, with X, which due to bad design has managed to reduce a buffered implementation to a many-call implementation)
Obviously a buffered implementation can be put in the kernel, thus saving a context switch. But this is a trivial savings compared to the savings of millions of context switches that the buffer itself provides. Most of your suggested techniques for speeding up a kernel implementation amount to implementing buffer operations in a user-level library.
But a buffer is not what NT does, and is not what any of the proponents of a "kernel implementation" are thinking of.
Re:Why? (Score:2)
Why does the X consortium produce software that nobody uses? I really don't understand the concept of actually coding a sample implementation that nobody uses.
The purpose of this release is a reference implementation of the new specification. It has no support for the myriad of video cards and so is rather useless for most desktops. But this isn't the point. They're not going to spend their time tweaking video drivers when the real purpose of a reference implementation is a proof-of-concept of the specification.
Releasing a specification without a reference implementation is just a bad idea. I'm willing to bet they revised the specification many times in the process of coding the reference implementation because they found parts of the spec that just didn't make sense or were just plain broken in practice.
Herein lies the whole point of a "sample implementation that nobody uses." It proves the specification is sound in practice. (Or at least, much more likely to be sound.) And incidentally, OMG won't adopt any spec unless it's been implementated at least once for this very reason. This is not wasted effort. It is sound software engineering.
Cheers,
Jason.
Re:Exactly My Point (Score:2)
"Foo version X.Y.Z has been released" isn't nearly as useful or informative as "Foo version X.Y.Z has been released, adding this feature and that bug fix".
If all we wanted to know was that a new version of X has been released, you can fit it into maybe 3-4 words.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com [velocinews.com])
Re:X Xand XFree (Score:2)
These X servers were hardly optimized, but they did correctly implement the server side of the X protocols and all extensions provided by the X consortium.
As for "sample implementations?" Its rare for a vendor to make changes in Xlib or Xt. The only "sample" is the X server. Xlib connects the the server by several means now, depending on the DISPLAY variable. Sockets aren't the only means provided by Xlib. In fact, before "Direct X" meant something to microsoft or to some XML dealer, it was the original name for an implementation of the C Xlib library that overrode the server and drew directly to the screen, provided the DISPLAY variable allowed that.
Rebuild X? Don't be silly. (Score:2)
Installing the NVIDIA drivers takes about 5.
And what are you using to do NAT on NT? That has a big impact on how long it takes...
And as for ALSA... not really an issue if Mandrake detects your soundcard out of the box (like it does for most of them these days).
(BTW. Using the stock kernel doesn't really have all that much impact at all on modern PCs.)
--
Re:Alpha Transparency (Score:2)
Alpha blending lets you make transparent terms, menus, etc. It also allows you to blend the pixels at the edge of text characters with the window below them (a process commonly known as antialiasing)
As for your other concern, have you installed a recent distro on fairly modern hardware? Mandrake 7.1 installed Xf86 automagically for me (on my 3dfx Voodoo3 and NEC monitor)
Re:Usable? (Score:2)
vendors of X software (xfree86, sun, ibm, etc) add support for their hardware and customise/extend X to suit their environments.
in the linux world, xfree does the hardware support end, while the distributions tailor X to work however they have laid their system out.
--
Maybe not, but they code rings around you (Score:2)
Fortunately for the rest of us, most techies spend a great deal more energy writing and fixing code than checking their grammer, spelling, and adherence to linguistic dogma.
While you continue to bitch and moan about our spelling, lax grammer, or bad prose, the rest of us will go on producing software that will continue to be the envy of the Closed Source world.
Who knows, maybe someday, while you're sitting on your ass bemoaning yet another typo, we'll revise the written English language itself into something a little more coherent, purhaps yusing thuh fonetik alfabet thuh wae it wuhs intended in thuh furst plaes, fonetiklee.
Then it will be you who can't spell.
Re:The REAL Question... (Score:2)
It's because as software gets older and more popular, there are fewer changes requiring a complete rearchitecting of the system. This is because such changes become harder both because the software is bigger and more complex, and because such changes usually introduce compatibility problems which a larger user base won't tolerate. It's a natural thing IMHO.
Policy (Score:2)
And we got CDE. (The committee Designed Environment).
No, better to let groups like GNOME, or KDE dictate policy now.
In retrospect, yeah, we needed style dictates, but in 1989, not 2000. We NEEDED a heavy hand to say "All applications shall have a menu, and EXIT shall be under the FIRST menu item." That randomness still haunts us (xv, WordPerfect, FrameMaker, xterm, etc EACH have different ways to exit). The big change is that the Vendors are now on the sidelines. Sun has Pissed DEC out of existance, SGI is wallowing in a ditch, IBM has begun to figure out what happened. HP, well, they still have HP-UX.
In the meantime, the Open Sores guys have taken the reins from them and started to DO something to counter Windows. Frankly, I trust them more than [vendor of choice here].
gnome/kde efforts have dealt with a lot of this quite nicely, without the brutal overhead of CDE type things. Fine. And about time. Let the best interface win.
X11R6.5.1 mirror in Australia (Score:2)
New Zealand as the x.org sites appear to be very
full..
From AARNet's Mirror Project:
ftp://mirror.aarnet.edu.au/pub/X11/R6.5.1/
http://mirror.aarnet.edu.au/pub/X11/R6.5.1/
-jason
Re:Quick, register slashdotfordummies.org (Score:2)
XSpell (Score:2)
X Xand XFree (Score:2)
Re:Just out of curiosity... (Score:2)
Re:Software Announcements on /. -- A Plea (Score:2)
I think he knows what X is, guys, I sure do, but I have absolutely no idea why X11R6.5.1 is important to *me*. It would have been nice if the article reported on what the software changed, why it was deemed to be worthy of an announce on SlashDot instead of just freshment, why I should care enough to download it, that kinda thing.
Y1 (Score:2)
Re:Network code ripped out? (Score:2)
Re:Three DAYS? (Score:2)
Re:Alpha Transparency (Score:2)
BTW> Slackware kicks ass. Getting networking and NAT configured in a few mintutes was awesome. I never did like SysV scripts.
Re:Why? (Score:2)
As for NT not using memory, qualify THAT! And your concept of memory use is twisted. The SYSTEM should NOT use memory just because it's there. The system should leave as much memory as possible for the APPLICATIONS. I could care less if GNOME didn't exist, I'm running the applications not the DE.
Re:Network code ripped out? (Score:2)
Usable? (Score:2)
Re:Network code ripped out? (Score:2)
just for diehard be fans.
>>>>>>>>>>>
BeOS is NOT an orphaned product. Let's see, you've got the upcoming network environment, the new accelerated OpenGL implementation, Opera 4.0, and Java2. Oh yea, Be has TOTALLY abandoned BeOS. (And none of this is vaporware, OpenGL and the networking environment (BONE) are deep in beta, and JavaSE is already running on BeIA.) Also, the shift is designed so any improvements to BeIA can be quickly rolled into BeOS. Seeing as Be has just made some deals with companies like Compaq, I'm thinking they are far from dead.
What should happen is we should take the good parts, and not so much source but the ideas, of BeOS and the Be API and incorporate them in the toolkit(s) for X and the kernel.
>>>>>>
Oh yea, add yet another toolkit to X and make it even MORE bloated!
The only big advantage BeOS had over Linux IMHO was the fact that it came with a journalling FS out of the box.
>>>>>
Sure that's the only advantage. The 3 millisecond latencies (BTW that's not hype. Read the BeNews article about the hardware company that shifted from using a proprietary OS to BeOS for their mixing hardware) great handling of video, easy API, and fast GUI are no big thing. Not the mention the utter "zen" of the user-interface. When I see something as cool as Cortex on another OS I'll be impressed.
These days all my servers run off of ReiserFS.
>>>>>>>>
ReiserFS STILL doesn't have database capabilities (it's planned.) BFS has had database capabilities for years.
I just downloaded the CVS tree from SGI XFS server, going to give it a spin on a spare box next week. Now if someone would produce a pervasively multithreading toolkit for X I'd be all set.
>>>>>>>
Great, yet another X toolkit! Really, do you think some new APIs and another toolkit are going to defeat the 20 million lines of code and 30 years of UNIX baggage (not all of it bad, though) that make up the average Linux system. Face it, Linux may be a great system, but in terms of sheer speed, it still doesn't compare to BeOS. I don't use BeOS because I'm a fanatic. I have both Windows and Linux (Slackware 7.1, a man's distro) on my system. I don't use BeOS just for the hell of it, I find myself being more productive in it. I like the API, the user interface, and find the applications on the platform to be very original, if a little lacking in features. I like the tight integration between the CLI and the GUI. I like the fact that the workflow is so fast, and that apps are so easy to install. For example, I just downloaded Jikes for BeOS. The installed automatically configured BeIDE for it, and all I had to do to uninstall it was delte the folder.
So fine, critize BeOS for what it lacks. I'm totally okay with that, in fact I'll point some stuff out for you right now.
A) It doesn't expose hardware acceleration comparable to what DirectX does.
B) It doesn't have as nice of a joystick API as DirectInput.
C) I lacks a decent web-browser.
D) Replicants are weak compared to systems like OLE or OpenDOC.
E) It lacks an object model.
F) Navigating multiple browser windows is awkward.
Complain all you want about valid problems. However, don't belittle it by saying that Linux is just a toolkit and an API away from bettering it.
Re:Why? (Score:2)
Re:Alpha Transparency (Score:2)
Re:Network code ripped out? (Score:2)
Re:Network code ripped out? (Score:2)
virtual 8086 mode. In this mode, there is no distinction between user and kernel mode (or ring 3 and
ring 0 in Intel-speak), because this functionality didn't exist until the 386, and the Windows 9x GDI
has never been a client/server architecture, so talk of 'moving GDI into the kernel' on Windows 9x is
complete and utter nonsense.
>>>>>>>>>
I've been duely chastised. However, I do have to point out that during Window 95's release, more of the GDI (which is almost all 16 bit) was rewritten in assembly. This was a major selling point of Win95 against NT. As for being in the kernel, the Windows 95 architecture is so confusing it might was well be. This is how I understand it, correct me if I'm wrong. Most of Windows consists of a set of DLLs (including the GDI) that are mapped into the address space of the application. I consider anything in these DLLs to be more or less in the kernel. However, a call into the GDI causes it to switch to the Win16 VM which runs it in V8086 mode. My question is this. Isn't the Win16 VM running in protected mode? As I recall, the real mode version of Win 3.1 really didn't work very well.
2. The NT GDI was designed as a client/server architecture, and contains no 16-bit code whatsoever
(or thunking, except when 16-bit applications are run, and their 16-bit calls are thunked to 32-bit
Win32 APIs). On pre-4.0 versions of NT, when an application made a graphics API call, this would
invoke an LPC (local procedure call) into the CSRSS (Client/Server Runtime Subsytems) process,
which would then carry out the graphical work. With NT 4.0, the GDI was restructured, and more of
it was moved into kernel mode (the video drivers, of course, have always run in kernel mode, since
they require access to the hardware). The impact of this change is often exaggerated, ignoring the
simple fact that a CSRSS crash would bring down a pre-4.0 version of NT anyway. Similarly, an X
server crash on UNIX brings down all of the applications which were being run in the X session, and
often the system as well. In other words, the effect is largely the same. The exception would be
UNIX servers which are also used as interactive workstations, in which case an X crash might not
bring down all of the services which were running. Of course, using a system both interactively, and
as a critical server, is an extremely bad administrative decision.
>>>>>
I was never talking about NT. However, the moving of the GDI did have a large impact. Graphics performance improved quite a bit.
3. Client/server architectures for graphics will always be slow. The fundamental issues are:
(a) A client/server architecture requires several context switches for each call to the graphics system
(at least client -> kernel -> server -> kernel -> client, often more, since the server frequently has to
communicate with drivers running in kernel mode), where as a kernel-mode architecture requires
only two (client -> KM server -> client), and a kernel-mode server can communicate directly with
kernel-mode drivers without any context switching.
>>>>>
Not entirely true. For example, the BeOS uses a buffered graphics API. Graphics calls are batched and sent when the buffer is full. So the result is a context switch into the kernel to send the messages. When the graphics server is next scheduled, it will carry out those messages. BeOS uses a dual-mode graphics driver API. The majority of driver functions run in a user-space module loaded by the graphics server (called an accelerant.) The only time the server has to switch into kernel mode are to handle shared resources and do interrupt handling. Everything else (including primative acceleration) can be done through the user-mode module. In practice, this method is pretty damn fast.
Finally, the Windows GDI is not 'notoriously slow'. In fact, the excellent graphics performance
offered by Windows in the early/mid 1990s, based on the hardware acceleration of GDI routines, is
one of the things that attracted me to the platform (coming from UNIX and Macintosh, which still
used simple frame-buffer architectures). MacOS and XFree86 now take advantage of this GDI
acceleration to some extent (since many of their primitive routines are similar to, or the same as,
the GDI routines which the hardware implements), but Windows probably still has an edge in this
respect, since it's what the accelerators were and are designed for.
>>>>>>>>>>>
The GDI IS notoriasly slow. Coming from a game-programming POV, you'll notice that the use of the GDI is banned for everything except rendering text into bitmaps for later blitting. In fact, I've done some tests between the GDI and the BeOS graphics system and the BeOS graphics system tends to win.
Re:Alpha Transparency (Score:2)
Re:differentce between X11R6.5.1 and X4.0.1 (Score:2)
Why? (Score:2)
Re:differentce between X11R6.5.1 and X4.0.1 (Score:2)
Re:differentce between X11R6.5.1 and X4.0.1 (Score:2)
Re:Why? (Score:2)
B) The Linux+KDE Beta +GNOME=WinNT point IS valid. I think you agree that the base components are equal in both cases. The only services running on both are NAT, and I made sure to compile a custom, modular kernel with only the necessary items. (The kernel weighs in at 550K) I even made sure to not load PPP and SLIP since I'm using DSL not dialup.
The KDE Beta2 is needed because it is currently the only environment that can use embeding and component technologies throughout the system. Since these services are built into WindowsNT (in the form of OLE and COM) they are necessary. Comparing NT to a lighter weight environment like FVWM or even plain Enlightenment wouldn't be fair as NT would have many more features. Since KDE 1.2 doesn't offer KParts, and GNOME 1.2's component services aren't totally complete, KDE2 Beta was the only choice. Given the fact that KDE2 is in very late beta, I think it is an appropriate choice. (Actually, KDE is needed for another reason. KDevelop won't run without it.) Now GNOME. GNOME is necessary, because there are several important applications that require GNOME. In NT you can neglect OWL, Qt, and Cygwin because no important applications use them. You can run 99% of all apps without them. The situation, however is different in Linux. Since GNOME has more than 50% of all the important "DE aware" applications, it has to be a part of the comparison. You might think it is unfair because of the duplicated code, but those are the realities of two incompatible DEs. (BTW I didn't count Mozilla in the mix. I can't stand Active Desktop. That gives Linux an advantage because IE takes less memory than Mozilla or Netscape.) Under these circumstances, Linux takes up more memory than WindowsNT 4.0.
Re:Rebuild X? Don't be silly. (Score:2)
BTW> The stock kernel on RedHat 6.1 is NOTICIBLY slower than a custom kernel.
Re:Network code ripped out? (Score:2)
Re:Network code ripped out? (Score:2)
Re:Alpha Transparency (Score:2)
Re:Alpha Transparency (Score:2)
Re:Network code ripped out? (Score:2)
Re:Network code ripped out? (Score:2)
Re:The X Consortium has released? (Score:2)
www.x.org [x.org] has more details.
As for the original X developers, Jim Gettys has been mentioned recently on
Still no alpha support :-P but no suprise. (Score:2)
What about 3 years from now? Will we all be using Berlin? Will there ever be an X12? X11r7? Hell, why not start over and call it Y1?
Just some thoughts.
Re:Why? (Score:2)
Your NT box after booting runs nothing other than its desktop (assumption).
Your Linux box after booting runs a bunch of background servers (assumption) and a desktop AND a BETA desktop.
It would be a huge achievement for the KDE team (and slack and gnome to a lesser degree) if your linux box consumed more memory at startup. Also, don't forget that linux/*nix regards memory as a valueable resource to be filled (make sure we're using it cause we have it) where Windows regards memory as a precious resource not to use (make sure we don't waste any cause it's so valuable).
IMHO, either don't make comments like that OR qualify them (with a link even) to describe what it is your really found, I would love to see good figures whoever wins that battle.
Nonalpha AA algorithm (Score:2)
Maybe you'd like to show us a non-kludge-riddled antialiasing algorithm that doesn't need an alpha channel?
This is how I used to do pseudo-AA text on an old paint program on a Macintosh computer:
<O
( \
XGNOME vs. KDE: the game! [8m.com]
Re:We will combine your distinctiveness with our o (Score:2)
Just out of curiosity... (Score:3)
Just out of curiosity, Hemos:
You download it... and what exactly do you intent to do with it? I mean, this is the sample implementation, and even if some stuff there is not present even on the XFree86 4.0 tree, unless you intent to merge the changes between R6.4 and R6.5 with XFree86 overnight... well you get the idea...
The REAL Question... (Score:3)
Is this TeX syndrome, where the version number asymptotically approaches some ideal number? X is already past 2*pi, but I'm sure there's a constant they're working toward...
-grendel drago
Re:Question: (Score:3)
"X WindowsThe first commercial release of X Windows was X10.4 in 1986, and was the basis for some commercial applications. The next release was X11R1 in 1987, followed by X11R2 in 1988. Version 11 was a complete windowing package that outperformed X10 in its speed, flexibility of features, and styles for multiple screens. X11 and later versions have become the de facto standard GUI for UNIX systems and are, therefore, the focus of this chapter."
Thus, X1-9 were apparently inhouse releases (just like the first several UNIX releases.)
Re:Network code ripped out? (Score:3)
A) It really wasn't built to take good advantage of powerful client machines. XFree86 has really helped in this regard with the XFree4.0, but the architecture is set in stone and there is only so much they can do.
B) It wasn't designed to take good advantage of hardware acceleration. Again, XFree has really helped with the rewrite of XAA, but they can only do so much.
C) There are many protocol limitations. For example, the reason they are having so many problems with anti-aliased text is that X only sees a font as a monochrome bitmap. Also, TrueType fonts are a bit of a hack on X, and general font support is poor. These are things about the protocol that just have to be worked around.
D) It seems that the API is pretty inefficient. As somebody pointed out to me a while ago on
However, the client server model really doesn't seem to be THAT big a problem. It is probably largely due to poor design decesions. For example, the Windows GDI is notoriously slow. It is largely 16 bit code that needs to thunk in every call to it. However, MS managed to get it to a decent speed by rewriting parts of it in ASM and putting it into the kernel. The GDI is actually just a DLL that is loaded by the client application. There isn't a server there. Despite these hacks, the GDI is still slow. (Though not slower than X.) The BeOS API, however, uses messaging and a client server model. Ask anyone, they'll tell you that it's the fastest GUI around.
The X Consortium has released? (Score:3)
Seemed a little odd at the time that the work on Broadway was just finishing up (or was done) and the X Consortium went out of business.
Of course, looking at the splash Broadway has made, it's not surprising.
Gosh, is anyone using Broadway out there? It seems like a good idea. Extend your X apps to browsers and still have the native X application. From what I've heard, it's slow, hard to use and immature as a technology.
Anyway, back on topic here. Who is doing this work for The Open Group and why? Is this being driven by the Unix vendors needs for new features?
-Jordan Henderson
Re:differentce between X11R6.5.1 and X4.0.1 (Score:3)
Other than X hackers, most users are best waiting for their particular X vendor (XFree86 for most Linux/*BSDs, Xig for some, Sun/IBM/Compaq for users of their Unixes) to incorporate the X.org
changes into their release.
As for license differences, the licenses are basically the same, with just the copyright owners
changed.
Re:differentce between X11R6.5.1 and X4.0.1 (Score:3)
The X Consortium defines the standards, makes the sample implementation, and then XFree86 rolls it into their implementation (at some point). Or, of course, maybe Xi Graphics, or one of the other commercial companies, will also create their commercial versions.
If you look in your directory hierarchy, under /usr, you'll see that, even though you have XFree86 V4.0.1 installed, the directory is called X11R6.
----------
Re:differentce between X11R6.5.1 and X4.0.1 (Score:3)
It's unfortunate that so many people are unclear on the difference between X and Xf86, and even what X really does.
Question: (Score:3)
Re:differentce between X11R6.5.1 and X4.0.1 (Score:3)
I can see where it's easy to confuse X Consortium releases with XFree86 releases, since most books, HOWTO's, FAQ's, etc., don't touch this topic at all.
I have only the vaguest ideas of what those entities do, but I'd love to know more.
Modifications. (Score:4)
Re:X.Org can't spell! (Score:4)
WWJD -- What Would Jimi Do?
Re:Network code ripped out? (Score:5)
Experts in XFree86 have already tried using other transports to see if things improve. This has in the past included a shared memory segment between the clients and the server. The surprise result was a reduction in speed. It seems that Linux has such a good implementation of UNIX domain sockets that doing it all by hand is an overall loss.
Removing the transport altogether is impossible. This is not an X consideration. No matter what windowing system you have, at one stage you need to pass messages between the clients and the X server, because they are not the same binary and they do not run in the same address space.
So ignore the pipe. The pipe isn't the problem. A real problem is context switching. Because the X server and the X client both run as user space processes the kernel must alternate the execution between client and server. This increases the latency of operations and time is wasted doing the context switching.
One solution that can result in a speedup is to put the X server into kernel space. This saves you one redundant copy and two redundant context switches. It also means your system is now as stable as Microsoft Windows.
The compromise solution is to put some highly timing critical code into the kernel but keep most of it in user space where it belongs. This is the technique that the DRI has used. It means the client can render directly to the hardware while still maintaining a balance between security and stability and clean design.
SUMMARY: The real performance killer of X is not the pipe. Changing the transport has already been tried and has already failed.
Re:Still no alpha support :-P but no suprise. (Score:5)
Re:what does the is mean for Xfree86 ? (Score:5)
Thats what they did originally. Lately, they've started applying useful patches to the clients and libraries from outside sources that may or may not every get into TOG's X(tm). For example, XFree includes the xterm patches from here [clark.net], added the essential XPM library, and beefed up Xaw to make it almost usable. Check out the release notes [xfree86.org] for more details.
Even more recently, they've started to tackle the key features that hold X back, like font handling and transparency. Check the mailing list archive [xfree86.org] for the most recent developments.
Software Announcements on /. -- A Plea (Score:5)
Thanks,
IT
Re:X Xand XFree (Score:5)
What we have here is a sample implementation, and not something that you want to use on your workstation. This will become useful once various releases of the X window system incorporate it, and then moreso when applications and toolkits are written to work with it.
Re:Question: (Score:5)