Slashdot Mirror
XFree 4.1.0 Out
A reader writes "After some release candidates, final XFree86 4.1.0 is out. Check it from XFree86 FTP server. Their website isn't updated yet." Check the README for more information.
← Back to Stories (view on slashdot.org)
I can't get in. Even the mirrors seem slashdotted. You'd have thunk that even geeks get out on Sat. night... ok, maybe not.
:)
The BSD license is more free than the GPL. At least BSD code can be used by anyone, anywhere, without all the restrictions and commercial confusion that the GPL imposes.
Go do something useful instead of post such crap.
I'm using a voodoo3 card and basically the whole of X is now a 3dfx-accelerated app with full MTRR support. Using aviplay I used 2 get about 10fps and now I can got fullscreen or maximize it and it's still deadsmooth at 30fps on my PIII/550. So if your card's supported with acceleration on X4, just get it :)
Somehow I doubt you can write anything worth selling. Since RMS brainstormed and wrote the license, he is the one most knowledgeable in how and where it should be applied. He is probably the most realistic GPL advocate out there now... Not saying that everything should be free, but saying what should be as well. Careful where you tred, slashdot moderators like to mod down anyone that doesn't proclaim that RMS is god.
It is totally out by XFree86's standards. The X Consoritorium doesn't make the RPMs, DEBs, or TGZs. They only release the source code and leave the rest up to distributors (whom normally put their binaries on ftp.xfree86.org), at least this is my understanding. You should try compiling from source.. it's really not hard. Download the 2 or 3 tarballs, decompress, enter the directory and type 'make World && make install' and that's it. Probably one of the easiest programs to build (takes a while tho)
Ass opposed to the other X11 implementations. X11R6.6 is the API, Xfree is a nice implementation, and it just kicks ass. Get a clue. There's plenty of competition, there's several commercial implementations, and I just love the fact that the free one is so great in it's features and performance. Windows can't even be compared since it lacks many of the even basic features like network transparency, documentation and portability...
The X consortium doesn't even make the code, you dweeb :) It just develops the X11 standard. It's the Xfree86 team that makes the free implementation most of us use and they do release binaries in tgz's, others make the debs and rpms...
Sheeyeah, right! They said the same thing about CP/M!
XFree86 lets you change screen resulotions on the fly. However, it doesn't let you change the desktop size without restarting, so changing screen sizes is kind of a pain.
You know, it would be nice if you waited until they announced it to report about it. They need time to let things propagate to the mirrors so their server doesn't get flooded. By pre-announcing it for them, you're basically screwing them over. Slashdot always does this and it makes releasing big projects a mess. Way to screw over Linux, guys.
what does freedom mean?
ok, i think i'm getting trolled here, but the whole world accepts the misunderstanding of freedom meaning being able to do whatever you want.
most people who create things like to see it impact the world.
free software licensing is done to allow the copyright holder control of how the software is used, to maximise use and adoption many people use the BSD or MIT licenses or simply release the code into the public domain.
re incorporation in proprietary crap: would you rather them sell a worse product or have higher development costs? neither is productive but are wasteful of human resource.
no, you don't have those freedoms, it's that simple.
The readme was mostly about XFree 4 in general, and it stated that DRI was new in it.
...
It didn't really say how 4.1.0 was better, besides "bugfixes" and new hardware support.
Well, hopefully it will fix the occasional system lockup I've experienced with my G400 under 4.0.3
---
I've never compiled X myself ... but ... on RPM-based systems, it seems like building from source would screw up RPM dependencies, and you'd have to use --force or --nodeps to install all X apps. Is that the case?
:-)
If so, I'll wait for Red Hat's release.
---
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Cool, I think i'll deploy it then! Just as soon as you supply me the five figure sum i'll need to do so....
I think the point here is that they licenses differ in who or what the freedom applies too. In this case the freedom appears to apply to the user for BSD while under GPL it is the code itself that has freedom.
XFree86 4.0.3 does not include Mach64 render code, so there is no anti-aliasing or anything.
While XFree86 4.0.3 does not have RENDER for Mach64, CVS does. I am running right now on this laptop. Used the antialias howto on dot.kde.org -- everything under 8 and above 12 is antialiased, it is sweet. And since I'm on an LCD subpixel antialiasing makes small text MUCH clearer than standard greylevel antialias.
I would love to know how to turn on antialiasing for any italics regardless of size; I tried a few variations of the configuration outlined on dot.kde.org but nothing seems to work. If anyone has any success here, please let me know.
EEK! Mike Harris is the premier of Ontario, Canada. And also I guy I hate. Now he's working on Free Software?!?! What is the world coming to....
If memory serves there used to be a Mike Harris hanging around either FidoNet or DragoNet in the 519 area code. His .sig was always "No I am NOT the premier of Ontario".
FidoNet... Christ... 1:221/[something].77 was my point.. I forget how the addressing works now. That was YEARS ago.
n hour? That's nothing - KDE2.2alpha2 takes about 16 hours to build! (no kidding - I started it building at 12 hours ago, and it's about 3/4 done)
What the hell are you doing? KDE2.2 compiles for me in about 2 hours. That includes manually un-tarring, ./configuring, and make/make installing. QT is by far the longest compile of the lot for KDE.
This is on a Cel300 with 256M of memory and running X. On my dual 450 it takes a little more than an hour.
I'm talking about ALL of KDE2.2, but just libs and base.
I understand that. How about this list?
(yes this is the 2.1 tree, and koffice wasn't included, that is a pig of a package)
Hmm... it could be because I'm using reiserfs - I'll try a build on my ext2 partition (I've got 5 GB free on there, so it's not prob).
The Dual466 system runs reiserfs on its data drive (actually 5 6.4G IDE drives in software RAID0 under LVM) -- I know that tail packing slows down reiserfs like winter does molasses; I have that (and atime updates) turned off.
don't think there's anything wrong with including a video driver in the kernel. Tying the kernel to a desktop is another story. The Linux framebuffer console is how video should have been all along. No need to be root in order to access the display. This is probably good for security as well as stability.
I'm mixed on the issue. Drivers are drivers, this much is true. Just because they are video drivers doesn't mean they don't belong in the kernel. (Hell my nVidia card has to have kernel drivers.)
At the same time, however, I think it hampers the rate of development for newer, faster and better drivers (video or otherwise). Video drivers especially change quickly as newer cards come out. It's not like SCSI or IDE or sound or network interfaces... they all seem fairly "standard" -- Video still seems to be a fast moving target.
I suppose you are vastly superior.
Stating on Slashdot that I like cheese since 1997.
Um, not quite right...the BSD license allows people to make non-public changes to source code, and release software binary-only.
If you, the software author, don't really care if someone ships your project binary-only, and further, makes whatever changes they desire without sharing with you, then yes, the BSD license is more free. Releasing under the BSD license certainly makes more sense than releasing under the GPL, then turning your project into abandonware. Or releasing under the GPL, then giving blanket permission to do with the source as you wish.
Stating on Slashdot that I like cheese since 1997.
"Kernel Drivers do not have to be under the GPL"
They do if you want them distributed with the kernel source tree.
OpenVerse Visual Chat: http://openverse.org
-- OpenVerse Visual Chat: http://openverse.com
X11 lacks such basic features as totally integrated anti-aliasing (extensions, in general, suck)
/me looks at his dust-covered BeBox.
Please. Extensions rule! They allow you to incorporate new features while keeping backward compatibilty. Who would have though that X would be getting a Plan9 based 2D rendering system with hardware accelleration, alpha blending, AA text, and whatnot!! Extensions made this possible.
X11 lacks a standard toolkit
Blimy, that's a feature!!!
X11 lacks high performance
Mwuhahaha, that's bullshit! My NVIDIA card is as fast as in Windows (2D and 3D), muuuuuuuch faster than in BeOS (since BeOS lacks MTRR support for AMD CPU's/chipsets and is generally AMD optimization challenged). I don't know if I should take anything you say serious these days. I have the feeling it's simply a side effect of your bitterness and/or frustration with the Be situation, seeing you call yourself "be-fan". I feel for you.
low memory use, and low latency.
Dude, my X server eats a whopping 5MB at startup. Pixmap caching and other stuff lets the process grow, but hey that's what bloody RAM is for no? As to "low latency"? Huh? This isn't audio we're talking about. If you mean "responsiveness". If X is not responsive enough for you recompile your Linux kernel with HZ = 1000 (which gives you 1ms timeslices instead of 10). I can only speak from my own experience and that is that X is smooth as Silk these days. (BTW, Make sure your X server has "SilkenMouse" enabled)
I just recorded a full 2 hour of the NBA playoffs from my BT848 card, all while happily browsing and compiling away. Not a *single* audio/video frame was dropped. Converting the Nuppelvideo file to DIVX as I type this. Gotta love it! I smell a MediaOS in the making *grin*
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
/usr/src/linux/include/asm-i386/param.h
:)
Simply put an extra 0 on the HZ #define line. Make sure you recompile everything (including your modules). BTW, HZ is already at 1024 for Alpha architectures. Looking forward to that becoming standard on x86 as well with 1GHZ+ boxes becoming standard and all
As for the "SilkenMouse" option, it is on by default on XFree 4.x but you can enabled it with Option "SilkenMouse" "1" in your device section.
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Oops, you're not. I've tried, but lameness filter is apparently too strict to allow posting this. :(
--
"Man in the Moon and other weird things" - wfmh.org.pl/thorgal/Moon/
Sure, if the fbdev code was accelerated "enough" and supported all the primitives for 3D and whatever else they want, then it would be easier. If or course fbdev was on all the OSes they wanted XFree86 to work on. None of that appears to be true.
Now they could divert that effort in making and extending graphics drivers from X to fbdev itself, but that would limit the OS choice and be a whole lot harder. Writing kernel code is very painful compared to writing user land code. Actually it isn't the writing that is so hard, but the debugging. My relatively few kernel modifications have taken about 4 to 5 times longer then I had guessed to debug, and I had already bumped the number up because I thought I knew how hard it would be...
Plus XFree86 is used by a lot more then just Linux, and I believe many of the XFree86 commiters are not Linux-only users (in fact the only XF86 commiter I personally know is a rabid anti-Linux zealot). So I doubt they would want to abandon support for OSes that didn't have a usable fbdev.
One small point in this arguments favor is that they have a fbdev driver, and have continued work on non-fbdev drivers.
So it seems to be the lesser of N evils to essentially have a user land device driver of inordinate complexity.
Yes the driver probably will need to be open-source. However it appears that after you have basic "turn this pixel this color" support, everything else in the interface is like "send this value to this control register". This will allow the "secret" stuff (ie what numbers to put into what control registers) to be put into a user-level "accelerated graphics library" and remain closed-source.
1. Add a new call to set the current font, with an intelligent interface. But both this and the "old" (xlfd) call update the same internal data structures, ie you don't need to know what call was used when drawing anything.
Antialiasing just works after that, as long as copy or replace pixel transfer mode is on. Setting xor mode, etc, turn off antialiasing. This is what the much-derided MicroSoft did with their calls (they did not always support antialiasing), I see no reason X cannot do at least that well!
To support Unicode, I would make the interface take UTF-8 encoding ALL THE TIME. However there are no "errors", instead illegal sequences of UTF-8 are printed as individual bytes. This would support ISO-8859-1 encoding just fine, there needs to be 3 accented characters in a row to make it accidentally think it is a UTF-8 character.
X11 lacking a standard toolkit is a feature, just like you said. One problem with a lot of this crap being added to Xlib is that everybody says "but Qt will be adding support really soon". This does not cut it, I don't want to be forced to use Qt anymore than I want to be forced to use MFC.
All of you, cut it out! This has been argued over and over, even if you're only counting the last few weeks of Slashdot. Some people like the GPL license and consider it more "free", some people like the BSD license and consider it more "free". Arguing about it some more isn't going to help, and it's off-topic here.
Also known as mharris@redhat.com.
-30-
You can have multiple X servers running, one in each virtual terminal. I have a set of scripts that automatically launch a new X server with some minimal twm setting, so as to run applications full screen: view DVI/PS/PDF documents, JPG/GIF pictures, HTML documents with embedded pictures, play games, etc. Very handy when you're in a console switching period and your preferred window manager is the linux kernel's virtual terminal facility.
In case you don't want to roll your own from scratch, I can make my scripts available on request: they work very well for me, although it would require quite a lot of work to package them into a RPM, and you'll have to dig the CVS for versions that used to work with older X setups.
Unix sucks so much.
-- Faré @ TUNES.org
-- Faré @ TUNES.org
Reflection & Cybernet
whoop whoop, pitty there isnt any decent nvidia 3d support on freebsd yet
The S3 Virge drivers have had pixel corruption on some cards for as long as I can remember (since the inception of the Virge, basically). I don't know of a fix.
Why bother with the framebuffer? Do what I do - run two X servers. I have a 1600x1200x24bit server for my desktop, and an 800x600x16bit server for games. And you can flip between them with Ctrl-Alt-F7/F8, so you don't lose that functionality either.
I haven't been able to tell, unfortunately - the CVS versions of DRI SEEM to have had the xv problem fixed...except that I can't use it to tell for sure. It appears there's a severe bug in Banshee chipset support (but reportedly Voodoo3/5 is working okay). If they only sync'ed up the DRI with the rest of Xfree86 two weeks ago, I'm guessing the problem I'm running into is still in there... Still hoping the DRI guys manage to get the Banshee support fixed soon...
---
Hacker Public Radio is our Friend
And how do you enable it?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I have a question, maybe you can help me. I still run Xfree86 3.3.6 (or so), and I'm quite happy with it. However, playing movies full screen doesn't work too well. Is X 4.x much faster, so I can really enjoy movies (avi/DivX mostly), or isn't there much difference with 3.3?
-- Cheers!
I use aviplay and the Realplayer.
-- Cheers!
You'd think that, having been around for so long, he'd know better.
Easy explanation: He's a Slahdot editor.
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Don't bother downloading the README, nothing interesting there. It's source only, no binaries yet. Also no change log or release notes either, so you'll have to wait to find out what's new.
One notable new feature of XF 4.1 (for me at least) is that it is the first release to include Alan Hourihane's work on the glint driver that supports the SGI Flat Panel + 3dLabs Oxygen VX1 combo. I've been using my flat panel with CVS XFree86 for a while now and it rocks.
If your card is supported by XFree86 4.x it is REALLY worth an upgrade.
XFree86 4.x is actually a pretty much totally new architecture, and is faster in both 2d and 3d. It also have some really nice new features. Like the render-extension for smooth fonts, DRI for smooth 3d, seperating drivers from the server (4.x uses one server for all cards, just with different drop-in drivers).
the other video players that use avifile play divx/asf much faster for me than aviplay. You should give Mplayer a try.
Probably what would make more sense would be to ditch the kernel fb drivers and instead have XF86 export a low level API to it's drivers that could be used for games and a frame buffer device.
I compiled 4.02 and then there was 4.03 and it promised features that made it worth compiling. Sure I got reasonably fast computers (an alpha and an A1200 among others) but even on a fast machine it takes almost an hour! That could several hours for PC users. What gives?
I dunnot about 4.1.0, but DRI 0.7 has supported my Voodoo3 2000 AGP much better with XVideo, i.e. my
xawtv (bttv driver) works as well as all sortsof media players that had problems before.
XML is like violence. If it doesn't solve the problem, use more.
XFree86 4.0.3 does not include Mach64 render code, so there is no anti-aliasing or anything.
The README states that you can update to 4.1 from 4.0.2, but it doesn't mention if it is possible to update to 4.1 from 4.0.3.
At home, I am running 4.0.3 on a Voodoo 4500, and it is *nice*. Excellent font anti-aliasing, and fast to boot. At work, because of the ATI card, it works, but without anti-aliasing, so everything looks crap. I have a TFT monitor at work, so Render + sub-pixel antialiasing would be great - anyone know if sub-pixel antialiasing works in Render?
XFree86 is an X11 system for Unix systems, not just Linux. Linux has a kernel framebuffer device (can anyone say Windows?), whereas other Unix variants leave the drivers up to XFree86.
Also, anything in the kernel would have to be under the GPL. Say goodbye to NVidia support.
Just curious...where did you grab this from?
It's 10 PM. Do you know if you're un-American?
"kick ass" as opposed to what ? What other alternatives do exists ? that's about the only complete & standard graphic API on Unix. There's 0 competition, except maybe for Windows which push the XFree group to add some features sometimes (like DRI).
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
And really, the basic theory is sound. As you point out, as computers get faster you can use that speed to make old programs run faster or to make new programs possible at the same perceived speed. Sure, Excel's a pig, but 99 times out of 100 I'd rather use Excel than Visicalc.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
Two mirrors that worked for me:
Hey, no fair, it's news for us BSD people too, and don't forget about those 2 Solaris X86 people.
I agree, when a fairly major release like this comes out, I like to know. It's not like XFree gets updated every week or anything. And this affects everybody, now if only they'd actually do a little research and tell us what we might be interested in in this release...oops, but this is Slashdot. I guess that's asking too much.
Riiiiight ... and so the new features are?
It's not very useful to just list the bugfixes of the last three days, when nobody knows what new features there are in 4.1.0. Okay, so there were over 600 bugfixes, which probably makes it worthwile to upgrade. But apart from that?
Isn't there anybody here who has a bit more insight into XFree who knows what stuff is to expect? Antialiased fonts maybe? Other stuff?
EagerEyes.org: Visualization and Visual Communication
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
A deep unwavering belief is a sure sign you're missing something...
Umm, does that mean X can't switch resolutions even when running a full-screen game or something? Meaning if I want to play Quake III at 800x600, I have to restart in that mode before starting the program?
A deep unwavering belief is a sure sign you're missing something...
transparency, documentation and portability...
>>>>>>>>>
99% of the world doesn't consider network transparency a "basic feature." 99% of the world doesn't consider portability a feature. Windows GDI is more well-documented than X11.
X11 lacks such basic features as totally integrated anti-aliasing (extensions, in general, suck). X11 lacks a standard toolkit. X11 lacks high performance, low memory use, and low latency. Most people consider these to be far more important feature than the server or scientifically oriented "features" you specify.
A deep unwavering belief is a sure sign you're missing something...
For all practical purposes, they do. They have to be open source in order to avoid the driver API of the day syndrome Linux has (or the company distributing them has to maintain dozens of different versions, like NVIDIA). In addition, the kernel developers are outwardly hostile to developers of closed source drivers (as evidenced by a recent kernel traffic thread) and the legal implications of closed source drivers linking to a GPL kernel are sketchy at best.
A deep unwavering belief is a sure sign you're missing something...
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
>>>>>>>>
I never said what was the case in practice. Theoretically, UNIX is much more abstracted than Windows. Stuff like DirectX is a good example. Again, I don't say that DirectX is good or bad (I personally love it) its just a lot closer to hardware than anything in UNIX.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
>>>>>>>>>
First, features do not necessarily cause slower more bloated code. Take QNX Neutrino as an example. Secondly, lessening the work of the developer through abstraction is a decent idea at the application level (although too often the abstraction is overkill and the performance hit is large. Take CORBA for example.) However, this thinking doesn't make a lot of sense at the OS level. The OS is largely the limiting factor in most I/O or CPU limited applications, and abstracting at the OS level creates a least common denominator effect. I don't much mind if my ICQ program is a little hefty (as long as the gain through abstraction offsets the performance hit) but if the OS causes my well-tuned 3D renderer to perform poorly, no amount of abstraction in the OS can justify it. The very reason people still use C for OS kernels is that it is almost as fast as ASM, and provides a decent amount of abstraction. Thinking that more CPU power entitles one to create more administrative overhead in the OS simply keeps the user from taking full advantage of his (often expensive) hardware. In concrete terms, if upgrading my CPU from 300MHz to 1200MHz results in a theoretical halving of rendering times, then I don't want my OS cutting in on that gain.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
>>>>>>>>
If you're CPU is 90% idle, you're wasting the power of the computer. You're also not doing video or audio editing and 3D animation.
A deep unwavering belief is a sure sign you're missing something...
Kernel Drivers do not have to be under the GPL
That's probably true
They are denying Anonymous access now. I guess they wanted to avoid the Slashdot affect as much as possible.
"Imagination is the only weapon in the war against reality." -Jules de Gautier
I don't like reading Freshmeat. Too much crap
WHAT?! You mean you didn't like this week's 4 dozen incarnations of MySQL enabled MP3 playlist maintaining programs? You must be crazy...
---
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
We totally need a Web site with this format: http://www.fileflash.com/index.aspx?action=headlin es ... FileFlash shows all the popular Windows applications.
:)
I just want the title of the program with version numbers, date, time, and links.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
A newbie question here... Is it pointless for me to upgrade? I am using RH Linux v7.1. Thanks.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Now that 4.1 has been out a while, has anyone established what the situation really is with AA - I would really like it for the Mach64, but won't risk CVS stuff. Sim
um.. way WAY offtopic...
Hmm, very good point. I think far too many people who read slashdot are under the illusion that it is a community-controled environment. It is not, has never been, and was never claimed to be.
True, Malda accepts people's opinions and input, but when it comes right down to it, (and Malda has said this many times before) Slashdot is about what Mr. Rob Malda finds interesting. He has publicly stated too many times that those who don't like Slashdot's content should just go and find another website to first-post. Like Kiro5hin.
(Oh, and the new Freshmeat design has a way that you can "subscribe" to various projects and get sent an email each time there's a new release. It's extremely handy if you just want to watch a few projects.)
Ahem... Care to search which other OSes use Xfree?
--
Artix
Your Linux, your init.
(And at the API level, there were no major changes in X11R6.6 - it was mostly fixing bugs and adding donations of code from Sun & DEC to implement improved non-English language support and accessiblity support for handicapped users.)
The BSD license Locks up any code so that people can't view it.
Really?
I can look at FreeBSD source code all day long.
Apple computer, under Steve Jobs has allowed the closed NeXT code AND the FreeBSD (Plus open and netbsd) to be viewed.
2 examples disproving your claim.
The GPL ensures that you cannot change the original intent of sharing the code,
Lets see:
In the linux kernel 2.0 series, you can find part of the TCP/IP stack where the BSD copyright was removed and a GPL license was instead put on. The ORIGINAL intent of the BSD code was that the license be preserved, and in this case, the GPL takes that away.
How about the Virgin webplayer? The license that shipped with the box violated the GPL and they would not release the source code.
2 examples of how the GPL does not offer the 'protection' you claim.
If you argue that the BSD license is more free, you are mistaken.
As you seem to be confused, perhaps you can understand this:
Humans are a tool using species.
Software is a tool.
The BSD license puts the rights of the human to use the tool ahead of any rights the tool has. In fact, the rights attached to the tool are associated to having the human who made the tool be remembered.
The GPL license puts the rights of the tool and how it shall be used ahead of the humans desire on how they want to use it.
I have more faith in humanity than you must have.
I perfer the freedom to choose ones path over forced servitude.
If it was said on slashdot, it MUST be true!
First of all, I don't think I have ever found anyone who has ever come up with an accurate analogy for anything. When you compare totally different situations, there is allways some type of error. In your case, everything you said is pretty much in error. "balance freedom" is basically a bullshit term for limiting freedom, just like "special needs" is for retarded kids.
Software that you write is not sitting in Africa being bombarded by gun toting rebels and neither are you, so don't try to compare the two. If you want to write software and release it under the GPL, fine by me. But the truth is it is not as free as when you would release it under BSDL. The people who use your software are under a restrictive license, and I call that a restriction of freedom. And what do you get from this? You don't get anything personally from it except that you get to see your GPL community grow and the source remain open. Comprimising of freedoms is fine, but it means that someone's rights are restricted out there.
If you used a BSD license, you don't lose any freedoms by allowing people to incorporate your code with their product. Its not like they are taking credit for your work...they still have to include the original license with the source and binary and cannot relicense the code. I think you are getting the terms "rights" and "preferences" mixed up.
Buying a Dell computer is equivalent to dropping the soap in a prison shower.
I've been having some issues with pixel corruption while running xfree 4.0.3-3 on a S3 virge/DX and got the same problem on a S3 virge/GX videocard.
;).
The DX has 2 MBs of memory and the GX has got 4. The problem is worst when I set the colordepth to 32 and reduces when I decrease the colordepth. It's also slightly better on the GX board than on the DX one.
I'm using the GX board with a colordepth set to 24 now and it's quite usable. Still, it would be nice if this would be fixed. Anyone recognise these problems? Know if they're fixed?
Some more info:
I'm running Debian Woody on a AMD K6-2/233 with 32 MBs of RAM. Also, I tried to file a bugreport, but that was during the time the site was down and I neglected to do it when it came back up (shame on me
If there is hope, it lies in the trolls.
antialiased fonts were in 4.0.1, though admittedly kinda buggy until 4.0.3.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
my X4 debs have annex's unofficial ppc drivers in them, and can do mach64. 4.1. will also have these fixes in them afaik (it has all of his other work, so I'd assume).
http://www.penguinppc.org/~puetzk, you want the xserver-xfree86 4.0.1-7puetzk package.
The rest you can getfun testing (it should work, even though testing is now on 4.0.3 - ymmv, I moved on and am running pre-4.1 cvs).
or, as I said, 4.1 oughta work out-of-box, I can't see any reason his mach64/ppc fixes wouldn't be in when all the other cards I have made it.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Modelines and LCDs are a long running problem for X. Very few laptop makers provide the documentation needed to get these configured entirely right. There is little X can do beyond begging, pleading, and asking customers to beg and plead. Threats don't work.
If the driver for your chip supports gamma (not all do), you could try various gamma settings. This is not really brightness controls but might accomplish what you need.
(From ChangeLog:) 560. Resync with DRI CVS trunk (VA Linux Systems).
____________________
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Yep it's in 4.1, AA fonts look nice under kde.
oh, and hardware cursors are in too! Simcity3k is now quite playable :-)
Anyone know if this release will finally have the render extension for mach64 based ATI cards? I heard it was in cvs but never had the time or energy to grab and compile it. Also support for hardware cursors would make me a very happy too (SimCity3k is quite brutal without it, and the game's software cursors are too sluggish)
What you speak of is called a restriction, which means that the freedom in restricted in one form or another.
If you lived in an area such as Afghanistan, with nothing restricting guerrillas from the other side from killing you, would you consider yourself free? In order to have freedom from, say, being murdered, people need restrictions on them such that they do not murder each other. Those in charge must balance freedom and security to create an optimal symbiosis.
(Insanely long copyright duration is not balance.)
"Windows XP: eXtremely Pathetic." -- Anonymous CowardWill I retire or break 10K?
And it's not like I sacrificed anything by doing so. Linux (Mandrake to be precise) works perfectly in the firewall/router/NAT role its in. Probably much better than W2K server would in fact considering the hardware I'm running it on.
The guy who inserted those keys didn't like the Content-Type thing :-).
Anyway, it's propagating well. Slashdotted!
You can get the README here
I've been following the latest DRI updates (binary) from http://dri.sourceforge.net and currently the only version available is for 4.0.3 (obviously).
:)
So my question is: How new are the DRI drivers included in 4.1.0? Should I assume they're the current CVS from the DRI project? Could someone please verify this before I destroy my current drivers?
Thanks!
>if X is not responsive enough for you, recompile your Linux kernel with HZ = 1000
Where in the kernel do you make this change?
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
So how about it, or should I start dragging the whole thing from the US (into Sydney) over my 56k beast.
Also, I'd like to add voice to the growing list of complaints about slashdot releasing release announcements before they're officially released from the real releasers. Really, this is unnecessary and as others have pointed out, screws up the icing on the cake for those who deserve it. And that thing about linking to a readme file on the main ftp server - that sux big time. Even I wouldn't have done that.
Anyway, congrats to the xfree86 team. Oh - and has anyone tried this thing with nvidia's drivers?
ftp://ftp.calderasystems.com/pub/mirrors/xfree866
ftp://carroll.cac.psu.edu/pub/XFree86
ftp://ftp.cs.umn.edu/pub/XFree86
ftp://download.sourceforge.net/pub/mirrors/XFree8
ftp://ftp.freesoftware.com/pub/XFree86
ftp://ftp.infomagic.com/pub/mirrors/XFree86
ftp://mirror.sftw.com/pub/XFree86
ftp://phyppro1.phy.bnl.gov/pub/XFree86
ftp://ftp.rge.com/pub/X/XFree86
ftp://ftp.valinux.com/pub/mirrors/xfree86
__
xgamma / startx -- -gamma x.x. do not seem to work.. the discussion continues in comp.os.linux.x.
--
I hit the karma cap, now do I gain enlightenment?
Escher was the first MC and Giger invented the HR department.
I have gone through a number of docs and searched google, but nothing seems to be there. So if/when your answer is the usual RTFM, please let me know which FM.
--
I hit the karma cap, now do I gain enlightenment?
Escher was the first MC and Giger invented the HR department.
I have to agree here, /. does a good job of letting us know of the major releases, and they are usually quite quick (eq, like with X410 :)
:)
btw, i'm downing it right now from planetmirror.com, yay!
Read the faq (the slashdot faq)
Yeah, yeah, let me say it all for you:
"What is this, Freshmeat or Slashdot?"
"How is this news? This is just a point release."
"This isn't news, this is software."
"This is only for Linux users."
"Even Linux users don't care much about this."
Well, I for one THANK Slashdot for letting me know. I like to be informed when 2.4.next is out, and the same goes for XFree86 4.next. Some people may be bugged by it, but I think Slashdot strikes a nice (if tricky) balance between overcovering software releases and keeping a large portion of their readers (Linux users) up on the latest.
I don't like reading Freshmeat. Too much crap when all I care about is really Kernel and XFree86 most of the time. I check into Slashdot once a day or so, so I'm glad slashdot lets me know when new stuff is out. Saves me from having to wade through Freshmeat, monitor the kernel mailing list, continually check the XFree86 Web site, etc...
I also like the distribution release announcements that are here sometimes.
So nyaaaaaaaah!
STOP . AMERICA . NOW
I don't think there's anything wrong with including a video driver in the kernel. Tying the kernel to a desktop is another story. The Linux framebuffer console is how video should have been all along. No need to be root in order to access the display. This is probably good for security as well as stability.
While I don't have much experience with other unices, I do believe that there is a concept of a framebuffer in most other variants. I heard somewhere that Linux was the one of the later OS's to get such a thing.
As for GPL issues, aren't there ways to load closed source kernel modules? They could be distributed "precompiled" for various kernel versions, or some sort of wrapper module could be compiled and linked against a closed source driver.
-Justin
Hey, does anyone know if there have been any improvements into getting XFree86 to play nice with the Linux framebuffer console?
Currently, I feel the best way to play a full screen game is in a virtual terminal under fbdev rather than through X, so that I can keep my desktop and the game separated. Ctrl-Alt-F3 takes me to my game, and Alt-F7 takes me back to X. Plus, the high-resolution framebuffer console is very cool just for shell usage too.
Unfortunately for me though, the XFree86 driver for my card clashes with the framebuffer driver from the kernel. So in order to have my super-cool framebuffer console *and* X, I have to use the fbdev version of X. This works and all, but it is unnaccelerated which means I can't do much. Fortunately, most of the games I have are SDL based, so I can just flip to a console to play. But something like OpenGL? Not a chance.
Now can anyone explain to me why there are two video drivers on my system to clash in the first place? It seems logical to me that everyone should use a framebuffer driver (I have a Voodoo3, and it is supported in the kernel) and that X should ride on top. The kernel has every other driver, so why is the video driver so special that X has its own?
Wouldn't it be easier for the XFree folks if they didn't have to worry about making video drivers, and instead it was all taken care of by the kernel? IMO, the only driver they should develop is the fbdev version.
Anyone else have any insights to this? Any reason why DRI couldn't be applied to an fbdev Xserver?
-Justin
I know it just got released, but how long before the packaged distributions will have this, do you think? I was already thinking of waiting a little longer for RedHat 7.2 anyway... Anyone got any good insight about the turnaround time for important software releases and when they make it into the commercial distros?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Anyone know if Tuxracer will finally play at >0.2fps on my Radeon machine?
Well, I'm using an ATI Xpert@Play '98 card right now, using the Mach64 drivers. But I'm not on a Mac, now am I? Why not just try xf86setup?
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
570. Add euro locales and some other missing locales to locale.alias and locale.dir (#4662, 4665, 4667, Mike Harris). 569. Fix Romanian XKB map (#4664, Mike Harris). 568. Spell Portuguese correctly in XKB lst files (#4663, Mike Harris).
EEK! Mike Harris is the premier of Ontario, Canada. And also I guy I hate. Now he's working on Free Software?!?! What is the world coming to....
--Volrath50
I stayed with 3.3.6 because 4.x.x refuses to find my Compaq's ET4000w32, even though it's supposed to still be a supported card.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
go to linuxtoday.com and get the changelog. it has a list of all the new features and drivers. enjoy.
What comes first, finding a teacher or becoming a student?
AFAIK the documentation remains silent in all languages about the RENDER extension on MACH64s. However, the file xc/programs/Xserver/hw/xfree86/drivers/ati/atiscre en.c does not mention the RENDER extension in 4.0.2/3 but it does in 4.1.0:
So if this fbPictureInit call succeeds we will have anti-aliased fonts, won't we?
Recent Changes to the XFree86 4.1 branch
Below is a recent extract from the XFree86 change log for the 4.1 branch. The full change log can be found in the XFree86 source tree (xc/programs/Xserver/hw/xfree86/CHANGELOG).
XFree86 development code can be accessed directly from the CVS repository. Information about this can be found on our CVS page.
XFree86 4.1.0 (2 June 2001)
619. Disable PCI resource conflict checking for Linux/Alpha (Jay Estabrook).
XFree86 4.0.99.902 (1 June 2001)
618. Fix Linux xf86GetPciSizeFromOS() parsing when the kernel is 64 bit
and any base or size is larger than 32 bits in magnitude (#4732,
David S. Miller).
617. Make XDarwin ddx pass up proper right and middle mouse button numbers
and fix mouse button 5 (Christoph Pfisterer and Torrey T. Lyons).
616. Restore backwards compatibility from 4.0.[2,3] to 4.1.0 for
the i810, r128 and radeon DRI drivers (Gareth Hughes).
615. Fix a problem when using patterns of horizontal lines with the mga
video overlay (#A.442, Ewald Snel).
614. Xinstall.sh updates and bug fixes (David Dawes).
613. Remove duplicate XineramaLibrary section in X11.tmpl (#4731,
Mike Harris).
612. Enable building DRI for Linux/ppc, and fix a drm-related bug
for Linux/ppc (#4728, 4730, Michel Dänzer).
611. Document Options for the r128 and fbdev drivers (#4727, 4729,
Michel Dänzer).
610. Add a BuildBindist switch which causes a file containing the XFree86
version number to be installed in ProjectRoot, include this in
the Xbin bindist tarballs, and turn on this switch in the bindist
host.def files. The purpose is to allow the installer script to
easily identify which version the bindist tarballs are (David Dawes).
609. Resync bindist and Xinstall.sh with changes made for 4.0.3 (David Dawes).
608. Fix the Shape extension's XShapeCombineMask to handle cases where
src_mask is None according to the spec. This reportedly fixes an
X server crash (#4715, Huver).
607. Make sure -UXF86DRI is after -DXF86DRI when compiling vfb/miinitext.c
(#4714, Frederic Lepied).
606. Fix ATI Radeon driver on Alpha. Seems as though the BIOS doesn't
like Re-POSTing and memory setup gets confused. (Jay Estabrook, Jeff
Weidemeier)
605. Fix build for Cygwin/XFree86 (#4711,#4713 Harold Hunt).
604. Fix problem with Xinstall.sh on Darwin 1.3.x (#A.431, Stefan Pantos).
603. Update Xinstall.sh and Darwin bindist directories to optionally
install Quartz support and to add an x86 distribution (Torrey T. Lyons).
XFree86 4.0.99.901 (29 May 2001)
602. Add missing return value for miSetPixmapDepths() (#4708,
ISHIKAWA Mutsumi).
601. Fill in the v4l man page template with some useful information (#4707,
Gerd Knorr).
600. Fix FFB OpenGL SwapBuffers (#4705, David S. Miller).
599. Work around a problem building the rstart specs doc with a symlinked
build tree (David Dawes).
598. Remove SPARC-specific byte-swapping code that would not work on older
SPARC CPUs (part of #4653, David S. Miller).
597. NULLify mapVidMem() and remove DEV_MEM #define for Linux/SPARC
(#4651, David S. Miller).
596. Fix Glint 300SX+Delta support. Add faster 500TX text acceleration
based on other code (Alan Hourihane).
595. Fixing MTRR split code (hopefully) (Egbert Eich).
594. Fixing coredump when doing vbeFree() twice: S3 Virge and C&T
(Egbert Eich).
593. Fixing HWCursor for mga driver in fbdev mode (Egbert Eich).
592. Fix xmh's use of XtNewString() with getenv (#4694, Tim Waugh).
591. Xdm/PAM fixes: leave it to PAM to observe whether or not an account
is locked, and reinitialize credentials after calling initgroups(),
because sometimes the credentials pam_setcred() gives are in the
form of group membership (#4693, Mike Harris).
590. Add an encodings file for standard box drawing characters for
VT100-compatible terminals (#4691, Juliusz Chroboczek).
589. Fix warnings when building mieq.c (#4689, Adam Sulmicki).
588. Fix some bugs in the cz and sk entried in XKB's keymap/xfree86 file
(#4692, Ivan Pascal).
587. Add 'hr' entries to XKB's keymap/xfree86 and rules/xfree86.lst files
(#4687, Nerijus Baliunas).
586. Include in shape.h to get Region typedef (#4686,
Adam Sulmicki).
585. Acceleration fixes for GLINT Permedia1 (Alan Hourihane).
584. Ensure glint driver chips don't exceed the specified virtual sizes.
(Alan Hourihane).
583. Remove all VGA'isms from the glint driver, it doesn't need them
(Alan Hourihane).
582. Support the Delta in the glint driver, needed for boards that have
the Delta connected to the rasterizer, as it acts as an arbiter for
the bus. Resolves acceleration troubles. (Alan Hourihane).
581. Add an lv entry to XKB's keymap/xfree86 file (#4685, Nerijus Baliunas).
580. Fix some typos in XKB's xfree86.lst file (#4684, Nerijus Baliunas).
579. Add DDXOSVERRORF ifdefs to the XFree86 ddx code that make use of the
OsVendorVErrorFProc feature (#4678, Michel Dänzer).
578. Convert the r128 driver's "UseBIOSDisplay" option into a more general
"Display" option (#4678, Michel Dänzer).
577. Treat GL_POINT like GL_POINTS and GL_LINE like GL_LINES in the sunffb
DRI driver (#4677, David S. Miller)
576. Fix bsdLib.rules and bsdLib.tmpl problems that show up when
X11ProjectRoot is defined (#4676, Johnny C. Lam).
575. Fix Trident XVideo colorkey at depth 15, 24 (Alan Hourihane).
574. Fix a typo in the lv XKB description, and fix things so that it gets
installed (#4675, 4679, Andris Pavenis).
573. Fix some apm driver bugs, including one that prevented acceleration
from working (#4674, Loïc Grenié).
572. Fix 555 (depth 15) palette handling in the i810 driver (#4673,
Andrew C. Aitchison).
571. [SECURITY] Fix authentication issues with mmap() on drm devices
(Jeff Hartmann).
570. Add euro locales and some other missing locales to locale.alias and
locale.dir (#4662, 4665, 4667, Mike Harris).
569. Fix Romanian XKB map (#4664, Mike Harris).
568. Spell Portuguese correctly in XKB lst files (#4663, Mike Harris).
567. Fix new ioperm calls in lnx_video.c for Alpha that are not needed
(Jay Estabrook).
566. Fix problems with assembler file dependencies when using gccmakedep
with the build (Frederic Lepied).
565. Finish DRI resync, including tdfx driver updates for textured video
support (VA Linux Systems).
564. Fix formatting of max clock reported by DDC (Marc La France).
563. Update Japanese localization of XDarwin help file (Toshimitsu Tanaka).
562. Update XDarwin man pages, help files, and version info. Add option to
build XDarwin.app bundle for deployment (Torrey Lyons).
XFree86 4.0.99.900 (18 May 2001)
561. Add an XKB description for Latvian (lv) keyboards (#A.411, Ilya Ketris).
560. Resync with DRI CVS trunk (VA Linux Systems).
559. Savage driver updates, including compiler warning fixes, document
the "ShadowStatus" option in the man page, and fix an argument
mismatch between ShadowWait and SavageWaitQueue (#4661, Tim Roberts).
558. Update the wacom driver to add a "ScreenNo" option to allow a tablet
to be attached to a screen in a multi-head setup, and to add auto-
detection of USB line and max parameters of USB tablets (#4640,
Frederic Lepied).
557. Add a README file that has information about enabling the extra buttons
on the IBM Rapid Access keyboard (#4639, Dennis Bjorklund).
556. Fix some Slovene/Slovak confusion in locale.dir/locale.alias files
(#4638, Kamil Toman).
555. New XKB keymaps for cz and sk (#4634, 4637, Kamil Toman).
554. Updates for the iso8859-2 Compose file (#4634, Kamil Toman).
553. Check V_CSYNC in the r128 driver, and fix building with R128_DEBUG
enabled (#4631, Michel Dänzer).
552. Mesa 3.4.2 (and later) import.
551. More build & warning fixes (Marc La France).
550. Fix bug that caused hardware cursors to be temporarily moved during mode
switches (Marc La France).
549. Optimise HARDWARE_CURSOR_AND_SOURCE_WITH_MASK case (Marc La France).
548. Move xf86CursorScreenRec definition into xf86CursorPriv.h
(Marc La France).
547. Fix BIOS retrievals in MGA driver (Marc La France).
546. Fix ATIProbe() for newer Rage128 and Radeon chips (Marc La France).
545. Add temporary workaround in ATI driver for interrupts that occur on
PowerPC's upon PCI master-aborts (Marc La France).
544. Update XDarwin to use fb and support Render (Torrey Lyons).
543. Back out sunleo conversion to fb. This driver is too heavily dependent
on cfb32 for a simple fb conversion (Marc La France).
542. Miscellaneous build/warning fixes (Marc La France).
541. More prep work for SunOS (Marc La France).
540. Fix libXft build on SunOS (Marc La France).
539. Another makedepend bug fix (Marc La France).
538. Fix use of xftcache utility during !UseInstalled builds (Marc La France).
feast and enjoy.
-bacchusrx.
Life after capitalism? The participatory economics project
I only run 3.3.6 on my iMac because 4.0 doesn't support Mach64, or at least i cant make it work. hope hope hope
There isn't much like the scent of a fresh harddisk
I suppose VNC is a simpler, more practical alternative for most applications, but still. Running plain X11 for remote, untrusted applications can be better in some cases.
Why not take advantage of the computing power of todays fastest PC's? What you are asking is that we halt and stop all software development and contine to run Linux 1.0 for the rest of our lifes without adding features and improving. Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
Did anyone test if the XVideo Extension now in 4.1 works proper with tdfx (Voodoo 3 PCI) ? I couldn't get it working with the latest bttv driver and XawTV. There was a black picture or the X Server smeared down. On the other hand aviplay did work correctly in overlay mode.