Mike, you rants are allways a good read :) Mike A. Harris wrote:
What happened to the days when people under stood, that unsupported was just that?On Fri, 24 Jan 2003, Thomas Dodd wrote:I DO understand it can ever be an official, supported release, but what about an unfficial, unsupported one?If it is unofficial and unsupported, then it is something that I would be doing in my own personal spare time. I would get nothing but end user bitching about whatever doesnt work not working, and I'd also get bug reports regardless, and when I close them as "unsupported" I would get users bitching at me for not supporting it. No thanks.
As I said, I'm using your XF86 CVS packages. I also use rawhide, and kernel.org kernels.
I'd use straight XFree86.org and GNOME.org butit doesn't mix with the Red Hat setup.
Are people reall that stupid. If the put other parts on their car would the expect the dealer to fix them?
What is the world comming to?
it works great", then put up a web page and offer RPM packages for people. Or put up a "HOWTO make XFree86 4.3.0 run on Red Hat Linux 7.1" website. Go nuts. If it is so simple to do, and doesn't break anything or require updating 40 packages, then by all means put up an unofficial site and maintain it. It's all open source, and freely available.I would need disk space to install RHL-7.1 :(
I've been busy and haven't had a chance to move to phoebe yet, but I will soon.
product. One example, is for the most part, 8bit depth doesn't
8-bit? people still use that?
work properly in XFree86 4.2.x. This regression was never found until after products shipped with 4.2.x because nobody out there for the most part _uses_ 4.2.x. That is one example. Users who use RHL 7.1/7.2 who would upgrade to 4.2.x if there were to be an official update, who require 8 bit depth working, would undergo a regression and be upset. I'm sure there are other regressions"Do not use this package if you need 8bit color support" in the errata/enhancement announcement and in the change log. That should be plenty. If some idiot installs it anyway and it breaks, 'rpm -e' and then install the old packages.
If it were _simple_ to do that, and it didn't take 1000 hours of time, then I would already be _doing_ that. My work time is
I ment, change the variables to sutible values for a RHL-7.x system.
You know the innards of that spec file, and what would needWrong. It is a full time job maintaining that spec file. I
changed better than anyone. It would probably only take 15-30
minutes to write the instructions and change the file.
Who said maintain it. I didn't.
Just the drm files, built for the current kernel. You don't need the WHOLE kernel for those drivers. Since this is mainly for i830 users, only the i830 driver. I've done the same for r128, which hasn't changed much. The 2.4.18 kernels have the correct r128 drm code for the current XF86 code.If you can't, I guess someone on the list could. Perhaps aThey're more than welcome to do so. They'll also have to maintain their own kernel too, in order to synchronize it with the Red Hat kernel DRM, or else DRI either wont work at all, or wont work properly.
RHL-7.3 user can get XFree86-4.3.0 (when released) in a usable
state added to freshrpms.net.
The whole point of XF86-4.x was to seperate the drivers from the rest of X. So one could add support for a new card/chip by adding the driver, and possibly the kernel drm module, or you could fix bugs in a driver, and only need to change the driver. It works too. I've used the DRI snapshots, wich only change a few files.
The kernel has support for this too. In the middle of a discussion on redhat-devel about 3rd party drivers/modules andf kernel updates. Most of the time the modules for kernel-2.4.x will work without rebuilding in kernel 2.4.z.
Right, but the current kernel DRM sources would be patched/copied to the X build tree.If the proper DRM sources were in the XFree86 SRPM, instead ofI've thought of making X spec allow building of DRM a few times, but the XFree86 source code's DRM source is always ancient compared to what is in our kernel. Keeping it patched and up to
the official XFree86 ones, it's a simple build. The XFree86 tree
supports building outside the kernel tree, but is never up to
date. Could is be copied/linked to the XFree86 build root
(/usr/src/redhat/BUILD/XFree86/linux_drm ?) and patched during
the prep stage?
One would need to rpm -bp XFree86, the build the desire drm modules. The only automation is having the source handy, with X, instead of getting a 32M ,kernel SRPM, you just get the 1.5M of source you need. Or even a kernel-drm pakage with the 1.5M of source needed to build the kernel DRM modules.
How exactly do you stop users from using it that CANT do that?Well you can't. So you hide it a bit. Most lusers that you're talking about don't know to check people.redhat.com, let alone to look through the mharris directory.
Nice in theory, but before you know it 15000 people are trying to use it, wondering why 30 new bugs are there, and filing bugs in bugzilla against Xconfigurator or something. Bugs like "I upgraded XFree86 to 4.3.0 in RHL 7.3, as I have a Radeon 9000 and want it to work, but Xconfigurator can't configure it".Which are summarialy dismissed, marked WONTFIX / UNSUPPORTED, with a breif "XFree86-4.3 is not supported on RHL-7.3"
I've use unsupported drivers form ATi on windows boxes. The state they are unsupported, with a few known problem listed. There are also several windows related "beta" sites dealing with unsupported drivers for other hardware. Is ATi and other companies having that much trouble with them?
Am I to believe that windoze luser ae that much more intelligent than linux lusers?
Many bugs get reported that are totally USELESS. People report bugs like
"My X no works. It work yesterday, but no works now.:
Reproduceable: Didn't try
Actual results: X no works
Expected results: My X works
Additional info: To have X work
Maybe they are....
Wow, I just realized. Is this mailing list ever therapeutic. Thanks guys. :o)Always glad to help where we can :)
It's a bit depressing that linux, and Red Hat is attracting such low quality lusers. One of the reason I switched to linux was to get away for the idiot users and moronic support staff. I hope that the influx of idiots doesn't lead to hiring morons :)
-Thomas
_______________________________________________
xfree86-list mailing list
xfree86-list@redhat.com
https://listman.redhat.com/mailman/listinfo/xfree86-list
IRC: #xfree86 on irc.redhat.com
