Slashdot Mirror
XFree86 News
PseudoMan was the
first with the news: XFree86 3.3.4 has finally been released (yes, you
can actually see the contents of the directory now). Rumour has it that
the new release contains support for various Matrox cards, and may be the last release before
we see 3.9 show up. Update: 07/20 06:05 by J : It seems that the first public beta of 4.0, 3.9.15,
is now available. xinerama, here I come!
XFree86 is done on a closed development model. Yes, the result is free and the source is freely available, but the development is still quite closed.
I really think that if they were to change this, it would accelerate the pace of XFree86 development, which I consider to be way behind the curve in how fast it's evolving compared to other projects of the same significance.
To some extent, though, the choice of a closed development model is to allow them to have greater ability to work with hardware vendors and software contributors that have restrictive requirements. There are clearly two sides to this coin; it lets things happen that wouldn't happen otherwise (more hardware support, more cool-neat-features), but it also lets things happen that wouldn't happen otherwise (being put in wierd positions by vendors such as with the NVidia stuff).
It may be possible for the XFree86 team to organize their in-development tree into friendly parts and unfriendly parts, where the former is stuff that could be made available by anoncvs and the latter can't. This might be a compromise situation that could make more people happy than the current scenario.
I can't show you mail that says 'bugger off' but I definitley got that impression.
When I read about SGI releasing GLX as open source I also read this on the Precsion Insight site:
Programmers who are interested in working with the DRI are encouraged to join the XFree86 Project.
As I was interested in working on this project, I went over the the XFree86 site and studied their procedures. They say
One of the XFree86 Project's scarcest and most valued resources is its developers. We're never short on things that need to be done, just short of people to do them. If you're interested in donating some of your spare time to help advance XFree86, we'd like to hear from you.
To join The XFree86 Project as a non-voting member, send email to xfree86@xfree86.org requesting a membership application form, and briefly state the reason why you wish to become a member. It is very rare that we knock back membership requests, but we are looking for members who will be active in developing and/or testing rather than people simply looking for early access to new code.
So I wrote a short e-mail stating my reasons to join and asked if they have a task that was suited to introduce me to the project.
The reaction was not a TO DO list, but a mail from XFree86 Prez Dirk Hohndel that told me rather to join some other related project that was run by another SuSE guy, Simon Pogaric. Thus I contacted him and frankly, IMHO he was not looking for any help, he had no TO DO list either.
This was not what I expected. As I did not want to force my help on people I did not pursue matters further and looked for some other stuff (after all there is enough work).
I might be paranoid but I have the feeling to have been gotten into some competition between two rivaling groups (Red Hat, PI vs. SuSE).
The whole matter rather annoyed me because I think such large projects should have enough tasks (documenting, code cleansing, implementing) where good coding skills (in my case 18 years of programming, plus strong scientific background) would help and that would allow one to get accustomed to the code base.
Other large projects like egcs or FreeBSD work that way and offer a kind apprenticeship system. With XFree86 I have my doubts.
The problem is LOTS of people (especially in the Linux camp) release broken fonts. Mkfontdir (under FreeBSD and IRIX) needs the entire fontstring embedded in the font file itself in order to work, not just the name of the font. What I've done is created a new driectory of these broken fonts where I can go through and create the fonts.dir by hand. For examples of broken fonts, check out fonts.themes.org.
I read the internet for the articles.
> XFree could start by opening up its codebase a little.
Once upon a time, it was open. Then certain Linux distribution maintainers (no longer around) decided it'd be neat to include outdated, buggy pre-alpha X releases in their distributions --- and redirected all the bug reports to the XFree folks. They Were Not Happy, and I don't blame them.
The upshot here is that *we* screwed up, and the XFree folks got burned badly as a result. If we want to see more open XFree86 development, we're going to have to prove to them that we're not going to pull stunts like that any more.
(Unfortunately, with Red Hat's fondness for including prerelease stuff in their distributions --- "prepatch" kernels and Perl "m" releases, to name some from the 5.x era --- I'm not sure I'd trust them to keep their mitts off prerelease XFree86 code.)
-- brandon s. allbery, sysadmin @ cmu electrical & computer engineering "Think, youth, THINK!"
Now that I've said all that, Adam, just s/Branden/Adam/ and it's still true. =)
I really don't get it. Font handling is a well understood technology, and yet XFree still falls short. Fonts (even true-type fonts) look terrible under XFree - they look _far_ superior under (for example) Solaris' X server. And I'm afraid to say it, fonts just look a lot better under MacOS or Windows. It's a real shame, because I think XFree would be a lot more usable with a decent font engine underneath - and yes, I've tried both TrueType font engines for XFree.
:)
,hacker Perl another Just)'
Anyone know of any progress being made in this area?
Also font setup is appalling. I can't believe you have to edit font.dir files for each directory - why on earth wouldn't the server do this for you? I was astonished at the amount of work it took to get a few TrueType fonts working before the perl TrueType tools came out to do some of the work for you.
I guess you could consider this a bug report.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
15" = 1152x900
You think THIS is a good idea? A 15" unit shouldn't be run above 1024x760 for ergonomic reasons.
But really, I'm ahead of the game. People blow good cash on a 21" monitor when they should go dual head with 17's and 19's. I'm willing to gamble that the two 19's cost less than a single 21" can give you better than 70% more total pixels at a better refresh rate with more than 70% additional screen surface area. That is from my own analysis. I'd post the numbers, but I lost them. I considered getting a 19" when the costed about 400$, but I found a pair of cheap 17" for about 350$, an extra video card for the remainder savings (Matrox Millennium 8MB - solid units) and come out way ahead. MetroX also supports multiple screens on all Matrox products.
15" = 1152x900
17" = 1280x1024
19" = 1600x1200
21" = 1880x1440
Great idea. However, I have yet to see any monitor which is even capable of those resolutions at the sizes you have indicated. I don't know of any 15" monitors which can do more than 1024x768, and I can't even get my 17" higher than that (never mind that it says quite plainly on the box that it should be possible). All of the 19" monitors I've found can't do more than 1280, and the 21-inchers can't do more than 1600.
Netscape is broken. Try this:
1) Install TrueType fonts. Use the xfs server from Redhat 6.0 or xfstt.
2) Install the Arial font from Windows according to instructions with the TT font renderer.
3) In Netscape's preferences Appearance/Fonts, use Arial as the default font, click on the Allow Scaling button.
4) In the same place, type the number 16 (16 point font) in the textbox next to the "Allow Scaling" button.
5) Save preferences
At this point your fonts should be MUCH better on all pages, and comparable to the Windows handling of fonts. This works for my home 15' monitor at 1024x768 and my 21' at work at 1024x1280. This is an OLD problem with Netscape, one that Mozilla doesn't have (thank god).
Oh, one problem with this setup. Netscape doesn't save the point size of scalable fonts, but rather defaults to 12. You have to enter the '16' into the text box every time you start Netscape...
jf
Hi,
X 3.3.5 should be released in a week or two.
Not everything made it in this release...
The fact that no one is coming forward to defend this wild theory is instructive, wouldn't you say?
I've finally had it: until slashdot gets article moderation, I am not coming back.
If you antialias 10 point fonts or lower, the of course they'll be blurry then, the only way to get around jaggy fonts at small sizes is to not use them. Besides, you haven't heard the same thing, you brought up the subject in the first place.
The, shall we say "novel", theory about how antialiasing works, by playing with your eye focus, simply isn't born out by any facts. I eagerly await revelation to the contrary.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yes, the time is almost upon us. I'd like to see nVidia pick up the ball and run with it now. I have to make a decision sometime soon for a new vid card, and I would love to have a couple choices. Voodoo3, G400, or TNT2/Ultra. Hmmm, choices choices...
:)
I'd like to see what a DRI driver can do for Q3Test, as this is what was holding back cards like the TNT2 and G400 from performing well.
With LAN tournaments coming up, I would love to be able to compete with Q3Test/Q2 native on Linux. That would certainly raise eyebrows for the Windows folk
X11 doesn't have the advertising clause of the BSD licence, so basically X11 code can ``become'' any other licence. It's truly all things to all people.
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
The second thing to know is that 3.9 is highly unstable, especially with multihead. Feel free to fix bugs and submit patches if you do hack around with the 3.9.15 release, though. =)
(I actually played with multihead on a Microchannel/XGA-2 system, but that's another story).
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
"Due to a few important changes that came after 3.3.4 was finalized , a 3.3.5 release (which will include binaries) will be made in the next couple of weeks."
Ok, so they're releasing this version, which is known to be somewhat incomplete under a full blown version name. Why? Shouldn't they just call it a pre-release or a beta? It's only a couple weeks until the Real Deal comes out. Why say "Well, We have this new version of Xfree, but its got problems and we'll issue the fixes under the next version." Doesn't this sound like some idiot software company out of Redmond who releases service packs to fix service packs?
Ok, that was a little too much of a parallel. But do you see my point. If an Xfree86 release addmittively sucks, don't give it the entitlement of a full version number. Just call it 3.3.x-pre or something and let the world know: "For bleeding edge users only." At least they were half-thinking like that . . . they left out the documentation so idiots like me can't see if I need it for my Banshee. . .
Hi, I Know most of you Linux guy are not concerned, but what is the compatibility with X11 ? I run a Solaris box, and there are already so many linux software hardly protable on other Unices.
It's kinda sad how short the XFree team is on developers when more or less 99.999% of Linux users use X and 100% of distributions package it. It could really use some more commercial support from RedHat and SUSE, though they have helped a little bit in the past (RHat donated NeoMagic code once...).
For information on becoming an XFree86 developer, please visit the XFree86 developer page.
Also, you non-programmers that use X can do your part by knowing that RedHat and other commercial Linux vendors have ears for their customers and showing concern for the frequency of XFree86 release cycles is a good way to let them know that support for X development is very important to the success of Linux.
The support load is one of the key problems behind the current
somewhat closed approach. There are other issues (the devel
sources often contain drivers that were written under NDA
and for which we haven't received permission to release,
yet. Those obviously can't be publicly available).
The 3.9.15 release is somewhat a test case. If we receive
tons of support email from people trying to use it and
asking for help, then we might revert back to the closed
cycle that we did before. I certainly hope that none
of the distributions will attempt to include 3.9.15.
It is definitely not ready for that. SuSE will NOT include
it on their next distribution, btw...
Don't get me wrong. Bug reports (and of course, patches)
are extremely welcome. I saw another comment that we didn't
respond to bug reports. My answer to that is simple.
We get so many reports, and there are only so few people
to respond. Usually none of them go unseen and as long
as they contain a fix or the fix is obvious, things
usually get fixed as well.
Of course, the 800 or so bug reports "my Trio3D card
doesn't work" didn't really help to fix the problem...
Dirk
Sorry if things went wrong that time. I get tons
of emails a day, so I must admit that I don't
remember the incident that you are commenting on.
There is no competition whatsoever between the
work that PI does and the work that SuSE does
for 3D. I am sure that Frank LaMonica from PI
will be happy to comment on his take on the issue.
Most likely your request came before the
DRI stuff was released to XFree86 (at which point
I usually deflected people since the stuff they
were looking for simply wasn't there, yet).
Normally everyone who sends email to XFree86@XFree86.Org
and states "I would like to work on ABC" with "ABC"
somewhat more informative than "XFree86" or "drivers"
will get an application form within a few days.
And those people are always added to the devel
team.
As to the generic issue here, yes, I think that
XFree86 should open up its development a bit.
And guess what, we will. The release of the
3.9.x snapshots is a first step in that direction,
more will follow.
Dirk Hohndel