Slashdot Mirror
XFree86 Release Plans
sfid writes "Just read at XFree86 about the release plans for 4.0. The first beta will be availiable in July, further on there will be releases every 4-6 weeks. "
Mentions several new chipsets in the 3.3.x tree, as well as
several interesting new features for the 4.0 tree including
video in a window, multihead, integrated TrueType,
as well as 3D support
Precision Insight's
DRI stuff (which looked really excellent at LinuxExpo), Mesa,
or SGIs GLX.
I for one am cheering for such a major upgrade. With recent advances with Redhat 6.0, GNOME 1.0, GTK+ 1.2, and many others (including the anticipated release of Mozilla), Linux is finally advancing far enough and fast enough to be a serious contender in the desktop market.
It's important to note the large availiability of applications and tools not only to make it easy for developers to create products for Linux, but also the tools to make it easy for "normal" users to experience the advantages of using an open source OS.
Especially with all the recent news coverage that Linux has been getting, the idea that device support (at least video device support) has started to become largely comprehensive (especially with a section of the market Linux has long been bad with, totally new drivers, as evidences by nVidia and Creative's moves) really adds to the appeal of the operating system.
Quite simply, I cannot wait until I can get my hands on a version of XFree 4.0, especially if there's some very cool and useful features such as multi-head support, support for more cards, &c.
Thanks to everyone that has helped develop and test X, and remember to support open source software!
And yet even with xfstt (or a patched XFree with ttf support) or xfsft (I've tried them all), font rendering at small point sizes is apalling. Absolutely terrible. No worse than PS font rendering at small sizes, but come on - Windows and MacOS have been doing good quality small point size rendering for years.
,hacker Perl another Just)'
I seriously hope this improves (it's all down to a good hinting engine). That and font smoothing would seriously improve my X experience.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
XFree worked fine before (well, the font display sucked (yes, I know about standalone TT and PS fontservers)), but the design -- separate server binaries -- always bothered me as very inelegant. Finally, my aesthetic sensibilities will be satisfied, and we will all live happily ever after! (the fact that there will finally be native Voodoo3 support, won't hurt either).
--
--
Victor Danilchenko
IMHO, other than hardware support, XFree is better. (And XFree has pretty good h/w support.)
Reasons you might want a commercial X server:
OpenGL with anything other than an NVidia or Matrox chipset. (And right now, 3D for the G200 is limited by incomplete specs.) So basically, h/w support...
Multihead support. I'm not sure if XFree supports multihead yet. According to the announcement, 4.0 will.
Umm... Other than multihead support and hardware support, I can't think of any other advantages... I think AccelX has been known to be faster for some cards, OTOH, I've heard many bad things about the quality of the server. (i.e. bugs) I'll take a performance hit for the stability of XFree.
retrorocket.o not found, launch anyway?
It would take more than an addition to 4.0 to support that, it would take a pretty fundamental change in X-Windows itself.
X fonts are returned to the server from the font server as monochrome pixmaps. Font servers expect to send that, x servers expect to get that, and the client programs all expect that. You'd need to extend the X protocol to support grayscale pixmaps for the fonts, recode the font server to be able to send them, and the clients to be able to understand them.
IMHO, I don't see it happening. Some client programs where it would be useful could be extended to do it the way Gimp does it (request the font at a size a few multiples bigger than needed, and resize it down on the fly), but it would be application specific, and I can't see very many applications needing it.
I thought for a while about poking around in Mozilla and trying to add the ability to do that in there, but since I decided to do it, I haven't managed to get a single copy of Mozilla to run on either of my decent Linux development systems...
I think Mozilla is a place it'd be nice to see that support.
A lot of good reasons and partition schemes mentioned above, but nobody seems to have mentioned a separate partition for swap.
/var or /tmp, so I generally have one partition for the relatively invariant stuff (the OS and apps, ie /var /tmp and /usr all on the same fs as /) and one for data, user files, etc. (Plus a swap). And then another partition for each OS if I want multi-boot.
Sure, ideally you have enough RAM that you never swap. But if you are swapping, performance will be a heck of a lot better if the swap space has its own partition rather than messing with the filesystem. Some commercial databases like to have their own partition for data too, for similar reasons.
On a mostly single-user machine (ie my personal workstation) I'm not much worried about overflowing
-- Alastair
Windows was able to include it without any rewrite to existing apps. Are we actually admitting that Windows can do something that UN*X can't? And as for the need - try going to 90% of webpages that have hard-coded font sizes in them. The suckers get scaled down so small they look like little bit blocks. With anti-aliasing, at least I could make a guess at what it was supposed to say. And yes, I run at 1600x1200. It doesn't make much difference when people force their pages (or apps) to 6 point fonts.
Please let's make one thing clear:
Since I read all the stuff about Linux in this comment: Xfree86 never was a "Linux project".
(GNOME, GTK and Mozilla aren't either.)
Yes, I know nobody said this but some readers here may get the assumption from reading comments like that.
The MacOS (or possibly even the hardware) handles the color bit change transparently - I don't think the application is even aware, because the system handles the dithering. Anyway, I used to have a IIfx with a 21" 4-bit grayscale and a 24-bit color monitor and everything worked (except a couple of games) with no slowdown.
--
Business. Numbers. Money. People. Computer World.
Given the same TT font on both X and Windows, if X shows the small points worse than Windows does, then my guess would be that the hinting support in X is either missing, broken, or just not good enough.
--
Timur Tabi
Remove "nospam_" from email address
The way I remember after reading about this, adding anti-aliasing would break compatibility with current X programmes, so that the new feature would have to be coded in as an 'extension' of sorts, and that would require that current X clients be rewritten to use that extension. This would either increase the creeping featurism and bloatiness that is currently present in X. Besides, as you say, it's not really needed.
In Soviet Russia, Jesus asks: "What Would You Do?"
This is something SGI has done forever, and it's just incredibly convenient. It's so much nicer to be able to have the default visual be an 8-bit colormapped visual, but have it be possible for specific applications to use 24-bit color as needed. Most applications don't need TrueColor, so all that memory is just wasted on them. And there are things you can do in PseudoColor that are just impossible to do efficiently in TrueColor.
It also makes debugging X programs much easier, because you can test whether your application works in both PseudoColor and TrueColor modes without having to start a second X server to do it.
I wish they wouldn't call this ``overlays'', though. Overlays are something else entirely (that's the term for visuals that have transparency built in at the hardware level. That kind of thing is supported on X servers from all the major players except XFree and Sun: SGI, HP, DEC and IBM.)