XFree86 Core Team Disbands
mumumu was among the many to write with this news: "XFree86's release engineer David Dawes has announced that "a majority of the XFree86 core team has voted in favour of my proposal to disband the core team". XFree86's News Headline has a short message about it. Why, all of a sudden?
What is the successor of the XFree86? Xouvert? freedesktop.org?"
Why would a successor for XFree86 be needed? As I understand it, this is only a change in the "political" structure of the project, not its end.
Programming can be fun again. Film at 11.
Sounds more like the "core" team weren't actually doing the development anymore, and that they felt it was unfair to be the "core" team when they weren't doing the work.
Nothing to see here folks, keep moving.
read.
the.
exceedingly.
short.
article.
cyn, free software and *nix operating systems enthusiast.
Face it.
"Core Team" Development models are out-dated and sound more M$'ish than Open Source'ish.
While several projects continue to use the "Core Team" model, like FreeBSD, in my opinion, the politics involved ain't worth it.
For XFree86, it's time for change. Hopefully, in years to come, we will see a more efficient graphics subsystem for Unix (MacOS X may be an example) weather it be by a XFree86, XF86 Fork, or some other system (NOT framebuffer because fb doesn't work well with some hardware)
After comparing the /. headline with the actual content of the email, I wonder what exactly /. *does* check on before they post these...I feel like they're trolling for a bunch of misinformed readers to overreact.
It may be newsworthy, but considering the length of the message, why not just post the original email and be done with it?
I think it's related to the "firing" of Keith Packard from the core group, when he was one of the few people trying to move X11 into the 20th century.
I'm going to forego the opportunity to use my moderator points today on this story because every odd-numbered post in the list is already "Score:5 Insightful". There's just a wealth of wisdom here, and I have precious little to add.
In all fairness to those who questioned the future of X, I was momentarily confused by the announcement, too. It appears this little group of developers has finally just gotten out of the way. I'm hoping there's still a person or two to moderate code additions while the rest of the community keeps up the project.
-j
The abundance of abandond projects on Sourceforge would appear to disagree with you. Open Source projects are usually NOT the domain of hundreds and thousands of globally diverse developers but rather a very small and very active "core" team. Once that core team leaves (and I'm not talking about XFree86 here) then the project usually dies. Why? Because even though the code is in the public domain there is a lack of willingness to get involved or a lack of skill of those who ARE willing or a lack of time for those who are both skillfull AND willing.
Mac OS X and Windows XP working side by side to fight back the night.
Any switch can blow up if a transition isn't well-planned or done with the right expertise. In my experience, major shifts like that require a lot of training of existing staff while bringing in a number of consultants that are fluent in the new tech.
True, choosing a product that is a poor fit will make it blow up in your face, but that doesn't mean that sticking with the old code forever is the answer.
Besides, we use SAP at my place of work and are pretty damn successful.
This guy shouldn't have been moderated down. XFree HAS forked, so fragmentation could be a real concern.
> make it hard for driver vendors like NVidia to target XFree86's derivatives as a platform
XFree has a standard "driver model" that they use, and dislike of that actually one of the things movtivating the forks. So, new X servers won't use the same drivers, but the argument is that it will be easier to implement better drivers without being hamstrung by backward compatibility.
> Unless they agree on an API or similar framework
That API is X11R6 + extensions. Ultimately it matters little if you use XServer1 and I use XServer2 -- the difference wouldn't be visible to end users except maybe with some eyecandy features like transparency effects.
This is a far less serious problem than (say) KDE versus Gnome, which affects the end user in all sorts of ways, but yet people manage to survive.
False. Enterprise financial apps don't depend on changing hardware every year like graphics applications. And "just plain works" doesn't mean is maintainable. And I would doubt very strongly that someone knows 30-year-old-multi-million-lines-apps of financial code in Fortran well enough to be sure that it does what it is supposed to do...
"I think this line is mostly filler"
Hey, just sharing what I know..Jesus. Go and throw a hissy fit why don't you.
I spent alot of time with the Xouvert crew. From what I understand, Xouvert was formed largely out of this same frustration -- Neither developers nor companies could even get a word in edgewise with them, with means the whole project sits and stagnates... Well, until things like today's event, that is.
The core team dissolving is a good thing, as I see it. It clears the way for XFree to be less Cathedral and more Bazaar.
Bowie J. Poag
Looking at Xouvert and XServer there are quite a few people interested in maintaining and continuing XFree86. As far as I can see it the whole old structure of XFree86 and the Core-Team was one of the main issues holding the progress back, making it extremly difficult to get code merged into the core tree and such. Sure it will take a while until the dust has cleaned up, but a big clean-sweat is really needed for XFree86, its IMHO one of the main issue that hold GNU/Linux as a whole back from moving onto the cassual users desktop.
Yea, like most CIOs get their tech, political, and business news from /. You grossly overestimate /.'s influence.
FreeSpeech.org
Open source development is a Darwinian process. The strong prosper and the weak either die off or adapt themselves to survive in an isolated niche. If a project is so uninteresting or so obscure that it can't attract a new maintainer, then it deserves to die. The carcass remains part of the ecosystem -- scavangers are free to pick the bones for anything useful, or someone can come along and breathe new life into it.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
The disbanding of the current XFree86 core team does not mean an end to the continuing development of XFree86, it means a change of people recongised as being key players.
The biggest remaining question IMHO is whether there will be a expansion of cvs commit access. I think the former core team realises that new up and coming developers need to be added to the project to subtain the continuing improvement and work with others groups such as X.org, and freedesktop.org. To say nothing of expanding access to video card manufacturers so they can maintain and improve open source drivers for their cards (Most companies are at least partial supportive of 2D drivers, the real issues occur over 3D accelation).
I expect it will end up being a good thing.
Why should Nvidia and ATI support any kind of X server? Doesn't that just make it harder to produce a driver package? Not to troll, but I couldn't even find a good how-to doc for this on the xfree86.org site. At most just a few hints on bare-minimum functions.
Why can't we shove off the X11 and let Nvidia/ATI implement a raw OpenGL driver? Just let them support their hardware. Let them expose OpenGL, shaders, and overlay/MPEG stuff. Wouldn't it be fantastic not to need a new set of drivers for each XFree86 version?
Then if you want legacy X11 functions, just re-implement them to call OpenGL functions instead. There's no reason for an X line when the hardware is built for OpenGL lines.
In this scheme the X11 is sidebanded (networking) and wrappered (graphics calls) and graphics card driver updates are greatly simplified. Dare we hope it may spur more frequent driver updates as well?
Do you have any basis for these assertions (for example, the assertion that the problems in Linux video driver support are actually due to weaknesses in the design of X) or are you just being an idiot ? If the former is true, and you actually know something about writing video drivers, could you please share with us the basis for these assertions ?
You are using your own definition of core here. XFree defined core as a certain set of people. What they have found recently is that the "core" was not in fact at the core of development of XFree, and that those who were were better capable of filling that role. Grats to XFree for having the stones to make that call. THAT is probably the best example of what open source has going for it that proprietary software does not. GCC continues, but companies and steering commities have come and gone. Mozilla continues, but Netscape has come and gone and gone.... Open source endures.
Actually, 2002 was when the new standard went into effect. COBOL Standards has the link to the official ISO standards regarding COBOL. Also, COBOL is not dead. Far from it. COBOL can even be used to develop for the web as well. We are using Miami Univeristy's (of Ohio) DARwin product and it's entirely ported to run with Micro Focus COBOL Libraries/compilers and on multiple platforms including UNIX. DARwin, or Degree Audit, allows students to play a what if game comparing what they have taken with the program they initially intended and other programs. This allows students to see what else they have to take in order to get their degree if they want to switch majors. I have not seen software like it anywhere else. Most of the schools in Ohio use it. COBOL still has lots of use in it and it's just morphed in to doing different jobs.
The same wil go for Xfree. So what? The core has disbanded....long live the new open core.
Gorkman
I think we should congratulate the core team for doing the right thing. Its pretty rare for any institution to volintarily disband no matter how irrelevant it becomes. I can think of a few institutions a lot less relevant than this group that have continued plugging along for generations.
These people are showing maturity and class usually missing in the software industry. Just by taking this action, the team has refuted one of the more subtle FUD points out there, that projects will eventually peter out or be consumed by internal bickering.
It seems that the tone of this article is misleading; X development will continue on in good health.
However, I always find myself thinking about Y as an X replacement. It's certainly not the most mature option out there, but reading throught the PDF is a pleasure, as the author seems to have struck a great balance of power and simplicity.
Cheers.
This can be worked around. You move to a new core, and you toss out all the backwards compatibility crap. THEN, you add a backwards compatibility layer or module for the code that still needs it. Surely it would be easier for X than it was for, say, Apple, when they made apps designed for System 6 on an m68k processor successfully run under System 7 on a PowerPC processor. Thus you can get your brand new spiffy clean core with all the latest features while retaining legacy support. You just need to lose the idea that legacy support needs to be maintained at the core...
"Convictions are more dangerous enemies of truth than lies."
I think the problem was the core team had become too much about politics, and too little about software. Look at the well publicized event about Keith Packard being outed from XF86. Keith has contributed some of the most radical changes to the X server system in recent years (XRender, XRandR, fontconfig, etc). He was outed because he dared to try suggest to others that there should be a new project started to create a new X server to both encourage XF86 to be more active, and to also try to solve some of the lingering archetectural problems of XF86. It's ironic that he achieved his goals by being kicked out.
I used up all my sick days, so I'm calling in dead.
That's what is wrong with the support industry. Lazy asses who don't take pride in their work and have little or no patience. Way back in 94 when I was a Windows n00b, I used to call support and was appalled at how bad it was. Adaptec, S3, Microsoft... they all sucked. Within a year of using Windows (originally a Mac and Atari/Amiga guy here) I became my own support because I knew more than any of the jackasses on the other end of the phone. What really used to irk me was when I would call and have to walk through all the crap solutions that they were reading from a database even though I'd already done all of that. I'd tell them I already knew the outcome but they wanted me to do it anyway. Then in the end they would say "fdisk, format and re-install". Of course I wouldn't do that. I would dig up the info online or form other users and eventually solve the problem. That's when I realized that the fools that work support are just plain lazy, but your comment cinches it.
I deal with stupid users every day where I work, but I still help them even if it's the upteenth millionth time. I don't expect them to understand or to know what to do. Face it. Computers are STILL to hard to use for the average user because they are very complex machines. The only people that have a prayer of being able to use a computer to it's full capabilities are people who are very good at deductive logic and can understand abstractions easily. This is NOT the average human being. It's probably only about 10% of the population. About 75% would be the people who learn by wrote. They just know what buttons to puch when, but don't know why. So people and computers are meeting halfway, but when something doesn't work, it all falls apart. Face it... computers STILL suck for the majority of the population. (Note that the other 15% I didn't mention are comprised of both the guys with the bulbous heads who can do advanced physics calculations at 245 MIPS in their wetware and the other end of the spectrum with the small cranium that has trouble turning on a light and votes for George W. Bush because that's what TV told them everyone else is doing.)
Anyway... I guess a big part of the "American way" (these days read that as the way capitlist countries act) is to be lazy. Make millions while you sleep, yadda yadda...
Un-news
We are all looking forward to your patch. Just post it to bugs.kde.org and a maintainer will get right on integrating it. Do you think you can have it done before the KDE 3.3 string freeze? The translators need some time to do their work. Oh, and make sure you don't break any of the Qt themes --- the theme developers have enough work to do as it is, dealing with the new KWin API, and Qt 3.3 API changes. At least, don't break Plastik, because that'll probably be the default in 3.3.
Thanks!
A deep unwavering belief is a sure sign you're missing something...
... and quickly drop that pesky cross-platform portability it enjoys right now, at least until someone ports the Linux framebuffer device to non-Linux systems.
how to invest, a novice's guide
I love how people always compare things to Windows, which is the most backwards, un-advanced OS ever.
If you want to compare GUIs, compare with Mac OS X. OpenGL-accelerated drawing? Check. Incredibly rich graphics in apps? Check. No need to wait until 2006. And of course, by definition, right now X is still where it is now.
If Linux always strove to play catch-up with Windows, it would be horrible. Fortunately, it doesn't do that, except in the area of the GUI. It's no surprise, then, that Linux's GUI isn't very good.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
The problem with using C++ because it has resource management is that assumes the resource management model that C++ uses is appropriate for the problem space.
C++ doesn't "have resource management", it has standardized hooks for implementing whatever storage allocation and resource management strategies you want.
You wouldn't use C++ resource management for buffer cache handling in an OS, would you?
Using C++ would give you identical performance to what kernels currently do in C, yet it would greatly reduce the risk of bugs.
In any case, more generally, I see no problem using languages that actually have resource management built in. Some of those are badly designed or inefficient (VisualBasic, Java) and are therefore unsuitable, but others are perfectly fine (Modula-3, C#). Automatic resource management (garbage collection, etc.) is almost always more efficient than anything C programmers do by hand, and it is far less error prone.