XFree86 Release Update: 4.0 in Q12000
Belzecue writes " XFree86.org has been updated mentioning that xfree-4.0 has been pushed back 2 months to mid Q1-2000, but that the next snapshot release of the 4.0 preview series will be released before the end of the year.
"
dga has been around for awhile now. Programs like wine, vmware and xawtv make good use of it.
- MbM
- MbM
Although many readers probably don't realize it, this is actually really bad news for the Linux gaming community. For those who are unfamiliar with the design specifications of Xfree86 4.0, one of the major planned innovations is tightly integrated 3D accelleration. Not only will this significantly improve performance and stability, it will also make it easier to make a given video card compatible, this increasing Unix's (yes, XFree86 IS at least somewhat cross-platform!) viability as a gaming platform. The sooner good, integrated, compatible 3D support comes to Unix, the better off Unix gaming will be.
XFree86 4.0 is being delayed two whole months.
I'll bet it is also losing market share in the
corporate segment as well. That's it. This
must be the end of X. Game over.
Actually, I can't even remember what got released
two months ago. XFree86 4.0 will come out.
It will be good. Mozilla will come out.
It will be good.
You may see more delays in the Open Source world,
than in the commercial world, but I think is's a
good sign. We keep our clear goals and do not compromise to keep a deadline. This means fewer problems in the future with necessary compabillity code to these 90% finished programs.
Still if you need the bleading edge - go for the snapshots.
Real Programmers know when their programs are in beta and when they are not.
Finally, the next release of X is visible on the horizon... :-) Hopefully with the new device driver API, people can come up with drivers for new video HW faster. My SiS6326 chip is still only minimally supported under X (no bitblt, no accel), and so far I'm stuck with 3.3.3. I tried the 3.3.4 driver and it barfs on my system, locking up the keyboard totally. :-( I've yet to try 3.3.5... but hopefully with XF 4.0 this nightmare won't happen again. A generic API is what we really want -- so that supporting a new HW doesn't entail hacking an entire X server, which is no trivial task. By localizing device-dependent parts of the X server, I think people will be able to come up with more drivers faster, so X won't be lagging behind new HW as bad as now.
mikre he sophia he tou Mikrosophou.
send flames > /dev/null
Only 'flamers' flame!
I hate to carp about something like this (I'm generally one of those "shut up and code" type people), but I really do think the XFree people could release more snapshots, and more development code. It's been what, three, four months since they released 3.9.16, and only now are they releasing 3.9.17. How many revisions has even the stable kernel gone through in that time, let alone the development kernel . . .
Which isn't to say that things would necessarily be going faster if they did, but they'd be much more likely to get people using the snapshots if they were obviously working on them. I'm not going to use development code unless I can be fairly sure that any bugs that are found are going to be fixed _and_released_ in good time. That's why so many people are happy using development kernels - they can see the improvements between versions, and if they find a bug they can see the fixes going on in real time. This just isn't happening with X at the moment, unfortunately.
Oh well. At least they're still working on it, even if it's not as open as we might like.
himi
My very own DeCSS mirror.
Actually, I'd be happier if more HW manufacturers adopted an open philosophy in publishing their APIs. Yes, it would be really nice if HW manufacturers starting putting out X servers for their cards, but I think it's better if they release their API. Why? Two reasons:
But in the meantime, I suppose all we can do is hope that XFree gets enough support so that those of us with unsupported (or poorly supported) hardware can have a better X server soon.
mikre he sophia he tou Mikrosophou.
How are people supposed to "shut up and code" on XFree86 when the application process to become a developer intimidates the casual bug-fixing C coder, and when the releases are so infrequent that released code is probably too far behind the current code for an outside developer to work on?
I say this here every time mention of XFree86 4 comes up, but I'll say it again: now that they've got a modular architecture that they can split NDA'ed drivers away from, they need to open up the bulk of XFree86 development to the public. How much of the work that goes into other open source software projects comes from people who download the latest bleeding-edge CVS and fix one little instability? How many now-full-time coders on other large open source projects started as people who simply liked poring through bleeding-edge releases and hacking on them?
There are two ways to recruit development for free software projects: you can plead for more full time developers on your web page like XFree86 does, or you can give people something bleeding edge to develop, like most other projects do. It's a shame that the most important free software project out there is hurting for lack of interested developers, but I think they're partially bringing the problem upon themselves.
For certain cards, you can get PDGood accelerated 3D under Linux now. See the Linux GLX site.
--
It's October 6th. Where's W2K? Over the horizon again, eh?
Sheesh, evil *and* a jerk. -- Jade
before posting. Plesae. read everthing.
Also, when you post, make sure you put a proper title in your subject.
Good luck.
--
I disagree. A few short years ago, gamers thought nothing of fiddling in MSDOS for an hour or two with IRQ settings, mouse.com, himem.sys, emm386.sys, and a host of other niggling things. The XF86Config file is a damn sight easier than this, and the Mandrake distro's installation preocess, at least, is going to be developed to autoconfigure 3D acceleration on Voodoo3/Banshee, Matrox G200/G400, and TNT2 cards, as soon as XFree 4.0 is out officially.
Then installling games will be a matter of clicking on the RPM in KDE. This is not very far away now, though the news of this delay sets this plan back about 2 months.
They will release the binaries for all 3 versions (Win32, Linux, and Mac) sometime after all 3 are released in retail. You can use the cd of any version with the binaries of any other version. The reason for holding off on the binaries for later is that they don't want everyone to go and buy the windows version and then just use the linux binaries with it. id would have liked to include all 3 in one package, but Activision and many other publishers and developers are VERY interested to see how commercially viable retail Linux games are, and if it's worth the effort to port other games. If the linux version gets good sales, it'd encourage a lot of developers to port their games to linux, so we'd have a lot more than the handful we have now. Let's just hope they don't make us pay seperately for each version.
This would have worked out a lot better if all 3 were available at once, especially since most ppl who have the hardware for it probably still dual boot and would go with the windows version first and wait for the linux patch. Unfortunately, it would have been too much trouble to wait for all 3, especially if it meant missing christmas.
It's going to be released in Q12000!? Quarter 12000 is like the year 3000! And I thought Mozilla development took a long time.
Luckily, though, with the beta releases, we have a 1000 years of testing, so it should be stable and feature rich.
NOTE: This post not for the humor (or humour) impaired
DGA has been around for years. It's analogous to DirectX minus Direct3D. It's used in vmware, and emulators such as vice and UAE, as well as games that use SDL on linux.
DRI is in XFree 4.0. It's analogous to Direct3D
GLX provides network-transparent 3D accelerated rendering by encapsulating OpenGL in X-protocol calls. That is to say, I can run a 3D program on a computer in Paris, and have it display it output on a computer in London, using the 3D hardware of the computer in London to render the 3D, rather than trying to send an entire rendered screen from Paris to London, which is horrendously inefficient and slow. This is very cool, and comes from the SGI high-end graphical workstation world, and is not something that's easy on windows (to do it on windows, you have to use X on windows - I think Hummingbird Exceed X server supports GLX. I might be wrong.)
In an Open-Source paradigm, even if the "official" release is delayed, you can still get something to work with. Proof that they're not dragging their feet, yes, but you can also start to work with the program. You see them fulfilling the promises they made.
In proprietary paradigms, you get nothing at all. That's the difference. More often than not, Microsoft and other companies make lots of promises and don't deliver. At least in Open-Source situations they deliver something, even when they say it's not yet completely ready.
If there's a new release every month in the development tree then people wouldn't get so worked up about it, and they wouldn't have distributions doing dumb things like that. The way things are, when they release something people assume that it's production code, because that's all we ever see from them. If they weren't so shy about releasing code people would be more careful about using their development releases.
What it gets down to is that the XFree developers have a different approach to development. Coming from the Linux world that approach seems a little bit silly . . . But hey, it's their code . . .
All that aside, though, they've done a great job. X might not be perfect, but it works, and the free Unices would be nowhere near as popular as they are without it. So more power to them . . . and as much good code as possible to everyone!
himi
My very own DeCSS mirror.
DGA has been around for years. It's analogous to DirectX minus Direct3D. It's used in vmware, and emulators such as vice and UAE, as well as games that use SDL on linux.
As a person that has used DGA and DirectDraw for many years, this is simply not true. DGA lacks a feature which is key to fast graphics: Hardware accelerated blting. DirectDraw does this nicely and even allows surfaces to be in VRAM for even faster blting. I am happy to say that this is being fixed in Xfree86 4. Both of these still lack blending support, but you can now just relly on the 3d hardware on most card to do that.
DRI is in XFree 4.0. It's analogous to Direct3D
DRI is a way for software to talk to hardware without going through the X server. Direct3D is a HAL, and an API, and a library. These are totally different.
This is very cool, and comes from the SGI high-end graphical workstation world, and is not something that's easy on windows (to do it on windows, you have to use X on windows - I think Hummingbird Exceed X server supports GLX. I might be wrong.)
Remote display with OpenGL is something that was built into OpenGL. It could easily be implemented on windows, as the line between client and server is well defined in the specification. --Tom
Why was this moderated down as flamebait. Seems reasonable to me.
Logic ... merely enables one to be wrong with authority. -- Doctor Who
...now that they've got a modular architecture that they can split NDA'ed drivers away from, they need to open up the bulk of XFree86 development to the public. How much of the work that goes into other open source software projects comes from people who download the latest bleeding-edge CVS and fix one little instability? How many now-full-time coders on other large open source projects started as people who simply liked poring through bleeding-edge releases and hacking on them?
Yes - and there's another big advantage - opening up the non-NDA hardware drivers will put a lot more pressure on the proprietary holdouts to open their specs, because the open-spec drivers will improve a lot faster.
Life's a bitch but somebody's gotta do it.
Not speaking for XFree86, but as a contributor, the few comments I've seen suggesting that the snapshot and released code is to old to work on or submit bug fixes against are not realistic. In the past months the released code is close enough to the development code that most bug fixes from non-XFree86 members would be welcomed. As are bug reports and problem reports. One of the major challenges of a project like XFree86 is getting the code base tested on multiple platforms with combinations of video cards. Let alone making both released versions such as 3.3.5 and snapshots of a new development effort (3.9.x) available.
Having said that, I'd encourage those who might like to contribute to consider joining the XFree86 effort. I won't claim the learning curve is easy. It's a large code base and video driver development isn't the simplest thing in the world. Or submit bug reports or patches against the released versions. Don't think that because the latest development source is not available that it has moved so far ahead as to make your patches obsolete. That is rarely true.
The closed development model is due to licensing concerns. From what I've heard there may at times exist code in the development tree for XFree86 which doesn't meet the release license requirements. The closed model allows XFree86 to release code to the developers without breaking that type of license restriction.
I don't give a flying fuck about the filesystem when I'm an end user. Unix people often fail to see the big picture when it comes to end users, probably because this type of user never gets near their OS.
When I was a CS student I had the pleasure of working with several UNIX flavors. I also installed linux on my PC when this still was a non trivial act. At the university I worked we had those nice little networked workstations which commonly shared one computer (3 terminals, one computer, HP UX machines, Indys and later also Sparcs). They were slow. Not just a little bit but really slow. Even when we got newer hardware it still was slow. Probably those things are really nice if you can use them stand alone but networking to terminals clearly was a bad idea performance wise.
X windows is only nice if you have monolithical applications (i.e. apps you can't break up). If its monolithical that means it is probably too big to run on a small computer. If it's not, you can separate the GUI from the rest of the application. Well designed applications don't need to waste bandwidth on transmitting mouse clicks.
Now opengl over X sounds like a really bad idea. Even a modest 3d environment can contain hundreds of megabytes in textures and polygons. I have a hard time believing that you can squeeze that down a network in real time. If on the other hand you have it locally, why the heck would you want your software to run remotely? Any performance gains would be canceled by the network overhead.
Jilles
I don't know what your situation is, but X windows solves many problems for me. I have a machine on my desk, but do to (stupid) licensing restrictions, the main program I run is on a computer way over there. I also work with headless machines in a lab, and pulling windows from them makes some debugging tasks easier.
Back home I have a powerful modern machine, and several older sun3s. Now I could buy more powerful machines, but those cheap sun3s make excellent terminals, and the powerful machine is fast enough for them all, but the suns are not fast enough.
I'll agree that X windows is a bit slow. I'll agree it isn't perfect. However it does solve many of my problems.