they're too often in the context of their development cycle - remember "every commit triggers a build + automated testsuite" or something along the lines.Ever since I read ESR's view on the American military and its major oversteppings, I just hate the guy, but he's got a few things about software development very well. "Release early and often". That probably means, more often than each month, each time with 4-5 who-gives-a-crap fixes. It means, "for each change you make", basically.
that effectively slows down development, i'm afraid. besides fglrx is not open source.
if it were they could release early and often. people could just fix the bugs themselves, having access to the source. this is not a esr's bazaar model where you can release early, release often.
I never really much problem with the installation process. It is the editing of xorg.conf that can be horrible.
Though, I do have to admit, compare to almost 2 years ago, the situation does improve a bit. I don't really have to hack the xorg.conf file that often.
Actually, reading these few exchanges, I am curious, if you are to upgrade a new release of kernel, how to install the fglrx? Did you run the whole installation process or go to /lib/module/fglrx and manually run the make.sh and make_install.sh (or simply copy the fglrx.ko to the appropriate kernel modules tree)? I did the later.
Last edited by lenrek; 08-14-2007 at 07:54 AM.
And that DOES fit into the bazaar model. Because including the right header files or whatever is needed to build against a certain kernel or Xorg version, will in some cases (perhaps most) not require any changes to the closed part, but only to the glue.
Instead we're left in the forum discussing what doesn't work for FC7, FC8, Slackware 47 etc... Which is nonsense. Someone makes a hack which makes fglrx work against a certain kernel+distro setup, instead of people working together fixing the glue-part of the driver in the first place.
This just sickens me.
m-a a-i fglrx
and reboot (or unload, load fglrx module and restart X)
Man, I spoke too soon. Turns out that this release is even worse than previous for me.
The console switching bug now affects me; that's in direct opposition to the claim in the release notes that this issue was 'resolved' by this driver. It had never happened to me before this driver.
There was some very annoying mouse bug that cropped up where the vertical distances for the mouse were skewed (the further down the screen, the larger the offset between the pointer was drawn and actually clicked).
And finally not only is the 'no signal' display-init bug still there, it seems to have regressed. Previous releases actually had the EDID hex dump fill up where this one went back to mostly 0s.
Any driver that even tries to work with the 1.3 server thinks I have a crt1 and tmds1 connected when only the latter is connected. Under older servers it works just fine.
I have a very hard time believing future versions will improve for me. They claim to make progress but now I get more bugs than ever. I'm going to see how the free drivers are doing, and if they aren't working well enough I guess it's time to jump on the Nvidia bandwagon.
Just found out that fglrx 8.40 only works on my 64Bit Sidux for me. I won't try anything to fix that, I just wait :P
Important question - is x86_64 driver finally working properly? Anyone tested this driver under x86_64 machine with FC7? I guess its working fine on i386 FC7?