Slashdot Mirror


XFree86 Politics

Pivot writes "Keith Packard wants to fork the XFree86 effort. 'It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team.' The XFree86 team is trying to become more open, to combat the fork. Keith is a capable developer, having worked on FontConfig, Xft, the X render extension etc. Meanwhile, All is not good in how XFree86 drivers are being developed. Anyone remember the GGI initiative a few years back, and the uproar it caused?"

18 of 357 comments (clear)

  1. Mike's diary entry by dd · · Score: 5, Informative

    Mike Harris is a bright guy, as anyone who has followed the various Red Hat mailing lists over the last few years will know. When he speaks out like this about the inadequacies of the development process of XFree86 we should all stand up and take notice. Be sure to take the time to read the advocago link in this story.

    1. Re:Mike's diary entry by Anonymous Coward · · Score: 3, Informative

      And all of a sudden, there's a bugzilla at xfree: http://bugs.xfree86.org/

    2. Re:Mike's diary entry by MonkeyDluffy · · Score: 2, Informative
      Bugzilla dosn't solve everything. Moz bug #69938 is over two years old. And still not fixed.

      -MDL

      --
      Happy meals fund terrorism
    3. Re:Mike's diary entry by vocaro · · Score: 2, Informative
      The hooks just aren't in the kernel. And that's the point: the kernel is not designed as a set of software components that people can assemble into a system, it's a monolithic piece of software that often needs to be patched in order to support some new piece of hardware or functionality.

      That seems like a terrible idea. As a Linux user, I wouldn't want to wait for a new release of the kernel just to use a certain piece of hardware. And I think just about any computer scientist would say that hardware abstraction and highly modular interfaces are good things. (But don't listen to me; I'm a bad computer scientist.) Besides, I don't think what you said is true, anyway. Linux has had a modules sub-system since version 2.0.

    4. Re:Mike's diary entry by Qzukk · · Score: 2, Informative

      Perhaps not completely new *classes* of drivers, but there are a dozen or so closed source kernel modules out there for various bits of hardware, for instance nvidia's graphics card driver.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    5. Re:Mike's diary entry by zimbu · · Score: 2, Informative

      If your going to quote a paragraph at least read the paragraph before it!

      XFree86 does NOT have a bugzilla or similar bug tracking database. Instead, bug reports are sent to an email address (xfree86@xfree86.org) which someone might or might not ever actually read. Many people think of this bug report address as a blackhole, or a /dev/null alias. In many cases, I believe they are right.

      He's obviously heard of Bugzilla he's just saying that the XFree86 team wasn't using it or anything comparable.

    6. Re:Mike's diary entry by zojas · · Score: 2, Informative
      Sure there is: the hooks just aren't in the kernel. And that's the point: the kernel is not designed as a set of software components that people can assemble into a system, it's a monolithic piece of software that often needs to be patched in order to support some new piece of hardware or functionality.
      you don't have to patch the kernel to add a device, you can link in a device driver as a kernel module at runtime. there is a well defined interface for creating a module, and there are interfaces to talk to the kernel subsytems you need to communicate with your device (for example, the pci bus). there's even a nice book (by rubini i think) about how to create a device driver, either as a module or statically linked at kernel compile time.

      the only time you have to patch the kernel is to change a subsystem, like the scheduler or memory manager, or if you want to CHANGE a driver that's already shipped with the kernel

  2. Re:Already begun by Jungle+guy · · Score: 2, Informative

    It can be seen here - http://keithp.com.

  3. Re:Already begun by urmensch · · Score: 2, Informative

    how about www.keithp.com

  4. Re:A fork would be *bad* by Alan+Cox · · Score: 5, Informative

    Thats crap to put it midly. You write an X application right and it works everywhere. Please already run a huge range of X servers, including WeirdX, MetroX, Accelerated X, eXceed and the like all of which are different codebases, and WeirdX is even in a different language.

    Its like arguing that you can't write a tcp/ip application if NetBSD and OpenBSD forked. The truth is that since both speak the same protocol it doesn't matter at all.

  5. GPLed X by Anonymous Coward · · Score: 1, Informative

    It's time to move to GNU GPL licensed X server WeirdX.

  6. Maybe they should try a style more like FreeBSD by Ded+Bob · · Score: 2, Informative

    They already have the idea of a core. All they need now is to create a level of developers with commit permission to take the load off the hands of a few committers.

    There are established rules to how to be a committer.

    Most important are the perks! :)

  7. Re:X *does* need a change by kigrwik · · Score: 2, Informative

    Just an idea, but if you're using the latest 1.0.4xxx drivers from nvidia, they have a new (read "broken") 2D acceleration driver. Check out the forums at nvidia.com.

    If you need decent 2D response, and you can spare the slight increase in 3D performance, just use the 1.0.3xxx series.

    Hope this helps.

    --
    -- don't discount flying pigs until you have good air defense
  8. Re:How immature of Mr. Packard... by JimDabell · · Score: 2, Informative

    Some people here seem to think that forking is unconditionally a good thing about open source development, but if everyone started forking the kernel, glibc, gcc, and XFree among other core packages, where would that leave us?

    Remember that multiple forks of the linux kernel already exist (e.g. the -ac tree) that are fairly important, and that the gcc 2.9x/3.x series is based on the old egcs fork.

    I'm not saying that forking is always good, but forks in major packages do happen, it's not the end of the world, and a lot of good things can come from it. As major packages, the improvements made possible by a fork can have much more effect than forks of small, insignificant packages.

  9. Keithp locked out... by po8 · · Score: 4, Informative

    Keith Packard has been denied commit access to the XFree86 CVS for several months now. (BTW, he was responsible for making the repository publically accessible---he had a long struggle with certain XFree86 Core Team members to let him do it.) This is obviously an insane situation: he has been the principal developer (outside of 3D and drivers, although he's worked on the latter a bit) for some time now. IMHO the situation is somewhat like locking Linus out of Bitkeeper: of course he would make alternate arrangements!

    In short, this is a fork in name only: the major players in the distro business have committed to work with Keith, and this is the clear successor for realistic X development. Note that this is the third such event in the history of X: the X Consortium was eventually largely dismantled and replaced by x.org, which in turn was essentially superseded by the XFree86 project. A big hope is that a charter and organization can be set up so that the governance of the new organization is democratic (ala Apache Foundation, Gnome Foundation, etc), allowing changes in governance without the need to create a new organization.

    As an X developer and heavy user, I personally am looking forward to having an X repository with current bits and sensible organization.

  10. Xfree86 is the fork, by stonewolf · · Score: 4, Informative

    I haven't talked to Keith for more than 10 years and I haven't been involved with X development for at least that long. But, I remember him from when he worked for the X consortium in the '80s and I represented a member of the consortium.

    Keith has been actively working on X for longer than many X users have been alive. He knows more about the original design decisions, the history and politics, and the problems with X than just about anyone currently living. I would trust his opinion over any other member of the XFree86 "team". And, let's get the facts straight on the idea of forking the XFree86 code base. XFree86 is a fork of the original X code base. X was designed to be forked by each group that used it. That is why it is under the X license.

    If Keith has concerns they are valid concerns.

    Personally I think a lot of what has been going on in XFree86 is misguided. Especially the way 3D has been implemented. Not to mention that the lack of a high performance local binding for X is criminal considering that several ways to implement it have been known for at least 10 years. It was IN commercial implementations of X 10 years ago.

    Stonewolf

  11. Re:You have the right idea by t_hunger · · Score: 4, Informative

    The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed.[...]

    I fully agree that Xlib compatibility is very important, but that can't be the driving factor in a project that wants to replace X. Such an evolutionary approach is far better handled by extending X than by writting an replacement IMHO.

    Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected.


    What makes you say it is a bad idea? We are not fixing the look nor feel of any object created, we just define a set of very generic interfaces to request certain kinds of objects (Buttons, lines, text, ...). Developers can choose the level of abstraction that matches their need. Why should they care wether the Kit is loaded into the server or linked to the client?

    First of all it makes it absolutely impossible to write such an emulation layer.

    That's wrong.

    Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED.

    I absolutly fail to see your point.

    You create a tree of graphic-objects that describe the look and feel of your application once. Afterwards there is NO communication between client and server anymore till the applciation updates its look or the user causes a change in the client's state. Usually not even events leave the server!

    We tried remote-displaying our demo. Via Fresco the communication needed 1.9kBit/s (alive pings) after an initial burst to create all the necessary graphics, even while moving/resizing/scaling/... the windows. Doing the same using VNC to export the same demo at the same color depth and using the same screen-size up to 800kBit/s were used when doing those operations. We allow that factor of ~400 for unforseen complications;-)

    You should further notice that individual graphics do not get complicated. Complex things are build up out of a couple of simpler graphics. This is *very* different from how both GTK and QT work and way more easy once you get used to thinking in terms of small building blocks.

    Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.

    Yes, we are incompatible for now. Nobody is working on an Xlib emulation layer. It can be added and it will be added once Fresco becomes stable enough to hold its own. Nobody can use Fresco for serious work yet, so nobody will miss X compatibility. We'd still have to keep updating the code to keep in sync with the rest of Fresco, thus draining resources that can be put to far better use elsewhere, Doing such an emulation layer now would do more harm than good.

    --
    Regards, Tobias
  12. Keith's POV by jbolden · · Score: 3, Informative

    Finally KeithP put out his response .