Hmph. It sounds rather unlikely to me. It sounds like this is a fairly typical case of not checking the incoming data correctly. The fix for 2000/XP is to verify the messages. Why does adding a few checks to the incoming data buffers require a fundemental rearchitecting?
Well, I can't think of any real reason why they'd deliberately screw their customers over this, NT is going to be EOLd soon anyway, so we just have to take their word for it. Something still seems a bit wrong here though.
What's this, a free software music video? this is going to be one of dumbest, geekiest things ever created. I can't wait to watch it.
Oh my god no! Don't do it! The free software song is probably the biggest and best advert for Microsoft around. It's not only an incredibly bad song, but watching people actually sing it is fanatically embarassing and creepy. When RMS sang it at FOSDEM, it made the whole thing feel like some damn cult, as opposed to a bunch of geeks talking about cool stuff (like it was).
For those who don't know, the tune is some kind of Bulgarian folk dance, with a rhythm that is practically impossible for westerners to keep in their heads, and a tune that sounds like the composer got bored half way through and just stopped adding new notes in the middle of a bar.
That gives us about 2 yrs to get linux ready to take over. Can we?
If by take over, you mean the corporate desktop, then probably. If you mean all computers everywhere, then probably not.
Because if not, it will be vary bad. This is our chance. Once people are tied into palladium, they're stuck.
But that's OK, because I don't understand how people get "tied" into Palladium. It provides hardware-backed authentication and code signing, I thought. I haven't seen any hard theories as to why this would be a bad thing yet, apart from the interesting post above about how licensing fees could be used to seal off open source software, so giving proprietary software the security advantage.
Anyway, people are already tied to Windows, Intel, Office, god knows how much else. It's not like there isn't already huge amounts of work to do.
To be honest, I've thought for quite some time that people should be moving away from C and C++ for most stuff on UNIX, simply for the productivity benefits it would bring - the added security is OK, but as pointed out in the article, high level languages aren't a silver bullet.
Unfortunately, the vast majority of our desktop software on Linux is still being written in C or C++. Why? Well, those are the "native" languages of the two big desktop projects. C++ was chosen in KDE because, well, that's what Qt is. C was chosen in GNOME, ironically partly because it's easier to bind to other languages (when done properly).
I think the one of the reasons more software isn't written in higher level languages is that bindings are a PITA - not only do you have to manually produce them, but in the absence of solid dependancy management for all Linux distros, it grows your dependancy list as well. See the fate of Straw (an python RSS app) for an example of this.
What's really needed is a decent component model, making it easier to choose the right language for the job, instead of choosing a langauge because that's what all the libraries are written for, or because that's what everybody else uses.
Unfortunately not all translations are equal... I have a Dutch friend who prefers using English on his desktop, simply because not everything is translated, and when it is, it's not always professionaly done (windows and linux)
What we _really_ need, is to revamp the KDE/GNOME games collection around network based multiplayer, using ZeroConf and/or internet servers. The most popular game ever is Minesweeper (well, i don't know that, but who will argue it with me;) - just imagine how much of a killer app multiplayer Minesweeper or FreeCell would be:)
Argh. Please please please don't buy people books that include Linux inside the book. We routinely have people on linuxquestions.org attempting to install Redhat 7.1, or even a 6.x series OS, then wondering why none of their hardware works and they can't find any RPMs for it.
Best to just give them a few CDs you burnt along with the book.
While your.NET apps won't easily port, who says.NET is better than Java anyway? I'm no Java fan, but I've done some Java web app coding and some.NET development, and.NET is no better.
Ouch! That hurts!
My current assignment at work is to try and get this Java app working on Linux. Should be easy right? Wrong. It uses huge amounts of code via JNI to integrate with Windows, from embedding Internet Explorer to system tray icons. Does Java 1.4 work on Wine? Nope. Time to put on my debugging hat.
Ironically, my boss is considering porting to.NET - realistically, Java simply isn't good enough for client side work. A.NET app, hell, a pure Windows app, would be easier to get going on Linux than this thing we have currently, because at least with Mono the Windows integration is automatic, and I'd much rather simply implement a few SWF classes than screw about with the Sun JVM any day.
I thought they were going to limit the release to Mandrake Club subscribers to start with, and only make FTP access available much later. What happened to that idea?
...or just roll their own Photoshop killer based on the GIMP.
I don't get where that idea came from. The GIMP is great, and the latest 1.3.x versions are really, really nice (gotta love that gtk2 goodness), but ignoring the question of whether it could be a Photoshop killer or not, they'd need to completely rewrite the user interface, or rewrite most of GTK. This isn't a web browser, it's not just a case of a few buttons and "BrushedMetal=ON". Even if they rewrote the UI, all the plugins would still use GTK, the code differences would be so huge it would (at this point in time) almost certainly cause a fork, and in general it wouldn't be worth the effort.
There's also the obvious point that if Apple continue in producing all the apps for their platform, 3rd party developers could well see it as a sign of weakness - "they couldn't get a good web browser, or image editor, and their office suite is from Microsoft".... doesn't look good.
Apple's got pockets deep enough to do it, and marketing savvy that put FinalCut Pro on a Powerbook in the news vans of every TV station in the civilized world. You don't take on Apple and win.
I hope this is a troll. If not, your view of reality has been seriously warped by advocacy, and perhaps more worryingly by blind loyalty to a corporation. Apple have been trashed in the market again and again. They have precious few corporate friends - alienate them, and Apple will be in serious trouble.
I'd note that this one (related to symbol versions) is a problem whenever glibc is upgraded. One solution is to compile against the LSB, which will force your binary to use versions other than the latest ones. You lose new functionality, but it means your binaries have some chance of running on older distros.
If you can't run binaries under it that you could in the previous release, then it can't have the same major-number. Period.
I don't think it's quite that simple. You can still run some binaries compiled for redhat 7.3 under 8 - hell, I know the Linux games industry basically compiles on ancient distros to avoid being bitten by glibc symbol versions (glibc is backward but not forward compatible, for obvious reasons).
Usually the reason for the change in binary compatibility is due to library changes (e.g. new major version of glibc).
Well, again, glibc doesn't break backwards compatability (it does fix bugs which sometimes broken or unlucky apps rely on though). And in fact in the latest security updates to psyche, the new glibc is used instead of simply backporting the fix. AFAIK the only thing it breaks is Wine, and that's a special case.
So essentially Red Hat upgrades from 8 to 9 in ~6 months. No wonder no one wants to write general-release commerical apps for Linux.. by the time they develop & test their product, the distro essentially discontinues the release & doesn't support it.
I didn't see anything about the difference in numbers determining for how long a particular release was supported. In fact, I'm pretty sure that RH8.0 will be supported for 12 months - like they said it would be.
At this rate, I don't think we will ever convince developers of some great software (Adobe, Macromedia, etc) to port to Linux.
We won't convince them by taking a half-broken desktop that hardly anybody uses and claiming it's stable either.
Desktop Linux (which is what redhat linux is now) is still very much beta software. When it's actually fully competitive with Windows in every respect, then expect it to start slowing down in terms of churn. Everybodies up in arms because a major release number means things change and backwards compatability is sometimes lost. Maybe in future we'll all be using distros with 6 month release cycles still, but that doesn't mean there will be chaos in the realm.
But I'm sure that there are some really excellent features packed into 9 to make it worth being a full version upgrade and not a point upgrade (uhh.. not)
You make it sound like the major version number is based on how many cool features something has. It isn't. It's based on significant loss of compatability/significant changes in the API/ABI levels.
Pretty pointless question. Both of them have such miniscule marketshare that it's impossible to get useful statistics.
Also bear in mind that the question is slanted in favour of MacOS - it's possible to measure sales of Macs, whereas nobody knows how many people "switch" from Windows to Linux (of course, people rarely go cold turkey over night).
Hah, nothing can beat me. My first Linux install was Slackware into 10mb of free space on a DOS drive. I didn't know ANY unix commands, so I just watched what was being installed as the packages flashed by on the installer. It took me several days to figure out that in Linux you don't start at the root of the filing system like in DOS. I couldn't understand where all those files had gone:)
I didn't hate it though. The next time I tried Linux was SuSE with a KDE alpha version. Better, but still rather primitive compared to '95. Then in 2002 I was elite enough and Linux was easy enough that we met in the middle:)
Well, GLX allows you to do network transparent OpenGL, albiet quite slowly, but I am always hearing about how you can get higher framerates in Linux, so I don't think the X protocol is an impediment there.
Besides, useful desktop functionality is being phased in, albiet rather slowly, stuff like XRandR, RENDER and window transparency is hardly industrial requirements. I hope if there is a fork it won't slow things down even more.
I think I've supported my original claim quite well, honestly. Here's the thing: The average user doesn't really differentiate between the UI and the rest of the OS.
Inaccuracies and over-generalisations are fine in conversations with non-geeks, but you made a very specific claim, which means you have to have very specific arguments. If I said, "Ford cars suck, I always get stuck in a traffic jam whenever I'm in one", you'd point out I was being dumb, and you'd be right. This is the same thing.
Well, sure, that's correct - but the user simply runs his/her app in KDE or Gnome, sees the problems, and decides the whole interface is inferior.
That's fine. When you make strongly worded assertions about the quality of their work, expect people to hold you to a higher degree of accuracy than some random user.
As long as UI's like KDE or Gnome are built on top of xfree86, they'll suffer from any problems inherent in xfree86.
You're confusing X and XFree.
Mac OSX, as we can see, got around most of these deficiencies, and maybe much of that is because they didn't run on top of xfree86.
No, it has nothing to do with X or XFree, it's because MacOS is a) very new, b) controlled by a central organisation. They provide one widget toolkit (in reality 3, but they all look the same) and Mac apps are expected to use that. For historical reasons, the same is not true on Linux - that's more to do with politics than X.
On VNC/rdesktop: "Is there a case where THIS IS NOT SUFFICIENT?"
Basically yes - it's not uncommon to see machines dedicated to serving up individual applications, rather than entire desktops. The useful thing about X network transparency is that it acts at the windowing level.
There are other benefits to having an open network-aware protocol as well - namely implementation independance. That can be done with other things of course, but it makes it easy this way.
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?
Not sure why you think it's a burden. It doesn't slow things down if that's what you're thinking.
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?
Load balanced application servers to a thin client is one fairly common use case. Tech support is another (just ssh in, run any gui apps you need, person can continue working oblivious), and GUI oriented server administration. It's not as confusing as you might think.
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.
Having said all that, I'm now going to go out on a limb, and say that while network transparency is good, X11 does it at the wrong place. The approach taken by PicoGUI or Fresco, which not only does pixel/windowing operations but also widget heirarchies seems better. I'd note that this solution is not without its flaws - real world experience with Display PostScript/MacOS X/NeWS has shown that this kind of architecture could be the graphical equivalent of the microkernel, great in theory but flawed in practice.
Also, what does it say that KDE has rebuilt standalone remote-viewing functionality in the face of built-in X network transparency?
The KDE functionality was addressing a different need - most apps can't display on more than one screen, and they wanted an app that let somebody remote control the screen, for training perhaps.
In fact, I have a hard time seeing the reasoning behind such an application, it seems to be copying Windows for the sake of it. For tech support, connecting via ssh/X is far easier to work with, and over a LAN X is more efficient. I guess perhaps TightVNC is better over ADSL connections, but remote guis will always be painful over those kind of things, might as well stick to the command line.
The other (obvious) disadvantage of the approach VNC-style systems take is you waste a lot of bandwidth and time shipping images of stuff you aren't interested in - desktop wallpapers, start buttons, menu decorations and so on. X lets you work only with the app, and reuse existing taskbars etc.
Re:X *does* need a change
on
XFree86 Politics
·
· Score: 3, Insightful
Try it yourself - open an X application over a browser window and resize it. See the ghosts left behind? The weird way the contents of the window redraw at a different speed to the window resizing? Change workspaces and I can see the windows redrawing.
The window resize issue is a known one, and due mostly to a bug in the "smart" scheduling algorithm XFree uses, rather than any inherant slowness of X or XFree.
The lagging of the window contents behind the borders is likewise known, havoc pennington has been playing with XSYNC lately to try and reduce that issue.
Actually, it's more because (as far as I can tell) there is a truckload of work to do before that becomes viable.
For starters, XRender has to get a lot faster. It's currently not as well optimised as it could be.
Then you have to decide how to do this. People are throwing the term "transparency server" around, but nothing is decided - unbreaking save-unders/backing-stores might be a smarter route to go.
I'm not really qualified to say, I just read the mailing lists every so often. But it's not quite as simple as just yet another server.
The nature of the XFree development process has been the subject of arguments on the dev list for a long time now. When Mike Harris first wrote his advogato entry, that led to a flamewar for instance, though I can't really be bothered finding the link to it now (it was perhaps a month or two ago).
All you have to do is read the arguments over having a bugzilla to see that the XFree core team are stuck in their ways. Between them, Keith Packard and Jim Gettys have been trying to open them up, and to a large extent the XFree group has reformed - there are no more private mailing lists for instance (or so they claim).
Unfortunately, getting even that small step took huge effort. I can understand why Keith might want a fork. The issues people have with the XFree development process are hardly a secret, if he didn't mention this on the list, it's only because it's been discussed a thousand times before and yet another flamewar would achieve little.
The main problem with a union for computer programmers is that it's not a continuous job - if you go on strike for a week, then the project gets delayed for a week and that's about it. Usually, because what is being sold is a non-scarce resource, if programmers stop working the company can still make money, simply by selling the products you've already made.
Now network admins could have a much greater impact. Network admins are a continuous job - if your network goes down for a week, your company is screwed.
Not many companies have taken on MS and lived to tell the tale. Apple has.
Yeah, but mostly because MS was throwing resources at them during the trial to stop them going under and making them an actual de facto monopoly.
Do they honestly think Al Gore can bring something to Apple?
FWIW I don't think directors of a company actually do very much, it's mostly a symbolic post, a group of people management can ring up for contacts and advice. If you look at companies, often they are all on each others boards anyway.
Slashdot Mirror
Well, I can't think of any real reason why they'd deliberately screw their customers over this, NT is going to be EOLd soon anyway, so we just have to take their word for it. Something still seems a bit wrong here though.
Oh my god no! Don't do it! The free software song is probably the biggest and best advert for Microsoft around. It's not only an incredibly bad song, but watching people actually sing it is fanatically embarassing and creepy. When RMS sang it at FOSDEM, it made the whole thing feel like some damn cult, as opposed to a bunch of geeks talking about cool stuff (like it was).
For those who don't know, the tune is some kind of Bulgarian folk dance, with a rhythm that is practically impossible for westerners to keep in their heads, and a tune that sounds like the composer got bored half way through and just stopped adding new notes in the middle of a bar.
RMS can do great code. He's a lousy musician.
If by take over, you mean the corporate desktop, then probably. If you mean all computers everywhere, then probably not.
But that's OK, because I don't understand how people get "tied" into Palladium. It provides hardware-backed authentication and code signing, I thought. I haven't seen any hard theories as to why this would be a bad thing yet, apart from the interesting post above about how licensing fees could be used to seal off open source software, so giving proprietary software the security advantage.
Anyway, people are already tied to Windows, Intel, Office, god knows how much else. It's not like there isn't already huge amounts of work to do.
Unfortunately, the vast majority of our desktop software on Linux is still being written in C or C++. Why? Well, those are the "native" languages of the two big desktop projects. C++ was chosen in KDE because, well, that's what Qt is. C was chosen in GNOME, ironically partly because it's easier to bind to other languages (when done properly).
I think the one of the reasons more software isn't written in higher level languages is that bindings are a PITA - not only do you have to manually produce them, but in the absence of solid dependancy management for all Linux distros, it grows your dependancy list as well. See the fate of Straw (an python RSS app) for an example of this.
What's really needed is a decent component model, making it easier to choose the right language for the job, instead of choosing a langauge because that's what all the libraries are written for, or because that's what everybody else uses.
Unfortunately not all translations are equal ... I have a Dutch friend who prefers using English on his desktop, simply because not everything is translated, and when it is, it's not always professionaly done (windows and linux)
What we _really_ need, is to revamp the KDE/GNOME games collection around network based multiplayer, using ZeroConf and/or internet servers. The most popular game ever is Minesweeper (well, i don't know that, but who will argue it with me ;) - just imagine how much of a killer app multiplayer Minesweeper or FreeCell would be :)
Best to just give them a few CDs you burnt along with the book.
Ouch! That hurts!
My current assignment at work is to try and get this Java app working on Linux. Should be easy right? Wrong. It uses huge amounts of code via JNI to integrate with Windows, from embedding Internet Explorer to system tray icons. Does Java 1.4 work on Wine? Nope. Time to put on my debugging hat.
Ironically, my boss is considering porting to .NET - realistically, Java simply isn't good enough for client side work. A .NET app, hell, a pure Windows app, would be easier to get going on Linux than this thing we have currently, because at least with Mono the Windows integration is automatic, and I'd much rather simply implement a few SWF classes than screw about with the Sun JVM any day.
Strange, but true.
I thought they were going to limit the release to Mandrake Club subscribers to start with, and only make FTP access available much later. What happened to that idea?
I don't get where that idea came from. The GIMP is great, and the latest 1.3.x versions are really, really nice (gotta love that gtk2 goodness), but ignoring the question of whether it could be a Photoshop killer or not, they'd need to completely rewrite the user interface, or rewrite most of GTK. This isn't a web browser, it's not just a case of a few buttons and "BrushedMetal=ON". Even if they rewrote the UI, all the plugins would still use GTK, the code differences would be so huge it would (at this point in time) almost certainly cause a fork, and in general it wouldn't be worth the effort.
There's also the obvious point that if Apple continue in producing all the apps for their platform, 3rd party developers could well see it as a sign of weakness - "they couldn't get a good web browser, or image editor, and their office suite is from Microsoft" .... doesn't look good.
I hope this is a troll. If not, your view of reality has been seriously warped by advocacy, and perhaps more worryingly by blind loyalty to a corporation. Apple have been trashed in the market again and again. They have precious few corporate friends - alienate them, and Apple will be in serious trouble.
The C++ ABI change was mostly a one off.... unless your program did not follow the LinuxThreads standard, it should be fine.
I'd note that this one (related to symbol versions) is a problem whenever glibc is upgraded. One solution is to compile against the LSB, which will force your binary to use versions other than the latest ones. You lose new functionality, but it means your binaries have some chance of running on older distros.
I don't think it's quite that simple. You can still run some binaries compiled for redhat 7.3 under 8 - hell, I know the Linux games industry basically compiles on ancient distros to avoid being bitten by glibc symbol versions (glibc is backward but not forward compatible, for obvious reasons).
Well, again, glibc doesn't break backwards compatability (it does fix bugs which sometimes broken or unlucky apps rely on though). And in fact in the latest security updates to psyche, the new glibc is used instead of simply backporting the fix. AFAIK the only thing it breaks is Wine, and that's a special case.
I didn't see anything about the difference in numbers determining for how long a particular release was supported. In fact, I'm pretty sure that RH8.0 will be supported for 12 months - like they said it would be.
We won't convince them by taking a half-broken desktop that hardly anybody uses and claiming it's stable either.
Desktop Linux (which is what redhat linux is now) is still very much beta software. When it's actually fully competitive with Windows in every respect, then expect it to start slowing down in terms of churn. Everybodies up in arms because a major release number means things change and backwards compatability is sometimes lost. Maybe in future we'll all be using distros with 6 month release cycles still, but that doesn't mean there will be chaos in the realm.
You make it sound like the major version number is based on how many cool features something has. It isn't. It's based on significant loss of compatability/significant changes in the API/ABI levels.
Also bear in mind that the question is slanted in favour of MacOS - it's possible to measure sales of Macs, whereas nobody knows how many people "switch" from Windows to Linux (of course, people rarely go cold turkey over night).
Hmm, that'd be overlapping windows :)
I didn't hate it though. The next time I tried Linux was SuSE with a KDE alpha version. Better, but still rather primitive compared to '95. Then in 2002 I was elite enough and Linux was easy enough that we met in the middle :)
Well, GLX allows you to do network transparent OpenGL, albiet quite slowly, but I am always hearing about how you can get higher framerates in Linux, so I don't think the X protocol is an impediment there.
Besides, useful desktop functionality is being phased in, albiet rather slowly, stuff like XRandR, RENDER and window transparency is hardly industrial requirements. I hope if there is a fork it won't slow things down even more.
Inaccuracies and over-generalisations are fine in conversations with non-geeks, but you made a very specific claim, which means you have to have very specific arguments. If I said, "Ford cars suck, I always get stuck in a traffic jam whenever I'm in one", you'd point out I was being dumb, and you'd be right. This is the same thing.
Well, sure, that's correct - but the user simply runs his/her app in KDE or Gnome, sees the problems, and decides the whole interface is inferior.
That's fine. When you make strongly worded assertions about the quality of their work, expect people to hold you to a higher degree of accuracy than some random user.
As long as UI's like KDE or Gnome are built on top of xfree86, they'll suffer from any problems inherent in xfree86.
You're confusing X and XFree.
Mac OSX, as we can see, got around most of these deficiencies, and maybe much of that is because they didn't run on top of xfree86.
No, it has nothing to do with X or XFree, it's because MacOS is a) very new, b) controlled by a central organisation. They provide one widget toolkit (in reality 3, but they all look the same) and Mac apps are expected to use that. For historical reasons, the same is not true on Linux - that's more to do with politics than X.
On VNC/rdesktop: "Is there a case where THIS IS NOT SUFFICIENT?"
Basically yes - it's not uncommon to see machines dedicated to serving up individual applications, rather than entire desktops. The useful thing about X network transparency is that it acts at the windowing level.
There are other benefits to having an open network-aware protocol as well - namely implementation independance. That can be done with other things of course, but it makes it easy this way.
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?
Not sure why you think it's a burden. It doesn't slow things down if that's what you're thinking.
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?
Load balanced application servers to a thin client is one fairly common use case. Tech support is another (just ssh in, run any gui apps you need, person can continue working oblivious), and GUI oriented server administration. It's not as confusing as you might think.
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.
Having said all that, I'm now going to go out on a limb, and say that while network transparency is good, X11 does it at the wrong place. The approach taken by PicoGUI or Fresco, which not only does pixel/windowing operations but also widget heirarchies seems better. I'd note that this solution is not without its flaws - real world experience with Display PostScript/MacOS X/NeWS has shown that this kind of architecture could be the graphical equivalent of the microkernel, great in theory but flawed in practice.
Also, what does it say that KDE has rebuilt standalone remote-viewing functionality in the face of built-in X network transparency?
The KDE functionality was addressing a different need - most apps can't display on more than one screen, and they wanted an app that let somebody remote control the screen, for training perhaps.
In fact, I have a hard time seeing the reasoning behind such an application, it seems to be copying Windows for the sake of it. For tech support, connecting via ssh/X is far easier to work with, and over a LAN X is more efficient. I guess perhaps TightVNC is better over ADSL connections, but remote guis will always be painful over those kind of things, might as well stick to the command line.
The other (obvious) disadvantage of the approach VNC-style systems take is you waste a lot of bandwidth and time shipping images of stuff you aren't interested in - desktop wallpapers, start buttons, menu decorations and so on. X lets you work only with the app, and reuse existing taskbars etc.
The window resize issue is a known one, and due mostly to a bug in the "smart" scheduling algorithm XFree uses, rather than any inherant slowness of X or XFree.
The lagging of the window contents behind the borders is likewise known, havoc pennington has been playing with XSYNC lately to try and reduce that issue.
For starters, XRender has to get a lot faster. It's currently not as well optimised as it could be.
Then you have to decide how to do this. People are throwing the term "transparency server" around, but nothing is decided - unbreaking save-unders/backing-stores might be a smarter route to go.
I'm not really qualified to say, I just read the mailing lists every so often. But it's not quite as simple as just yet another server.
All you have to do is read the arguments over having a bugzilla to see that the XFree core team are stuck in their ways. Between them, Keith Packard and Jim Gettys have been trying to open them up, and to a large extent the XFree group has reformed - there are no more private mailing lists for instance (or so they claim).
Unfortunately, getting even that small step took huge effort. I can understand why Keith might want a fork. The issues people have with the XFree development process are hardly a secret, if he didn't mention this on the list, it's only because it's been discussed a thousand times before and yet another flamewar would achieve little.
Now network admins could have a much greater impact. Network admins are a continuous job - if your network goes down for a week, your company is screwed.
Yeah, but mostly because MS was throwing resources at them during the trial to stop them going under and making them an actual de facto monopoly.
Do they honestly think Al Gore can bring something to Apple?
FWIW I don't think directors of a company actually do very much, it's mostly a symbolic post, a group of people management can ring up for contacts and advice. If you look at companies, often they are all on each others boards anyway.