Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
X GUI

XFree86 Politics 452

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?"
This discussion has been archived. No new comments can be posted.

XFree86 Politics

Comments Filter:
  • Mike's diary entry (Score:5, Informative)

    by dd ( 15470 ) on Thursday March 20, 2003 @08:47AM (#5554281) Homepage
    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.
    • by Anonymous Coward on Thursday March 20, 2003 @08:58AM (#5554350)
      Keith Packard is also more than aware of similiar problems. You don't start talking about a fork unless you have serious reasons to think that your fork would be better. Just forking for the sake of it just splits the developer base, and the new fork usually gets bad press and poor support. I don't think Keith Packard is stupid, and Mike Harris would seem to give some very good reasons why a fork might be required.

      I'd rather not see a fork of XFree86, but if they can't solve their problems quickly then they may find their hand forced by a fork. That won't be pretty.
      • God *DAMN* it (Score:5, Insightful)

        by 0x0d0a ( 568518 ) on Thursday March 20, 2003 @01:38PM (#5556767) Journal
        just forking for the sake of it just splits the developer base, and the new fork usually gets bad press and poor support.

        I think I'm going to cry. Keith has done the most amazing stuff -- Xft, the modern font architecture -- all the really good features that I've played with recently. If he splits off, XFree86 is going to take a very serious hit.

        Please, please, *PLEASE* try to work this out with Keith, XFree core. If you need to maintain more stability, think about a more unstable devel versions, or even a second "really unstable" devel tree that patches can at least enter the tree. Anything, just don't end up hating each other and refusing to share your code with each other.

        Either side of such a fork would have a much weaker team. We need XFree86 so much right now, with 3d becoming important to mainstream Linux users. I appreciate all that the XFree folks have done, and asking for more seems ungrateful -- but please try to work it out without ultimatums. *Please*. The mplayer folks hang together, even though A'rpi's abrasive, because he's a really great coder, and everyone would be worse off if he wasn't involved.

        Man. I feel almost as bad as when Bungie was purchased by Microsoft. The world *needs* Keith and XFree core being friends, not adversaries.

        This and a war in Iraq, and it isn't even 1:00 yet. What a awful day. :-(
    • Since there is no way to "track" a bug through various stages, through resolution, many bugs, and likely many fixes also just fall through the cracks. Since XFree86.org doesn't really have any way for various distributions to share patches efficiently, or to keep track of the status of an issue, or to even find out if a bug has been fixed or not, and if so, if it is in CVS or not, distribution development tends to needlessly end up with each vendor/distro doing a lot of duplication.

      Ummm, have these guys n
    • by n1ywb ( 555767 ) on Thursday March 20, 2003 @09:09AM (#5554425) Homepage Journal
      I'll admit, Mike Harris' comments are slightly disturbing. But perhaps the real solution isn't to fork XFree86. Why do XFree drivers have to be released by XFree with the core release? Can't they be developed and released indipendantly? Can't ATI just release their drivers themselves? If XFree is slow on the uptake then let the distributions package them. It's not like everybody forgoes the latest Windows video drivers until they're included with a major release of Windows, christ you'd never get them then. It sounds like XFree needs to modularize their development efforts. And if XFree isn't willing to do so then there is nothing stopping anybody from standing up and releaseing their own XFree drivers pack.

      Oh and BTW from http://www.xfree86.org/developer.html
      How to Become an XFree86 Developer

      Get and build the latest XFree86 code from the CVS repository, and subscribe to the XFree86 developer list (see above).

      I don't know if Mike's quote from that page is old or just innaccurate.

      It sounds like XFree could use some new blood. It's too bad there aren't just more active developers as it would help to steer it in the right direction. The Linux kernel is a good example of a piece of software which is ultimately controlled by Linus' inner circle, but which is really driven by the hundreds (thousands?) of other people who hack on it and release their own trees, etc. Maybe writing GUI code is boring by comparison, or something.
      • by dd ( 15470 )
        The diary entry is Jan 9th, so presumably xfree86 opened up the developer link since then. One wonders of they opened it in response to undercurrents or complaints in the ranks?
      • by g4dget ( 579145 ) on Thursday March 20, 2003 @09:38AM (#5554651)
        The Linux kernel is a good example of a piece of software which is ultimately controlled by Linus' inner circle, but which is really driven by the hundreds (thousands?) of other people who hack on it and release their own trees, etc.

        But from the user's point of view, the problems are quite similar. For example, you still can't get a 2.4 Linux kernel with decent ACPI support, reasonably complete FireWire support, or lots of other features that have been out individually for months or years. And the 2.5 kernels do not even come close to compiling cleanly in most configurations (at least the half dozen I have tried).

        Both the Linux kernel and XFree86 suffer from similar problems: they are very well-written and well-tuned C programs, but there is only so much magic even the best C wizard using the best tools can work on huge C source trees.

        • by n1ywb ( 555767 )

          But from the user's point of view, the problems are quite similar. For example, you still can't get a 2.4 Linux kernel with decent ACPI support, reasonably complete FireWire support, or lots of other features that have been out individually for months or years.

          I'm honestly not up to speed on the kernel support for ACPI or FireWire. But lets face it, there are what now, a billion computers out there? And how many of them have ACPI or FireWire? Not the majority, thats for certain.

          And the 2.5 kernels do not

          • I'm honestly not up to speed on the kernel support for ACPI or FireWire. But lets face it, there are what now, a billion computers out there? And how many of them have ACPI or FireWire? Not the majority, thats for certain.

            The majority also lack SCSI, video capture, and probably USB, as well. Yet, the 2.4 kernel supports all of these. What was your point again?

          • by g4dget ( 579145 ) on Thursday March 20, 2003 @10:25AM (#5555027)
            Again, there's nothing stopping anybody from releasing these drivers indipendantly of Linus' releases.

            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.

            And how many of them have ACPI or FireWire?

            Most of the new ones have ACPI. In fact, my two year old desktop has ACPI. I suspect the majority of new laptops being shipped can't be suspended under Linux, even though the code has been donated by Intel a long time ago and works.

            Linux is so much more stable than Windows because Linus is so picky and doesn't just cobble stuff into the kernel before it's ready.

            This isn't about Windows vs. Linux. The Windows kernel seems to suffer from the same problem, although for Windows, they at least have figured out how to make third party drivers work a bit better. But just because everybody suffers doesn't mean that there isn't a problem.

            Linus is doing a great job at what he is doing. But there is only so much any group of developers can do with a software system that is millions of lines of code and for which new components are often distributed as patches. We will have to move to a different architecture at some point; the only question is when and how.

            • by turgid ( 580780 )
              Linus is doing a great job at what he is doing. But there is only so much any group of developers can do with a software system that is millions of lines of code and for which new components are often distributed as patches. We will have to move to a different architecture at some point; the only question is when and how.

              *sigh*

              A documented and stable binary interface for drivers in the Linux kernel would be good for many reasons. The standard "reason" given by the kernel developers why there isn't one a

            • by t0ny ( 590331 ) on Thursday March 20, 2003 @11:55AM (#5555879)
              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.

              g4dget is correct. That is also the reason why Linux is faster than Windows- you are running one program rather than several that hook into each other. But what Windows loses in speed it makes up for in flexibility. Its a trade off, and each made their decision. Since Unix (and hence Linux) is essentially a server OS, graphics display are not its core concern- networking performance is.

              The Windows kernel seems to suffer from the same problem, although for Windows, they at least have figured out how to make third party drivers work a bit better.

              Well, for the most part. You still get flaky implimentation. For example, until its influx of 3dfx people, ATI really sucked ass with both hardware and software (and drivers). Now they unified their drivers like nVidia, and are getting some pretty stable performance: they still arent near stability of nVidia tho- nVidia cards are like a tank.

              But aside from all that stuff, there are some good some bad with other graphics drivers, especially the farther down the food chain you go. But thats the whole thing- it IS possible to make rock solid third party drivers for Windows, its just some companies generally dont have people skilled enough to do so, or else the product itself is unstable.

        • by Alan Cox ( 27532 ) on Thursday March 20, 2003 @10:54AM (#5555253) Homepage
          Firewire is ok - the ACPI one is a good point, and its one reason I want to get the newer ACPI and the patches to handle buggy but not detected by MS ACPI into the -ac tree.

      • "Can't ATI just release their drivers themselves?"

        I was wondering the same thing. Are XFree86 drivers modular? If not, why not? And if not, then XFree86 is severely broken and badly needs to be redesigned to be modular.

        If so, why does ATI wait for the core XFree86 team to (months and months later) even look at the possibility of including its drivers?

        I'm not familiar with XFree86's internals, but my guess is the former (XFree's internal architecturer is broken). If it were the latter, then this wh
        • The degree of modularity that would allow vendors to plug in binary drivers would lead to vendors no longer cooperating at all in providing open source drivers.

          Some would say that this goes against the spirit that XFree86 is being developed under, and would lead to the project eventually falling into becoming fairly proprietary.

          I am not saying this is good or bad, but there's a political agenda behind the licensing tactic of many Open Source projects. That's how it works.

  • So what? (Score:5, Insightful)

    by thanuk ( 620203 ) on Thursday March 20, 2003 @08:47AM (#5554282)
    Someone wants to make their own fork of an open source package. I thought that was the whole point of open source.
    • Re:So what? (Score:3, Insightful)

      The virtue of open source is that you can fork, if necessary. But it's still a bad idea, most of the time, since it reduces the effort that can be applied to each branch.

      In this case, we'll only know if it's a good thing if we read the facts, and think it through. So that's not about to happen :)

      • Re:So what? (Score:3, Insightful)

        by pldms ( 136522 )
        The virtue of open source is that you can fork, if necessary. But it's still a bad idea, most of the time, since it reduces the effort that can be applied to each branch.

        Agreed. (That sounded a bit 'me too'. Eek). However this sounds a little like the FSF Emacs/Lucid Emacs fork [xemacs.org].

        In that case, and this (Mike Harris sounds like a reasonable guy so I'll take his word on this) the reasons for the split were issues with how the project was managed - it wasn't a petty 'you won't accept my ideas so I'm off', t

    • Re:So what? (Score:4, Insightful)

      by peerogue ( 623472 ) on Thursday March 20, 2003 @08:58AM (#5554348)
      You are highly mistaken. The point of being open source has never been to make code fork possible.

      My experience with code forks is that it is often a failure on the forked part. Rarely, the forked project may become more successful than the original project. Most probably, this will increase the work on both projects if they want to be kept in sync.

      Before rejoicing about the fork, think of it that way: assume the fork proceeds, and we have a new Xfree86-bis project. As an end-user, which one will you want to run? Do you think forking the project will bring you more freedom of choice, more quality, more robustness, more timely updates?

      Just because you CAN fork an open source project does not mean it is a good idea. The fact that it's so easy to proceed with the idea is nothing. The hardest part is managing the "after-fork".
      • Perhaps, but often there is a good reason for a fork. Linux is playing around with several schedulers (or they were 6 months ago), as is freeBSD. Part of the reason is there are different ways to do it, and depending on what your goals are you may want to run different ones. I might pay to fork Linux just so you can choose your scheduler. (Of course if the scheduler is just a drop in replacement you can choose at compile time, but if one schdeuler needs other code changes to really work good then compi

      • Re:So what? (Score:5, Insightful)

        by Surak ( 18578 ) <surak&mailblocks,com> on Thursday March 20, 2003 @09:15AM (#5554471) Homepage Journal
        My experience with code forks is that it is often a failure on the forked part. Rarely, the forked project may become more successful than the original project. Most probably, this will increase the work on both projects if they want to be kept in sync.

        I disagree. Forks are useful and often necessary. Phoenix and whatever-they're-calling Chimera this week are necessary Mozilla forks. Mozilla is more or less intended to be a test platform, while Netscape, Phoenix and Chimera are designed to be useable applications. Each of these forks are intended to serve a different purpose. Forking the refinement of the UI into different projects allows the main Mozilla trunk to focus on Gecko and other underlying functionality while not neglecting the need entirely for a refined UI.

        Another case of different audiences: GNU Emacs vs. XEmacs. XEmacs is designed to be a polished version of Emacs that works well for people who want a nice professional development environment on *nix, while GNU Emacs is geared at being the consumate hacker's editor.

        Or the embedded Linux forks. Actually, there are about a bazillion different Linux kernel forks. Everyone has their own kernel...eventually they re-sync with Linus' kernel, but each of these separate kernels are, again, geared at different audiences.

        • Re:So what? (Score:4, Insightful)

          by Abcd1234 ( 188840 ) on Thursday March 20, 2003 @01:52PM (#5556882) Homepage
          Actually, a far, far better example of the benefits of a fork is the fork of GCC a while back. This fork led to the EGCS project, and EGCS was then adopted as the official GCC 3.0. In this case, the fork was highly beneficial, and is the reason, IMHO, that was see GCC progressing the way it is today (prior to the fork, GCC really seemed to be stagnating).
      • Re:So what? (Score:5, Insightful)

        by n1ywb ( 555767 ) on Thursday March 20, 2003 @09:16AM (#5554475) Homepage Journal
        My experience with code forks is that it is often a failure on the forked part.

        There are many, many forks of the Linux kernel. No, none of them are as popular as Linus' kernel, however it is in these other trees that most of the development of the kernel takes place, and the good changes get accepted back into Linus' tree. The history of the Linux kernel is a twisted map of intertwining forks. The fact that none of the forks has been more successful than Linus' is completely irrelevant. Without all those other forks the kernel wouldn't be where it is today.

        Perhaps we have different ideas about what exactly qualifies a "fork".
    • Re:So what? (Score:2, Informative)

      by questamor ( 653018 )
      It's about the biggest fork possible, besides someone forking the linux kernel itself.

      In the sense of being Just Another Fork it's not all that interesting, but it happens to be one that's relevant to just about anyone who runs an app that's dependent on a X Window system of some kind.

      Just about every graphical app on an *ix system depends on that. OSX's Quartz is a notable exception.
    • I don't think anyone is saying you're not allowed to fork; the problem is (Disclaimer: I haven't read the article, I'm going from the story blurb) that a core member of the XFree86 was being evasive about what he was planning to do about a fork. The goals of the core team are to maintain the best set of code possible; a code fork goes against some of those goals.
      • Re:So what? (Score:3, Insightful)

        by 4of12 ( 97621 )

        You're right that being evasive about the reasons you want to fork is not healthy.

        However, that does not diminish that forks are sometimes a good idea.

        It gets back to your comment

        goals of the core team are to maintain the best set of code possible

        because best becomes highly subjective for future features that have not been implemented.

        One developer might complain that code cleanliness will suffer; another might sacrifice complexity for low memory footprint or performance under conditions that may or

  • Damn! (Score:3, Insightful)

    by Anonymous Coward on Thursday March 20, 2003 @08:49AM (#5554299)
    This is bad! Keith was one of the few developers who really was adding value to XFree86, with fontconfig and xft. Without those, fonts on *nix would still be an utter mess...
    • Re:Damn! (Score:5, Insightful)

      by Alan Cox ( 27532 ) on Thursday March 20, 2003 @08:55AM (#5554331) Homepage
      I think an XFree86 fork will be good, for both sides. XFree86 has become stuck in a rut or two. It needs people to go out and do crazy stuff, to make things happen. If that works then like egcs becoming gcc3, the new X will become the base X, if not well the good bits will drift back into XFree.

      XFree86 is an old project, based on even old roots so its not suprising its a bit of a dinosaur at times - its taken a very long time to get bugzilla.

      The response to Keith is horribly netbsd'ish though, this "you are with us or against us" thing (Actually its terribly George Bush right now). I suspect in the same situation Linus would merely wish the person "good luck" 8)

      Alan
      • Re:Damn! (Score:4, Interesting)

        by Rich ( 9681 ) on Thursday March 20, 2003 @09:39AM (#5554653) Homepage
        I agree. It is strange that even people with a long history of Open Source development seem to be unable to get access to the XFree86 cvs. A case in point is the missing support for the signal level in the Xv extension which means that it cannot be used to scan for TV channels. George Staikos was willing to take a look at it (so we could make things work nicely in the KWinTV rewrite) but of course getting the patches accepted is a problem.

        The fact that AFAICS *all* the new facilities in recent XFree86 versions have come from Keith would suggest that the problem lies with the way the project works rather than with Keith.

        Rich.
  • Positive Side? (Score:5, Insightful)

    by saynte ( 659908 ) on Thursday March 20, 2003 @08:58AM (#5554349)
    Is it possible that this fork could be a good thing? I don't see why somebody concurrently working on the project could be a bad thing. (Since he's off the official team anyway, they won't otherwise be losing his contribution ;)). Maybe the current group has gotten a little stagnant a little change of direction is needed? I'm not saying the current effort is *bad*, just that there are possible good sides to a fork. The fact that the dev team would be a small private group, doesn't really seem to be that bad. After all, there are many private groups of developers that make fine fine products. Although this hasn't been worded very well on my part, I'm really just trying to say this: why stop someone from *trying* to make it better? Why is a private group a *bad* thing? (ie - just because they're private, doesn't mean that they won't listen to the concerns of the public) Do you people think they might not make the work they do accomplish public? (I'm not sure, but it seems there is no obligation to release source for changes made?)
    • Re:Positive Side? (Score:3, Interesting)

      by Panaflex ( 13191 )
      Let me just say that many of the innovations in XFree86 (minus DRI, XAA, XVideo, and a few others) has been pushed and developed by Kieth.

      Keith is well placed for a fork... Examples:
      1. Developed numerous core extensions (XRender, XCursor, many many others)
      2. He's developed on X for at least 15 years??, and is one of the few people to understand a good part of it.
      3. He works with Jim Gettys (Designer of X) at HP.
      4. XWindows needs to go towards a real rendering model server wide. People are willing and rea
  • by Anonymous Coward on Thursday March 20, 2003 @09:01AM (#5554370)
    Maybe he is holding it back. I say fork!

    Actually to be honest, I would like the transparency server but more importantly things like the Mach64 driver need to be integrated so I can get XVideo and DRI w/o having to download binaries. The stuff in question has not been updated in ages and I am concerned that the 4.3 release will go unnoticed and I'll be stuck w/o dri.
  • XFree86 (Score:5, Insightful)

    by pajor ( 310214 ) on Thursday March 20, 2003 @09:01AM (#5554373) Homepage
    I think XFree86 needs a good fork. It seems to suffer from a sort of PHP-Nuke meglomania. Vendor support is massively important; if ATI is nice enough to supply patches to add support for their latest cards and latest features, it would help linux and unix in general to be nice enough to check in the patches ASAP. If vendors look upon Xfree86 as worthless to support drivers for because of inability to delegate responsibility, then X and linux in general will never reach the usability levels that we strive for.

    That being said, forks are dangerous and should only be done by talented contributing people with people skills. Keith Packard is a good coder, I hope he's as good with politics.
  • Already begun (Score:5, Interesting)

    by grub ( 11606 ) <slashdot@grub.net> on Thursday March 20, 2003 @09:05AM (#5554390) Homepage Journal

    Not Found
    The requested URL /~keithp/talks was not found on this server.

    Apache/1.3.26 Server at www.xfree86.org Port 80


    He better find a new home for his homepage methinks!
  • More open? (Score:5, Insightful)

    by moriya ( 195881 ) on Thursday March 20, 2003 @09:06AM (#5554407) Homepage
    I've read Mike Harris' log entry and I agree with many of the points he brought up.

    But the thing is ... if XFree86 wants to be more open, why did they remove Keith Packard from the core team in the first place? I know he has contributed in XFree86 that is beneficial but still, despite that he wants to fork off his own XFree86 tree, does the people at XFree86 require to know what he (Keith) intends to do with it?
  • by standards ( 461431 ) on Thursday March 20, 2003 @09:07AM (#5554409)
    When you signed up to work for our organization, we made a contract. That contract states that you are not allowed to work on any other external project without our permission.

    Not only have you decided to form a competetive product, but you're also trying to steal our people away. We can't have this nonsense at our company.

    This organization has to protect it's financial interests. We can't have competition from within. We don't want you to take anything away from our premere product.

    You're fired. You'll hear from our lawyers in regards to the anti-compete clause that you agreed to.
  • by Erwos ( 553607 )
    But Keith better be damned sure _why_ he's forking, because the last thing the Linux community needs at this point is for the windowing standards to fall apart.

    If this was a "to-be-merged fork" like the sort you always see at the DRI project, I'd be much more sanguine about this. The article makes it sound like it's a full-blown "screw you" fork.

    -Erwos
    • Re:OK (Score:3, Insightful)

      by Anonymous Coward
      Keith better be damned sure _why_ he's forking

      That is almost certainly why he has been "privatly" talking to people about a possible fork. He isn't stupid, and there is no way you could fork a project like XFree86 without both internal and public backing of some sort.

      Now that XFree86 Core has got its panties in a bunch and thrown Keith out, it has probably made the posibility of a fork even more likely. After all, Keithe has been one of the main drivers behing recent XFree86 development, he is passio
    • XFree86 is not the windowing standard for Linux and never has been; XFree86 is just one of many server implementations of the X11 protocol. People run Linux desktop software on non-XFree86 implementations all the time.

      Presumably, after a fork, both XFree86 and Keith's X11 implementation will continue speaking the X11 protocol, and both will support common extensions. Keith may add more experimental extensions, but that shouldn't be a problem for anyone.

  • KGI FreeBSD project [freebsd.org]

    Just so you know KGI is the Kernel Graphics Interface project that was to be the underlying layer of GGI in Linux.

    I used to mess around with this back when Linus was saying how much it was a bad idea. The neat thing about ggi applications is if you compile them once they will run within X as well as at the console without a recompile. At least that used to be a goal... Admittedly I stopped following this project a long time ago but I am glad that it appears to be moving forward else
  • by Yag ( 537766 ) on Thursday March 20, 2003 @09:19AM (#5554496)
    XFree is old, should be rewrited from scratch, but the problem is the time. XFree works in a lot of architectures, and a lot of different hardware. Out there there are good alternatives (from a "design" point of view) like DirectFB but they run just on few hardware, and, usually, only 1 architecture. So, the problem is, XFree is too big to make forking a good idea, i think people should just make current X better without any fork. We need some standard for direct hardware access (like DRI) and concentrate work on them. Just an opinion...
    • Where do people get the idea that DirectFB is an alternative to X? It is a fast and good graphics library, just like SDL or GGI or some others! Just that you can run GDK on a graphics library does not make it a replacement for X.

      I do think we need something to replace X, but that shouldn't be some more or less randomly picked graphics library. That's a step backward: You loose network transparency, which is a really cool feature and will become even cooler with the rise of mobile devices. You don't loose m
  • by Jay Maynard ( 54798 ) on Thursday March 20, 2003 @09:28AM (#5554565) Homepage
    ...is one that constantly seeks out new talent and includes their efforts in the project. One thing I've learned about managing (FSVO) an open source project is that the worst thing you can do is to ignore people's contributions. Heck, if Mike's diary entry is still the state of affairs, there are more people with commit access to the Hercules CVS repository than there are XFree86, a project that's probably two orders of magnitude bigger!

    No wonder people are getting frustrated. Perhaps a fork is in the best interests of the XFree86 project.

    I'd be interested to hear Keith's side of the story, especially his concerns. If they're correct, though, and he's only willing to discuss them with a handpicked developer community, I doubt we'll hear anything useful.
  • XFree86 seems very poorly managed, especially compaired to somthing like KDE.
    The whole project seems to take a black box approach, or at least that's my view from XFree86.org

    If I take a look at what's in the next release I get Release Plans [xfree86.org]
    "XFree86 4.x
    Our current release is the 4.3.0 release, which was released on 27 February 2003.

    A current snapshot of the 4.x code can be checked out of our public CVS repository."

    And what's in 4.x? looks like nobody knows.
  • Why not? (Score:5, Interesting)

    by g4dget ( 579145 ) on Thursday March 20, 2003 @09:30AM (#5554585)
    Sounds good to me. Either the two will co-exist, or the better project will win.

    The message posted by "Moulinneuf" actually suggests to me that Keith probably is well-justified in doing this. It makes sense to kick people off an open source project if they don't contribute or do technically the wrong thing, but that's clearly not the case with Keith. OTOH, if a project member wants to test the waters for a fork privately, so what? Moulinneuf's message sounds like Keith was part of the secret service and spying for the enemy. Sounds like wounded pride and politics to me.

    Another question one might want to ask, though, is whether it isn't worth starting an X11 server from scratch. X11 isn't as complicated as the XFree86 server makes it appear to be. And the priorities have shifted, too: stuff that used to be really important in X11 could perhaps now be shifted to simple generic implementations.

  • I know that the most important feature of X I rely on is the client/server setup. I enjoy the fact that I can have tens of NCD terminals per low end P3-1Ghz machine.(20 per terminal server in fact.) and it brings maintaince of each office from a whole day job to 20 minutes via SSH and tight-VNC.

    What changes are in store? The links to his "talks" are dead.
  • I would like to quote Dennis Leary in regards to this:

    "Whiny fuckin' maggots"

    One only has to examine the Linux distro home page to see over *70* forks of the original Linux idea.

    Fork it, fine, but quit being a bitchy "snadbox is mine" baby, this goes for both the team AND the forker.

    Moderate this not as a troll, but as flamebait. I'm tired of reading articles like this where one guy with a big ego is torqued off at the rest of the big ego teams and things like this happen.

    It's a cult of personality and
  • Transparency Server (Score:2, Interesting)

    by barspin ( 585641 )
    Now it's understandable why Keith Packard hasn't released any code related to his long-awaited transparency server - he's using it as leverage for a fork that would be led by himself.


    Such is the way of open source. Fork, I say! I only hope that Keith's concerns are truly pragmatic and related to the software, rather than ego.

  • by Stiletto ( 12066 )

    A forked tree would basically kill X as a _standard_ platform. If I write an X app, do I write it for XFree86 or XFree-KiethP? If I'm putting a distribution together, do I package XFree86 or XFree-KiethP? I'm ATI and I want to contribute to driver development. Do I support XFree96 or XFree-KiethP. I'm trying to port an app written for XFree-KiethP to Solaris. What now??

    X has survived for this long because it is a _standard_ platform. You can write an X application anywhere and reasonably expect it t
    • by Alan Cox ( 27532 ) on Thursday March 20, 2003 @10:10AM (#5554894) Homepage
      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.
    • People said the same thing about forking the Linux kernel. Look how its doing.

      Further to that, XFree86 is NOT X. X is a standard. As long as any forks adhere to the X standards, and implement the same extensions XFree86 does, there should be no problems whatsoever.

      As far as writing separate patches for separate package versions is concerned, I don't think this'll be a problem. X seems sufficiently modular that a few driver changes here and there shouldn't have any effect on interoperability.

      With any
    • A forked tree would basically kill X as a _standard_ platform. If I write an X app, do I write it for XFree86 or XFree-KiethP?

      Considering that I can run every Linux app imaginable using a completely non-XFree86 X11 server on Windows (XWin-Pro, Xceed), I'd have to disagree with you there. I'm sure the KDE team didn't "write KDE for" XWin-Pro, but it works fine. Also, there are non-XFree86 X servers for Linux that work great, one of which I can't remember the name (it's a commercial server).

      X11 is the
    • I don't know a single app that targets XFree directly. They all target X11. The apps may take advantage of XFree86 features, but run on any other X11 server. The same will be the case if they fork.
      But as the development in XFree is rather slow, and at least my impression is that all feature-improvements in the last 2 years have been partially or completely done by KeithP, I doubt that anyone would still bother to use XFree in another 2 years...
  • by BlackHawk-666 ( 560896 ) on Thursday March 20, 2003 @09:58AM (#5554819)
    The binaries for XFree86 are over 70MB in size, what on earth are they putting in there? Maybe it is time to fork this project or start again from scratch and apply modern design techniques. How about modularising the engine? Why do you have to download every driver for every stinking card out there when you only have 1 video card in your machine? This thing's bigger than early versions of Windows, and it's only a display driver. With a modular design the individual companies could produce their own driver which could simply drop into the main X engine. That would free up the developers from worrying about approving all the patches from each of the major vendors, and they could concentrate on writing some useful core software.
    • by Alan Cox ( 27532 ) on Thursday March 20, 2003 @10:12AM (#5554912) Homepage
      Actually Keith has been working on this for some time. Take a look at the hw/kdrive tree in XFree86, that produces very small Xservers and supports a few chips so far (notably things like the iPaq use it).

      Also a lot of the rest of the XFree binary package set is fonts, weird prehistoric applications (wtf uses xsetpointer, xkbbell,
      xstdcmap...) and ancient unused (but important for back compatibility libraries) like Xaw.

  • Good fork (Score:3, Insightful)

    by Daniel Phillips ( 238627 ) on Thursday March 20, 2003 @10:18AM (#5554951)
    I'm not deeply clued in to XFree politics, but my off-the-cuff impression is that this would be a good fork. XFree, for all it's great qualities, could definitely be more forward-looking, especially in the rendering area (i.e., aa, subpixel, alpha etc) Keith's speciality. I don't know how it might work out, but it would be nice to see more competition/openness on the display driver front as well, especially 3D, and especially, 3D used for 2D rendering, which I'm sure Keith has some ideas about.
  • by akc ( 207721 ) on Thursday March 20, 2003 @10:19AM (#5554967) Homepage

    The whole strength of the open source concept is that the many hands in a community can make complex problems shallow. If forks can't happen, then a monopoly on the supply of software develops. However, within there already seems a situation in which the threat of a fork is forcing a previously partially closed community to consider how to open up more.

    Don't forget that forks are considered by Linus to be essential elements of a successful project. They allow the opportunity for alternative approaches to be tried, and if successful to be adopted. The trick in the kernel is that Linus recognises this and is prepared to merge again when a fork shows its worth

    This hasn't worked through yet - it may well be that the threat that it might happen allows the situation to improve such that the natural progression is to bring the two sides together again. This is an opportunity not a threat and we should encourage it

  • by Ded Bob ( 67043 ) on Thursday March 20, 2003 @10:35AM (#5555110) Homepage
    They already have the idea of a core [freebsd.org]. All they need now is to create a level of developers [freebsd.org] with commit permission to take the load off the hands of a few committers.

    There are established rules [freebsd.org] to how to be a committer.

    Most important are the perks [freebsd.org]! :)
  • by Hard_Code ( 49548 ) on Thursday March 20, 2003 @11:11AM (#5555407)
    Ok, I've participated in many X "discussions" and the one feature of X that is always trumpeted is the out of the box network transparency.

    As the Windows and Mac OS GUIs increase in sophistication, we have seen that they have been able to add in "network transparency" to an extent (ok more like "remote viewing") with things like VNC, and other implementations, that exist entirely seperate from the GUI proper - they basically implement a very very basic bitmap-copying protocol.

    Is there a case where THIS IS NOT SUFFICIENT? Is it really that much of a win to burden the entire architecture with a feature that in its common use can be implemented completely seperately and still solve 90% of the problem?

    I'm serious here, can some a heavy/long-time user of X illustrate cases where they NEED network transparency built in (besides that it is "elegant" technically)? The only thing I can think of is having remote windows "integrate" with your local X server - but is this a COMMON CASE at all? I would imagine the common case to be temporarily using remote apps (potentially on an entirely seperate desktop instance) in which case it doesn't matter (or is in fact beneficial) that they are visually distinct, OR using an ENTIRE remote desktop (KDE, Gnome, etc.) in which case ALL your apps will be "integrated" visually since they will all be running on the remote machine.

    In what circumstances would you WANT disparate remote applications, from potentially multiple remote machines, integrating invisibly in your current desktop ?(I for one would think this would be hell of a confusing! "Shit did I just 'rm' that file on my local machine, or the server!??") What is the benefit here? What is the cost?
    • Let me add a bit more...

      This is not to mention the fact that since nobody can (or will) decide on window managers or toolkits, apps currently look different and are non-integrated ANYWAY, regardless of whether you integrate the network transparency at the X level.

      Also, what does it say that KDE has rebuilt standalone remote-viewing functionality in the face of built-in X network transparency?
      • X network transparency makes the applications network transparent, which is not the same thing as making the desktop network-transparent. KDE has done the latter, and the difference is that it's a coordinated remove-viewability that includes the KDE toolbar, applets, desktop-statefulness, and so forth. I don't believe it's true, as you have implied, that KDE found X's network transparency to be flawed in some way and so had to work around it. KDE simply solved a different problem.

        I personally am a regul
      • by Stinking Pig ( 45860 ) on Thursday March 20, 2003 @01:05PM (#5556502) Homepage
        It says that someone realized VNC/rdesktop style screenscraping is easier to implement, and wrote a GUI to control it.

        In other news, it's also easier to write a note with a pencil on a piece of paper than it is to log into a computer, log into a discussion site, and type the note in. There are times when each is the more appropriate choice, depending on the task at hand.

    • by Alioth ( 221270 ) <no@spam> on Thursday March 20, 2003 @11:54AM (#5555861) Journal
      Is there a case where THIS IS NOT SUFFICIENT? Is it really that much of a win to burden the entire architecture with a feature that in its common use can be implemented completely seperately and still solve 90% of the problem?

      Several cases. Personally, I use the network transparency of X daily, to use GUI apps that are being run on more than one computer *without* disturbing the desktop on said computers (and in fact, one of them isn't even running its own X server). I find this feature very useful, and something VNC and its ilk does not replace.

      Also, X over a network is quite a bit faster than VNC.

    • Is there a case where THIS IS NOT SUFFICIENT?

      VNC/RDP both export the whole desktop. Your remote view of the computer is a window containing the entire remote desktop; start bar, explorer, window manager, everything. X11 remotely views a single application. You have a single desktop which integrates applications from multiple sources.

      In what circumstances would you WANT disparate remote applications, from potentially multiple remote machines, integrating invisibly in your current desktop ?

      If yo

    • Network transparency doesn't add a whole lot of overhead. All the major GUIs today (even some of the fastest ones like BeOS's) used a client/server design. With more and more stuff moving towards the graphics card (which all employ a "batch commands and DMA in one go" programming method that is well-suited to client-server systems) the cost approaches zero.
  • by jonadab ( 583620 ) on Thursday March 20, 2003 @11:13AM (#5555438) Homepage Journal
    What we actually need is a replacement for X11, redesigned from the
    ground up, with compatability libs to allow normal, window-bound
    X11 apps to work on it. We'd lose existing "special" apps (window
    managers, screensavers, panels, ...), which is a shame, but it's
    what needs to be done to allow for future improvements.

    Don't get me wrong, I mostly like XFree... but the design is
    (gradually) reaching the end of its useful lifespan. There are a
    number of improvements I'd like to see that are fairly impractical
    for a design based on X11. Resizing windows is nice, but I also
    want to be able to scale them. (This implies that bitmapped fonts
    should die, among other things.) Being able to grab a bitmap of
    the desktop and use it as a window background is one thing, but
    I really want a full alpha channel for every window (controlled
    by the application for each widget in the window, or for each
    pixel in an image canvas widget) plus an overall opacity setting
    (controlled by the user) for the whole window. And so on.
  • This is stupid. (Score:4, Insightful)

    by Anonymous Coward on Thursday March 20, 2003 @12:38PM (#5556264)
    I'm posting this anonymously because, well, I just feel that way. I suppose I don't feel like giving information that could tie my various online personas together.

    Keith has come by PSU (I mean Portland State, not Penn.) several times to lecture in Bart Massey's AI classes. I haven't met him, but I do know some of the people involved in some of this "new X stuff." My girlfriend even had lunch with him once. Several of the people I work with were involved in pre-XFree86 X development and have nothing but good things to say about him.

    My take on this is, Keith has some pretty radical ideas for changing X. At least, radical in the eyes of the XFree86 "core team." I've seen him on the lists defending his opinions, and he does so maturely and patiently, even when people don't agree with him. I think he's just given up trying to convince the XFree86 team, but he doesn't see that as any reason to abandon his development. Why shouldn't he make a fork if that's what he wants? If XFree86 didn't want this, they should have never made the source open.

    For this perceived treachery, the core team whines and boots him out. Pretty stupid considering he was making considerable headway with Xrender, the only major advance in the basic graphical functionality of X in many years (excluding hardware acceleration).

    I'm gonna go out on a limb and say that if Keith is successful in what he's doing, there will be plenty of people running his stuff in the future, and XFree86 might become much less relevant.

  • Happened to me (Score:5, Interesting)

    by ElMiguel ( 117685 ) on Thursday March 20, 2003 @01:47PM (#5556836)

    About three years ago I was a happy user of XFree86 3.3.6; then XFree86 4.0 was released and my Matrox Mystique stopped working. After carefully determining that the cause was almost certainly a bug in the XFree86 4.0 driver, I decided to send a bug report to XFree86. I read all the relevant instructions on the web site, collected the required data, and sent a polite and detailed bug report to the appropriate mailing lists.

    After some weeks I had received no answer. Bad luck, I thought, so I rechecked I had done everything as indicated in the XFree86 site and reposted my bug report. Zero feedback again. I sent about eight bug reports along three months more or less, and got no answer from any XFree86 developer.

    I did get mails from some people with the same problem as me, wanting to know if I had found the solution. I had tried to debug the driver myself, but I don't really had the necessary skills and experience, not to talk about the technical specifications. So there was nothing users who suffered this problem could do; we had to stay with 3.3.6.

    Finally, I got some explanation from the last bug report I sent. It was from another user who was frustrated with the way XFree86 was developed. He explained that the public mailing lists I had sent my bug reports to (as I was supposed to do) were only occasionaly browsed by a couple XFree86 developers. Real communication among developers happened in private, closed mailing lists that only people with CVS access could post to or even read.

    So the problem went unfixed. Some months later I upgraded my computer and forgot about this. Probably, to this day, owners of Matrox Mystiques with a certain chipset can't use XFree86 4.0.x, and I bet the maintainers of the mga driver don't even know. I couldn't tell them.

  • Keithp locked out... (Score:5, Informative)

    by po8 ( 187055 ) on Thursday March 20, 2003 @01:53PM (#5556905)

    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.

  • Xfree86 is the fork, (Score:5, Informative)

    by stonewolf ( 234392 ) on Thursday March 20, 2003 @02:03PM (#5557066) Homepage
    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
  • by jbolden ( 176878 ) on Friday March 21, 2003 @12:16AM (#5562698) Homepage
    I saw this link [xfree86.org] on OSNews and thought it should be reposted here. This is a member of the XFree BOD giving more information on why Keith was expelled and a discussion of how X is governed (i.e. the distinction between BOD and Core). He also argues for LSB taking a much larger role with respect to X (I can't help but think that BSD, Solaris, etc.. would object to that).

    OTOH YMMV as far as this attack since there is no discussion of what specifically are the issues leading to the fork and rather vague comments about "corporate interests".

For God's sake, stop researching for a while and begin to think!

Working...