Slashdot Mirror
X Consortium Announces X11R6.5.1
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!
In the BSD case, the 4.x numbering scheme started because AT&T objected to the name 5BSD, on the grounds that it would be confused with UNIX System V. In truth, they were probably (and correctly) afraid that BSD would have moved on to 6BSD before UNIX System VI came into being (it never did), making BSD appear to be a `higher version than AT&T UNIX.
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).
Then, a window would really be a like a window, not like an opaque peice of paper.
The BSD version numbers were legally required to stay at version 4.something. I think AT&T made this requirement in the early 80's when they started selling System V (because bigger version numbers are always better :-). I don't have a link to back this information up though. If somebody could provide that, I'd appreciate it.
-Dom
Yes, there really were 10 complete versions before X11. There haven't been significant changes to the core since X11 Release 1, so the major version hasn't changed in a while. The changes have mostly been in the extensions (eg, XPrint is the big change for R6.5.1).
Quite often because the specs released to XFree86 are incomplete. An example would be the NVIDIA 2D driver. The official NVIDIA 2D driver uses DMA and AGP and is 80% faster than the XFree86 NVIDIA 2D driver which doesn't use DMA or AGP.
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.
how is this relevant to X?
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
Ok, what's the difference between this new X11R6.5.1 and the X11 4.0 that was just released earlier this year? I'm not as interested in licensing differences as I am in features. I'm quite confused now. What do I get from a Download at x.org and what do I get at a download from xfree86.org/
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
I'm still holding out for X11R6.5.6.32L27.2.34a++
*That*'s going to be the version to last...
--Lenny
Wow.
Takes me half an hour.
And that includes the time taken to eat the pizza.
--
Peter
How can you not know what X is? I would think anyone who read this site often enough to have an account would know how important X is to the Unix community. Yes, this is a software release announcement, but it's not just a new release of some unknown console game. X is important enough to be announced here.
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
I think it's a little more involved than just adding a few more lines of code and releasing. The sample implementation they release doesn't have to include all the video drivers that people would need, it doesn't have to be optimized (Which would probably take a lot of time), and they don't have to support it. They probably realize that all the above stuff is being done by XFree86 (Who would probably still do it even if X.Org did it themselves... liscencing issues and all), so why bother duplicating the effort that they might not be able to accomplish? I'm not sure how many people they employ down at the Open Group, but I'd rather they spend their time working on what they can add for X11R6.6/X11R7/X12 rather than writing drivers and replying to bug reports.
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
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.
Need a Python, C++, Unix, Linux develop
Now that's a pretty nifty project!
;D
.~.
/V\
// \\
/( )\
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
Hmm... sorry to bring this up, but I couldnt resist. What you should have said is "We don't have to spell correctly"
_joshua_
If you actually examine the RELNOTES.TXT file on the X.org ftp site, apparently you can build an Xserver for XFree86 so I think I'm just going to download the source and try just that.
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.
{justin.filip | jfilip AT gmail DOT com} {http://jfilip.ca/}
Oh, and get some good lawyers....
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Like you know anything about me...
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).
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*.
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
Power corrupts. PowerPoint corrupts absolutely.
What about SMP processors?
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
Hey, you can get netatalk-1.23.35-beta-2-asun34... (I'm probably exaggerating, but that's the latest release, I believe.)
-grendel drago
Laws do not persuade just because they threaten. --Seneca
You have just been trolled.
He just wanted to get a rise out of people by saying something completely stupid and inflamatory.
I refuse to reply to this message because you didn't put two line breaks after my quote, and you quoted using bold.
Oh, wait a minute. You were serious?
Ok, can somebody educate me as to where this actually fits in with XFree86? Is this just a release of X libraries? Or is this a non-free version of X that is competing with XFree86? Where does it fit in? Can I download it, recompile it, and then stick it into my XFree86 install and magically gain new features?
It's 10 PM. Do you know if you're un-American?
Linux: The OTHER OS that's bloated as Windows.
A deep unwavering belief is a sure sign you're missing something...
Those releases are the reference implementation, which is taken almost "as is" by most vendors.
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.
Does anyone have a better Slashdot example of where so many people don't know what is going on?
Hey, thanks for all the good information.
Boy, I wish I could take that informative point someone gave me and reassign it to your post.
I don't know what's informative about my post...
(I really should have self-moderated with "No Score +1 Bonus".)
-Jordan Henderson
I downloaded it and tried to build on Sun/Solaris; but way down in programs/Xserver/PEX5/ddpex/mi/level{3,4} there are files which reference PEXOCPickXorg, which I find in no files in the source tree. I guess that's what I get for grabbing it so quick.
Althought I am sure someone else has this as well, I just think there are more important things that hold X and XFree86 back like configuration (hey if MS can figure out what you have installed automagically and it's abilities, XFree86 should too! as far a X goes anyway. I have better things to do then edit modelines and config files.).
Gorkman
Why do people think we became coders? We don't have to spell right, we just have to spell consistently.
Reality has a conservative bias: it conserves mass, energy, momentum...
If my assumptions are wrong, fine...that's why I stated they were assumptions allowing you to correct me.
Running two desktops however does not an equivalent system make, I don't care how you try to justify it. If you add some programs that require a pre-loaded desktop environment to your NT (doesn't KDE run on NT) you will start to get an equivalency.....just because Linux allows you to tweak your system to use more memory does not mean that it takes more memory. Really I just think it is an unfair example you give...remove the KDE and tell us your results, I would believe that NT could still come out with lower memory usage, thats why I wrote the above disclaimers. Don't flame me back for questioning the validity of your statement, correct me (as a lot of your post did) and try to redress my issues. If you think KDE Beta+Gnome=NT equivalence then we'll just have to agree to disagree. If you can present some more arguments as to why you feel your situation is valid then fo gor it.
BTW I feel my memory usage ideas are fine (now the validity of my statement vis-a-vis a just finished booting system may be invalid) however I feel that the idea of keeping your memory free for applications that may be started is stupid, if you can write something else into the memory that may speed up subsequent operations then why not if it can be swapped off if an application needs the space?
Never underestimate the dark side of the Source
Man, got flamed for helping reduce FTP downloads. lol
Sorry it took you 2 seconds to scroll down the list.
That's the problem; Microsoft blames drivers for much of their instability. They're probably right in most cases. Still, considering that our drivers aren't written by the people who have full access to the hardware specs, would we fare any better? Probably worse. It's better to keep it out, so that way bad drivers can't bring down the whole system.
Those who can't do, teach. Those who can't teach either, do tech support.
Louis Wu
"Where do you want to go ...
According to the RELNOTES.TXT (Release Notes), 5. Supported Graphics Devices This release includes the necessary device-dependent support to build a native X server for the following platforms: HP-UX: Xhp Compaq Tru64 UNIX: Xdec on DECstation 3000/400 (Alpha) with PMAG-B SunOS/Solaris: Xsun -- see the Xsun man page for supported cards XFree86: See the XF_* man pages for supported cards So apparently, it *is* possible to run it on top? along with? instead of? XF86. I don't have the bandwidth nor the space, but I would like to know if any of the changes that the XF86 peeps such as the modular Xserver made it into X11R6.5.1. Any one take a peek at this yet? Also nice is that dynamic resource modification now happens at the Xtoolkit layer, so you don't need to link in EditRes (or resource yer resources file). From my casual read of the release notes, this is a fairly minor update, with bug fixes primarily. Though I wished they *stated* what those bug fixes are outside of the tar files. Cheers, edward.
>Linux: The OTHER OS that's bloated as Windows.
I had to bite:
I guess this 1.44 MB distro doesn't count:
http://www.linuxrouter.org/
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
There are a few basic parts of X. There are the X libraries that are used by X client software. And then there is the X server. The X server is what talks to your display hardware. The clients talk to the Xserver using the X protocol. X.org's job is to develop those libraries, and define the protocols and most of the extensions to the X server. X.org maintains some X servers for testing purposes.
XFree86's job is essentially to write an Xserver that can talk to PC video cards. And workstation venders write X servers for their own OS's. But the hardware independant part of the Xserver code is provided by X.org . The X libraries we use are almost unchanged from that provided by X.org . That's how there is compatibility between Sun and Linux X programs. However, XFree86 does incorporate additional patches because X.org takes too long to do anything. And XFree86 does write new X extensions and is in the process of redoing the rendering model. In theory, X.org should have been the ones to do that. But the Open Group lacks the ability and/or will to innovate. Graphics innovation is now driven by the PC market, so it is PC UNIX developers that advance the GUI for UNIX.
The build problem you describe was caused when X.Org filered the final source to replace rcs keywords $Id: to $Xorg: so that the released rcs id would be preserved at the user site.
e r.c
e rse.c
c t.c
Unfortunately three (3) files resulted in incorrect substitutions as you describe.
Quick fix is to do the following:
1) change PEXOCPickXorg to PEXOCPickId in:
xc/programs/Xserver/PEX5/ddpex/mi/level3/miRend
xc/programs/Xserver/PEX5/ddpex/mi/level4/miTrav
2) change Xorg: to Id: in ErrorF format strings in:
xc/programs/Xserver/PEX5/ddpex/mi/level4/miStru
A public patch will follow.
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.
I was under the impression that this would be a fully functional Xlib (probably using BSD sockets). I don't know for sure because I've never actually downloaded their 'sample implementations'. Of course they couldn't make an Xserver (except maybe an Xnest type deal). The question of *why* you would want to install it is interesting, considering your X server won't support any of the new extensions, but I'm skeptical as to just how much it would break.
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...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
X11R6.5.1 is important. It will help us to read slashdot in bold new ways, where non X users have not gone before. Its lightyears ahead of other GUI's, allowing for quite some time to remotely run X applications from across the universe directly on your computer screen.
Better technology to better advance technology. That's what its all about! Slashdot puts the N in Nerds!
And I was talking about the person who said:
who may or may not have been talking about the Windows 9x GDI.
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.
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.
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.
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.
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.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
A kernel rebuild on my machine takes about 10 minutes. (PII 350, 128MB RAM)
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.)
--
Peter
it's a complete implementation, with with little or no hardware support.
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.
--
I absolutely refuse to pay any attention to anything X.Org has to say until they fix the typo on this page
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.
The Future of Human Evolution: Autonomy
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.
Need a Python, C++, Unix, Linux develop
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.
I've put a mirror up for users in Australia and
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
availible? The sound of avian speech?
This may be a really stupid question, but if I compile and install this over top of my Xfree86 4.01 installation, how badly will I have ruined my system?
you can recompile your code with the new Xlib stuff right away..of course the features of the new stuff will not show up if it requires too many changes to the X Server...in most cases the new stuff works even with the old X servers...just make sure you upgrade your X libraries and headers.
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.
..don't panic
Although I think someone is working on the Y-windowing system. I think that the first release should be Y_0 (Y sub 0). Which in science is pronouced "why not."
Disclamer - Opinion of Person
Huh? What phsychology? Development for Be does NOT suck that bad. BeOS IS good enough to attract good programmers. What the hell are you talking about? My point is instead of writing yet another GUI toolkit for X, go help fill in the gaps in the BeOS software line.
A deep unwavering belief is a sure sign you're missing something...
Your assumptions are wrong? Why the hell would I compare a tuned desktop to and untuned one? (Why would I use Slackware if I had an untuned system?) The only things running in the background are the things I can't kill. I don't even run atd. As for running two desktops, that is to represent the fact that you HAVE to run both or else not be able to run all the applications. (BTW, the NT machine actually has more services running, though I've got NAT on both, NT is acting an ftp server for my network, and also has some rpc services that I don't start in Linux)
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.
A deep unwavering belief is a sure sign you're missing something...
Actually, these days local stuff is done through sockets. And X uses shared memory as well.
A deep unwavering belief is a sure sign you're missing something...
I don't really understand the way X is released. Is the thing the X group releases a sample implementation or what? Is is actually a usable product?
A deep unwavering belief is a sure sign you're missing something...
Why? BeOS is an orphaned product. Be has shifted focus to the Internet Appliance space. BeOS is
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.
A deep unwavering belief is a sure sign you're missing something...
I'm talking FUNCTIONAL distribution. The Linux kernel is a work of art, and that is more or less what that 1.44 MB distro is. The core part of BeOS (which includes all the servers, the windowing system, tracker, etc) is about 16.5 megs (700K kernel, 3.5 megs servers, 2 megs tracker, 10 megs for libraries, everything from OpenGL to C++ and C libraries) If you can find a functional Linux distro that has the GUI, a desktop environment, runs any available Linux app, and fits in 17MB, I'd like to see it. As for my comment about bloat, it's true. My system, Slackware 7.1 with GNOME 1.2 and KDE 2 Beta3 takes up more memory at startup than WindowsNT 4.0
A deep unwavering belief is a sure sign you're missing something...
I was talking about the Windows95 GDI.
A deep unwavering belief is a sure sign you're missing something...
1. The Windows 9x GDI contains a lot of assembly code, including some 16-bit code which runs in
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.
A deep unwavering belief is a sure sign you're missing something...
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. Coding a sample implementation is not that much easier than coding one releasable one. So why do it? Why not just do a little more work on it and release it as a usable product? It would speed stuff up too. Instead of waiting for XFree86 to roll in the changes (which, probably won't happen for several months) a new implementation would be usable when it is released.
A deep unwavering belief is a sure sign you're missing something...
Actually your missing an obvious point. Client/server relationships make it much easier to asynchronos calls. Fill a buffer, send it off the the graphics card and get on with our processing. Since most calls are hardware accelerated, client-server architectures make it much easier to exploit the parallel processing characteristics of modern systems. Also, in cases like OpenGL, having a client/server model allows the server to reorganize the input data. Since a state change often lowers performance more than the additional processing, a client/server model turns out to be faster.
A deep unwavering belief is a sure sign you're missing something...
If a diverse number of applications require it, yes. What you don't seem to get is that if there are 5 different toolkits that each implement major, but redundant services, and the available body of applications uses each of the toolkits equally, then you HAVE to have them installed. For example, it is pretty hard to avoid having KDE or GNOME installed because there are several great applications (KOffice or KDevelop) that require it. I'm sure you agree that several redundant toolkits lead to bloat, and if people actually take advantage of those toolkits, it no longer becomes a mattar of what YOU want, but what the application programmer decided you need.
A deep unwavering belief is a sure sign you're missing something...
Is it in the standard kernel? Obviously if it hasn't been integrated into the kernel, there are issues that prevent it from being integrated, no?
A deep unwavering belief is a sure sign you're missing something...
Nobody ever suggested using it for serious database chores. However, having basic database capabilities in the OS makes all sorts of cools thing possible. The catalouging of MP3s, the organization of "people" records, etc. That's the only type of database that it makes sense to integrate into the file system of a genral purpose OS. As for the old filesystem, back then the bfs WAS a database, but it was changed due to performance concerns.
A deep unwavering belief is a sure sign you're missing something...
It was actually released by X.org, a new organization created by the Unix vendors to further the X standard after the Open Group took over. The actual central CVS repository is being maintained by Metro Link, with changes being submitted by all the X.org members, including XFree86.
/. for his work with Compaq's handheld computers, and Bob Scheifler is working for Sun on Jini technology.
www.x.org has more details.
As for the original X developers, Jim Gettys has been mentioned recently on
Not surprisingly, there's still no builtin alpha channel support. Many Linux desktop users have been beefing about this for a while now, and I'm wondering if it will ever make its way into X.
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.
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!
Will I retire or break 10K?
Anonymous coward, prepare to be innovated.
We are Microsoft. You will be Innovated(tm). Resistance it futile.
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...
... is why version increments keep getting smaller on venerable standards. For instance, if you look at the early days of UNIX, SVR3 was soon followed by SVR4, and BSD went from 4.2 to 4.3 to 4.4 in a reasonable amount of time. Likewise, we went from X11R5 to X11R6. But now, we're stuck in X11R6.5.1.blah.
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
Laws do not persuade just because they threaten. --Seneca
From UNIX Unleashed...
"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.)
A deep unwavering belief is a sure sign you're missing something...
The reason it's so slow is because it really wasnt' designed with current desktop configurations in mind
/., you really have to do a lot of things in X that shouldn't be necessary. (What I really want to see, though is a windowing system that totally ditches the concept of a palatte. Screw the 256 color users, let them put up with automatic dithering.)
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.
A deep unwavering belief is a sure sign you're missing something...
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
Why is it called X11? I understand what X is, but I find it hard to believe that there have been 10 complete versions before this, if each is ALSO numbered with a major/minor number (6.51). Has it always been called X11? Is there a reason?
You know, the best thing for X would really be to dicate a bit more policy. The whole concept of X is to provide the low level services that higher level window managers need. Thus, X can provide a common foundation, while window manager provide the actual user-interface. However, this concept has faded in recent times. Now, you have things like GNOME and KDE implementing things that really should be in X. Things like printing services, imaging systems, and object models, that aren't really part of the user-interface, but part of the lower-level "services" layer that X provides. The benifits of integrating more of this into X are obvious. Instead of having the two competing desktop environments that you have now, you would have a common base of X windows applications that would work in any window manager. In the process, there really isn't any freedom lost. Are the two desktop environments really that different? Aside from the look (which belongs in the window manager anyway) the two environements pretty much provide the same services in more or less the same way. Sure you know have one object model, one imaging system, etc. Of course, you only have one graphics system for X, you only have one X input API. You can't choose the input subsystem for X, so why should you be able to choose the object model? For that matter, why should you care? At some layer of the system, you have to standardize something or all hell breaks loose. SOMEBODY has to dictate policy or else you end up with a sysem THAT HAS NO POLICY. In return for a little freedom for the developer, think of what you gain. The user gains the choice to use what desktop environment they want. Developer gain the freedom to not have to worry if they are cutting of people by using the wrong DE. Commercial vendors gain the freedom to write applications to a desktop environment instead of just statically linking Motif.
A deep unwavering belief is a sure sign you're missing something...
WWJD -- What Would Jimi Do?
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
The networking code between the X client and the X server in XFree86 is a UNIX domain socket. This is possibly the fastest IPC method in Linux. The UNIX domain socket requires only one redundant copy and Linus Torvalds himself has optimised the all mighty crap out of it.
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.
Free86 takes the code that the X Consortium has developed and changes it in such a way as to make it x86 native
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, added the essential XPM library, and beefed up Xaw to make it almost usable. Check out the release notes 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 for the most recent developments.
I'm not going to be one of those people who gripes that Slashdot is not Freshmeat, and therefore shouldn't announce software releases. (Hey, if it's News for Nerds, it's fair game.) However, could we try to have some explanations of exactly what this software is, what it does, and why this release is significant? Posters and editors should realize that this isn't the same audience as Freshmeat (i.e. not everyone compulsively keeps track of and updates every item of software in their system). And, I'm embarassed to say, "X11R6.5.1" doesn't mean much to me. C'mon guys: if we wanted plain vanilla software announcements, we'd read Freshmeat (and many of us do). So please, don't just announce the news -- report it.
Thanks,
IT
Power corrupts. PowerPoint corrupts absolutely.