Slashdot Mirror
XFree86 4.0 Now Available
YAH00 writes: "The 4.0 release of xfree is now available!!! I'm downloading it from ftp.xfree86.org as I type!!! " I've played around with the preview releases, and 4.0 looks to be a much needed improvement over the 3.3.x tree, with xinerama [?] features and improved performance for many graphic chipsets.
makedepend stalled at some point during make World. Killing the it off with ps was the answer, compiled without any probs.
Running it now. Mozilla actually looks right, the menu fonts are the correct size. Woohoo!!!
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
http://www.au.xfree86.org/4.0/RELNOTES. html
Enjoy. Congrats and thanks to the XF86 team
Eric
(here's the introduction/installation instr. for those with mirror probs):
XFree86 4.0 is the first official release of the new XFree86 4. XFree86 4 represents a significant redesign of the XFree86 X server. It is very important to keep in mind that XFree86 4 is still very much in development, and it contains a lot of new work. That means two things: there is a lot of new exciting stuff to try, but being new code, it hasn't had nearly as much of a workout as the stable 3.3.x releases. If you're looking for a well-tested, stable release, and can't afford the inconveniences that new software can sometimes cause, then you are probably better off sticking with the 3.3.x releases for now. If you have the resources to try out the new version and investigate its features, or if you just like being on the bleeding edge, then please try 4.0!
This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.
On the subject of configuration, we have updated the basic text-based tool "xf86config" to generate config files in the format required by 4.0 (3.3.x config files won't really work with 4.0). We're also working on some other configuration tools, including one that is built-in to the X server. An early version of this is included in the release, and it works well for some hardware. To try it out, just run (as root) "XFree86 -configure". Both of these configuration options will at worst give you a reasonable starting point for a suitable configuration file. We've put some effort into documenting the 4.0 config file format, and you can find that information in the XF86Config manual page. Please check that and the driver manual pages and related documentation for further information about that.
Oh, another thing you might notice is that our documentation is rather patchy. Most of what is present should be in reasonable shape, but there are gaps. We thought it better to leave out docs that were very out of date rather than providing inaccurate and misleading information.
Finally, before you download and install the binary distributions for this release, please have a quick read through the Installation Document. It may save you some time. If those cautionary notes haven't turned you away (and we certainly hope not), please read on... The sections below describe some of the new features and changes between 3.3.x and 4.0. There is a lot of new stuff, and we definitely don't have enough space to cover it all here.
Want to work at Transmeta? Hedgefund.net? Priceline?
Can your IM do this?
ftp://download.sourceforge.net/ pub/mirrors/XFree86/
---
SourceForge Programmer Type - http://sourceforge.net
---
Drew Streib, dtype.org
ftp://soul.apk.net/pub/xf4/
;-)
enjoy until we get slashdotted!
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
Berto
Does Xfree86 4 have support 2-d transperancy? Is such support necessary for pulling transperancy in X? One of the things I like about Mac OS X is that it can do slick things with tranparent windows and menus and such. I'd like to some wicked cool enlightenment theme with such trasperancies all over. Even more, I would like it to have some hardware support so that it will be fast.
So, does 4.0 do this? Does anyone even care? Or is this really in the domain of toolkits to handle?
Got HTML? Want LaTeX? Try html2latex
This is basically a problem in your browser. The ls command used by ftp servers has a policy of giving a year if and only if the file is more than x months old. I believe x is 6 for most FTP servers.
Your client, trying to be helpful, attempts to reconstruct the year by assigning a year in the last 12 months if the year is not given. This works well. Most of the time.
The analomous case is when the timezones differ so that the file looks like it's in the future to the client.
Fixing this is not hard, and I did forward it to the Mozilla team.
Moral of the story? Getting times and dates right is hard.
LILO boot: linux init=/usr/bin/emacs
If everyone keeps hitting the main FTP site instead of one of the mirrors, the stuff'll never replicate.
Here's a hint: Mirror List
æeee!
Bad fonts under Netscape is a solved problem };-)
While anti-aliasing isn't involved, I think you'll find these a significant improvement over X11's out-of-the-box look:
X: A Site for Sore Eyes
(go to the bottom of the page)
iSKUNK!
a) The linux kernel isn't any more open a development environment than XFree is. There are a couple of gurus with commit rights. Everyone else sends patches. Most of those are rejected. It's not a formal process of approval like becoming a FreeBSD developer. But you're equally free to fork the code in any of those cases -- the unwashed public always has full access to everyone's latest stuff.
:)
b) Hiding behind cruft is not a way to fight closed source drivers. They've been offered before, many times. And the response has been increasingly negative. I think we'll continue to write our own, open drivers, and write better ones. I want code I can review running with priviledges on my machine. How about y'all?
c) A cleaner driver model will make it easier to write Free drivers too.
d) Let's keep things positive here, huh?
e) "uncommon hardware, (alpha,ppc)" will rise to crush puny pathetic PCs once and for all
Since you brought it up...
/. years. It holds no water. You, as an obvious repeat AC, know of something called the "Slashdot Effect", it's the strange phenomenon of 100,000 info-crazy quadrapeds stressing the laws of physics and the capabilities of silicon based counting machines. Sometimes this "effect" breaks stuff. Chains being only as strong as the weakest link and all that, bottlenecks and such.
/..(nitpick that punctuation)
I've seen this lament a number of times in recent
So to bring it to a point, sometimes it is, in fact, "informative" to cut and paste some electrons, as such action makes this information more available to all, utilizing the vast resources of a billion dollar corporation who's mouthpiece is affectionately known as
I await your inevitable retort.(and my Karma protects me from flames like Goku's many Dragonballz)
--
+&x
Hopefully companies like Creative Labs will set a good example for others to follow. Creative released a closed-source driver for the soundblaster live. It worked (just) but MP3 playback was noticably worse than in Windows. They got a lot of flack from the Linux community over their refusal to open-source the driver and eventually gave in and released the source under the GPL. The soundblaster live driver suddenly improved beyond recognitions (thanks Alan & everyone else) and now plays MP3's better than the Windows driver on my PC.
If companies realise that there are real benefits to open-sourcing drivers, then they might just do so.
HH
Yellow tigers crouched in jungles in her dark eyes.
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
All this means is that we need to use a different means of keeping the pressure on. Personally, I'm *glad* I'll be able to have a little more flexibility in using binary drivers and at the same time I'm *sad* that this means of pressuring harware vendors to open their specs is now going to be weakened.
There are a few factors working in our favor:
The binary video driver api doesn't give hardware vendors cross-platform access - they wind up having to build and distribute drivers for every platform, multiplying their headaches and workload. This is work than can much more efficiently be done by the distributions and platform maintainers, including making necessary adaptations, for example, byte swapping - a much bigger issue than you'd think.
It doesn't give hardware vendors access to the power of open-source development, and the quality improvements resulting therefrom. Oh, and don't even *think* about trying to pass of a binary version of someone's open source driver as your own.
Closed-specs hardware vendors don't get the "coolness" bonus from, for example, us, the Slashdot community. Don't underestimate the effects of this: we've now become the "brand specifiers" for a huge part of the PC market, especially the games market. I'd say that we had a lot to do with 3Dfx's decline (because of closed-api concerns) and NVidia's rise (because they opened *part* of their specs).
The embedded market XFree is just too big and bloated for the embedded market - anybody care to argue this? Or for installing on old 486's and P90's. I know - I've tried it. We absolutely have to have an alternative, and there are already several projects underway on this. Let's not build in a binary driver api in these new video systems for at least 2 or 3 years, ok? That will keep the pressure on: if you want your card used in the embedded market (possibly much bigger than the desktop market) you'd better open the api. Do it sooner and get a bigger piece of the market. Do it later and become a historical footnote.
Life's a bitch but somebody's gotta do it.
I think your extreme attitude helps marginalize Linux rather than support it. A future where open and closed software intertwine (for various values of closed) is not to be feared. Yes, some vendors will gain temporary advantages through concealment, but you show little faith in the power of open source if you believe that its advantages will vanish as soon as such hybrids appear. Other vendors will go the open-source route, and profit from its advantages.
You mention several advantages of open-source, such as better stability and intregration. These are real, solid advantages that potentially give one vendor a leg up over another. In the face of this, it would be unlikely that no vendor would take advantage of those things. Many won't--old habits from the MSWindows domain will die hard--but a few will, and from their success more will be encouraged to do so.
Look at it from another perspective: we're going to get vendors involved in Linux who otherwise wouldn't be involved. Then we'll convert 'em. Not all of them, but the fact remains that opening up a middle ground like this gives us more of a chance of pulling them into the open-source way of doing things than an all-or-nothing attitude will.
Tear down the walls!