It's not really wrong, it's that the developers are all targeting to have it ready to go in 18 months. It basically just means planning more carefully, and having a large well-trained release team on the job of having a global view of what's going on so that large transitions can be ironed out as needed so they don't hold up things endlessly like they did for sarge. There are still huge release issues (as Andreas outlines) to go for etch, but transitions are generally better managed than in the past which will hopefully let us all make our target.
I don't know, but I'd imagine there will be a backport. It depends on whether libxrender can be easily backported, but I haven't looked at that myself.
Yeah, if you read that it says that 6.9 has been in experimental for a while and has been actively tested. That particular mail pertains entirely to getting it in to unstable.
6.9 is slated to go in to unstable very soon now. It's basically hinging on confirmation from the release team over the Xrender update (so as not to cause too many transitions going on at once), some basic package polish, and the time it takes to build and upload the monster. 6.9 has the exact same source base as 7.0, so users should have the newest drivers available to them soon without having to resort to massive workarounds. Work on 7.0 is currently ongoing in the X Strike Force subversion repo, but 6.9 should tide people over at least until 7.1 comes out, thereby letting the team get the modular packages in acceptable shape.
The way it was managed is that a skeleton tree was created with just the build system. A script was also written to symlink the actual sources from the monolithic tree to the modular skeleton tree, so that there was only one real tree to work from depending on what you were doing. Very late in the release process, the files were actually copied over so that the same changes had to go in to both places, but his happened so late that it didn't really matter so much. Now the old monolithic tree is closed for most commits and the modular tree is the de facto tree. All in all a very well planned and smooth transition.
Work on Xorg 7.0 for Debian is ongoing, but it's not at the point of going in to experimental yet. 6.9 has been in experimental for months now (the 6.8.99.903 is in fact 6.9 Release Candidate 3), and is very nearly ready to go in to unstable. Hopefully within a week, depending on how much time the holiday season steals away.
If you're interested in the modular work, the latest updates are here and here. It's sitting in the X Strike Force subversion repository, and once 6.9 gets all settled in the focus will shift entirely to getting the modular stuff ready to go for etch.
One of the fun things about these examples is that we don't know exactly how they happened. The possibility most people will jump to is that some random mutation(s) happened in the short time span that allowed the change to occur. The other possibility is that the population already contained within it the vast majority of the variation necessary to produce the change. If you shuffle the variations around, eventually you'll get a good combination without the need to mutate a thing. The interplay between these two possibilities isn't fully understood right now, and I'm personally pretty excited by the work in the field.
Try looking at the bibliography in that textbook for the references that the textbook authors drew from. You should be able to get easy access to the original journal articles documenting the work that provides the evidence that backs up the claims. If you don't believe the research documented in the papers, you can repeat it to see for yourself or you can try and provide positive evidence for an alternate explanation. All the printed text draws from physical evidence found by actual work done by the people who wrote the paper. It wasn't just made up to force you to think something.
The history of the horse is an old, and well understood example of a fairly drastic change over time as well. The transition from something sorta vaguely horse-like to the modern animal has been traced out.
And he didn't anticipate Barbara McClintock's idea of the way that eukaryotic cells arose via merger of independent single-cell organisms.
Great post, but this attribution is wrong. McClintock was responsible for finding that genes could move (using maize as her model system). Lynn Margulis came up with the idea of endosymbiosis leading to eukaryotic cells.
It's funny, I thought this too when I first started playing with ruby. But once I actually started using the language I found that I wrote in it completely differently than perl. Closer to what little python I had written actually.
Ruby looks like perl because it uses the $ and @ prefixes, but it uses them for completely different purpose: in perl they denote type where in ruby they denote scope. This turns out to be a nice feature, since you should be using some sort of notation in your variable names to denote scope anyway. It also permits the concept of duck typing throughout the ruby community, which is a key feature in making the language natural and easy to use.
Furthermore, people tend to write ruby with a lot more OO than in perl. Again, much closer to python.
Finally, good ruby code uses blocks everywhere. You can do code block-like things in perl or python, but in ruby it's very simple, fairly clean, and a very natural part of the language. I think this is what really distinguishes ruby from python fundamentally as a language. RoR, like any app written in a ruby style, makes extensive use of this feature and it allows some of the things that make people so excited about rails.
Oh, and the culture of the ruby community is such that people tend to write code that's fairly consistent between authors. Python is similar, although this seems to be more a function of the language itself than the community's culture. Perl's culture, on the other hand, encourages creativity and variety between authors, making it hard to read other people's code unless you know most of the camel book. I've never had any trouble reading someone else's ruby code, and I know about as much ruby as I know perl.
The gtk frontend to the installer doesn't use Xorg, but gtkfb on directfb instead. So you still won't be certain that Xorg will be correctly configured while you're installing. Sorry.
That's rather unfair. Sure, the author has a bias, but then given the total lack of coherent communication the X developers give to the rest of the free software community the only people who can write this sort of article are the type who are heavily involved and therefore not detached. So I'm not surprised it's heavy on opinion.
I think it's fair. It's pretty obvious that Jon wrote this to get a reaction from the community at large as well as the X developers. He wouldn't have posted it to the frontpage of slashdot otherwise, but would have simply stuck it on the site and maybe the wiki. It's basically trolling by definition. And I don't think it's fair to say that the X developers aren't communicating. That was true in the Xfree86 days, but not any longer. I think the X.Org people are doing a great deal, with the wiki and totally open lists, to keep communicating with the community at large. Most people have at least heard about the modularization effort, for example.
Given this constraint and the fact that the world is rapidly moving to 3D acceleration for all drawing, even on the desktop, it's completely reasonable for Jon to brush this off as "well that's just something we have to live with".
I don't think it's reasonable at all, since he's vehemently opposed to the real-world gains that can be had right now by things like EXA. For a fairly small amount of development effort you can get immediate functionality that was promised ages ago. Functionality that isn't at all certain when you choose the purely GL route. I'm not against moving towards a GL backend (I'm in favor of it) but the problems are complex and simply ignoring them by saying "well we just have to live with it" isn't going to solve things in the long run. It'll probably just dig us deeper in to our own grave. Personally, I'd rather see it done right.
Certainly I'd say nearly all the Linux users I know with ATI or nVidia cards do use the proprietary drivers already and don't have any hangups doing so. Are they perfect? No. But then the open source drivers for some cards are buggy as well, it's not like being open source is a magical recipe for bug-free software so this seems to be something of an academic point.
And I know tons of users who don't use the proprietary drivers. Which do you think I see more tech support issues with? If you want to complain about bandaids, complain about the proprietary drivers, since they are, at best, a short-term solution.
Furthermore, you've decided to ignore the non-linux platform issues that he rants about. I also didn't mention the low-end platforms that Linux currently needs to run on, that just can't do OpenGL at any sort of reasonably useable speed. X can scale in these sorts of directions, but it needs good drivers and a good model for doing so. Pushing madly ahead with a GL backend right this moment, despite having all sorts of poorly documented hardware on your system, may not be the best idea in the long-run for everyone.
Of course, rather than simply prove it to everyone by continuing on with his vision, albeit at a more reasonable pace, Jon decided to post this article to get everyone riled up. No one said he had to work full-time for no pay on Xegl, and it doesn't suprise me that he's imploded on it the same way Tom Lord did with arch. Fortunately, others are going to keep working on Xgl, Xegl, etc and they'll demonstrate whether or not Jon is right. They're the real heroes, and the fact that this article has managed to piss them off too is what really gets me.
Why can't a binary driver be accepted? I understand the implications. But seriously there are times when you need to look at the bigger picture.
I think you need to take your own advice. What happens when you go away because SGI won't pay you any more or decides to cancel your contract? Who can port the driver or make bufixes? In a year? Or two? What about all the users who are dependant on your driver?
The bigger picture is that we need open drivers so that we're not reliant on you or anyone else. If you want to distribute your own binary driver, go ahead, but the rest of the world needs that driver free.
Oh, and X.Org doesn't want things licensed under the GPL, but the MIT/X license, just like everything else in the tree.
A lot of this article is flamebait. Jon is pretty obviously bitter that the rest of the X developers didn't feel his sense of urgency in moving everything to Xegl right away.
The fundamental difficulty in getting specs to write and maintain open drivers for various video cards still exists, and any move to a fully OpenGL-based system will still have this barrier for a large number of people. If you've ever tried to run sw-based mesa, you know how slow it is, so on a fully OpenGL subsystem a large number of people will have to run it using the proprietary drivers. These work well for some people but for others they crash constantly and integrate poorly with the rest of their system. Ultimately, the X developers have their hands tied with these drivers because they can't fix them. Imagine a world where most everyone running all of X on these drivers, from 3D games to xterm, and you can see a serious problem.
Jon just brushes this off in his article ("believe it or not some people like the proprietary drivers"). Meanwhile, he calls the current effort to actually make the code work a "bandaid" even though it shows great promise to actually deliver useable drivers for a large number of people in a very short amount of time. He laments that X doesn't handle hotplugging well, but ignores the many efforts to implement this (check the X wiki for info) and the fact that no one has really figured out the best way to do it. He willfully ignores the fact that X needs to run on non-Linux systems, and as such it can't rely on many of the facilities he talks about.
Jon's definitely a smart guy, and he understands X incredibly well, but he's unwilling to accept that maybe he's not prioritizing things very well. He certaintly hasn't done a great job of selling Xegl to the rest of the X world, because if he had he might not have written this wonderfully elaborate troll.
Just because a totally random system could create a living system does not mean that's the actual mechanism by which it occurred and is currently occurring. We know natural selection is taking place, and have the evidence to demonstrate it, but there are details about the relative contributions of random (or semi-random) mutations and non-random natural selection to the process that need to be worked out in more detail.
Don't worry, belief in natural selection is about as safe as a belief that matter is made up of atoms.
In my eyes, OS X is open enough, having all of Darwin, most of Safari, and a bunch of other well documented APIs. Meanwhile it's competitors are all scrambling to try their best to beat it, but they simply can't match the momentum that's currently pushing Apple up the hill of beans Microsoft has accrewed over the past decade.
One day Apple will change.
One day, Steve Jobs won't be around any more and someone else without even a touch of his abilities will come in to run the company.
One day, Apple may well revert to the old Apple of the mid and late 90's.
Then what will you do with your "open enough" operating system?
That's entirely the problem. Debian has a zillion packages but has trouble releasing due to everyone's pet project, be it a pet architecture or a pet library or whatever. Not enough people want to put together a coherent distribution, they just want their little feature taken care of. Witness the number of people working on core pieces of Debian like apt, dpkg, aptitude, etc in comparison to the total number of Debian developers.
Maybe on travel to conferences and new hardware for compatability?
That's exactly it actually. Sending people to debconf (the debian conference) or for new hardware or replacement parts for old hardware. Also to ship donated hardware to people who'll put it to good use for the project.
I tried using arch to manage my debian packages, which have an upstreamversion-packageversion versioning number scheme. Both tla and baz complained that this wasn't an appropriate version number. This is beyond annoying, it makes arch unusable for my fairly simple needs.
Plus, the UI is completely tied to the implementation, so you have to know a ton about the underpinnings of arch in order to use tla. I don't want to know how arch does what it does. I don't care.
The baz people are working on fixing this, but there's a lot of problems to be fixed (see this for the massive list) and I think it'll take them some time to do so. Currently, baz is pretty buggy for me too, segfaulting on things like branching. That said, I have a lot of faith in both the baz team and Martin Pool, simply because they've thought things through very well. Currently though, tla and baz are nothing but an exercise in pain for me to use, and bzr isn't ready yet. I'll keep checking on them, because I really want to like them, but they make it so hard on me.
Debian Developers all have GPG keys that are signed by other Debian Developers, and are thus in the web of trust. The project would have no way of verifying that someone outside that web of trust even exists. Furthermore, their conduct within the project allows an easy reference point in choosing a candidate.
Debian has a security team who track and patch issues that apply to the stable distribution, even if upstream has written off that version of the software.
Slashdot Mirror
It's not really wrong, it's that the developers are all targeting to have it ready to go in 18 months. It basically just means planning more carefully, and having a large well-trained release team on the job of having a global view of what's going on so that large transitions can be ironed out as needed so they don't hold up things endlessly like they did for sarge. There are still huge release issues (as Andreas outlines) to go for etch, but transitions are generally better managed than in the past which will hopefully let us all make our target.
Thanks for having the best post on the subject in this entire thread.
I don't know, but I'd imagine there will be a backport. It depends on whether libxrender can be easily backported, but I haven't looked at that myself.
Yeah, if you read that it says that 6.9 has been in experimental for a while and has been actively tested. That particular mail pertains entirely to getting it in to unstable.
6.9 is slated to go in to unstable very soon now. It's basically hinging on confirmation from the release team over the Xrender update (so as not to cause too many transitions going on at once), some basic package polish, and the time it takes to build and upload the monster. 6.9 has the exact same source base as 7.0, so users should have the newest drivers available to them soon without having to resort to massive workarounds. Work on 7.0 is currently ongoing in the X Strike Force subversion repo, but 6.9 should tide people over at least until 7.1 comes out, thereby letting the team get the modular packages in acceptable shape.
The way it was managed is that a skeleton tree was created with just the build system. A script was also written to symlink the actual sources from the monolithic tree to the modular skeleton tree, so that there was only one real tree to work from depending on what you were doing. Very late in the release process, the files were actually copied over so that the same changes had to go in to both places, but his happened so late that it didn't really matter so much. Now the old monolithic tree is closed for most commits and the modular tree is the de facto tree. All in all a very well planned and smooth transition.
Work on Xorg 7.0 for Debian is ongoing, but it's not at the point of going in to experimental yet. 6.9 has been in experimental for months now (the 6.8.99.903 is in fact 6.9 Release Candidate 3), and is very nearly ready to go in to unstable. Hopefully within a week, depending on how much time the holiday season steals away. If you're interested in the modular work, the latest updates are here and here. It's sitting in the X Strike Force subversion repository, and once 6.9 gets all settled in the focus will shift entirely to getting the modular stuff ready to go for etch.
One of the fun things about these examples is that we don't know exactly how they happened. The possibility most people will jump to is that some random mutation(s) happened in the short time span that allowed the change to occur. The other possibility is that the population already contained within it the vast majority of the variation necessary to produce the change. If you shuffle the variations around, eventually you'll get a good combination without the need to mutate a thing. The interplay between these two possibilities isn't fully understood right now, and I'm personally pretty excited by the work in the field.
Genesis of course.
Try looking at the bibliography in that textbook for the references that the textbook authors drew from. You should be able to get easy access to the original journal articles documenting the work that provides the evidence that backs up the claims. If you don't believe the research documented in the papers, you can repeat it to see for yourself or you can try and provide positive evidence for an alternate explanation. All the printed text draws from physical evidence found by actual work done by the people who wrote the paper. It wasn't just made up to force you to think something.
The history of the horse is an old, and well understood example of a fairly drastic change over time as well. The transition from something sorta vaguely horse-like to the modern animal has been traced out.
It's funny, I thought this too when I first started playing with ruby. But once I actually started using the language I found that I wrote in it completely differently than perl. Closer to what little python I had written actually.
Ruby looks like perl because it uses the $ and @ prefixes, but it uses them for completely different purpose: in perl they denote type where in ruby they denote scope. This turns out to be a nice feature, since you should be using some sort of notation in your variable names to denote scope anyway. It also permits the concept of duck typing throughout the ruby community, which is a key feature in making the language natural and easy to use.
Furthermore, people tend to write ruby with a lot more OO than in perl. Again, much closer to python.
Finally, good ruby code uses blocks everywhere. You can do code block-like things in perl or python, but in ruby it's very simple, fairly clean, and a very natural part of the language. I think this is what really distinguishes ruby from python fundamentally as a language. RoR, like any app written in a ruby style, makes extensive use of this feature and it allows some of the things that make people so excited about rails.
Oh, and the culture of the ruby community is such that people tend to write code that's fairly consistent between authors. Python is similar, although this seems to be more a function of the language itself than the community's culture. Perl's culture, on the other hand, encourages creativity and variety between authors, making it hard to read other people's code unless you know most of the camel book. I've never had any trouble reading someone else's ruby code, and I know about as much ruby as I know perl.
The gtk frontend to the installer doesn't use Xorg, but gtkfb on directfb instead. So you still won't be certain that Xorg will be correctly configured while you're installing. Sorry.
Furthermore, you've decided to ignore the non-linux platform issues that he rants about. I also didn't mention the low-end platforms that Linux currently needs to run on, that just can't do OpenGL at any sort of reasonably useable speed. X can scale in these sorts of directions, but it needs good drivers and a good model for doing so. Pushing madly ahead with a GL backend right this moment, despite having all sorts of poorly documented hardware on your system, may not be the best idea in the long-run for everyone.
Of course, rather than simply prove it to everyone by continuing on with his vision, albeit at a more reasonable pace, Jon decided to post this article to get everyone riled up. No one said he had to work full-time for no pay on Xegl, and it doesn't suprise me that he's imploded on it the same way Tom Lord did with arch. Fortunately, others are going to keep working on Xgl, Xegl, etc and they'll demonstrate whether or not Jon is right. They're the real heroes, and the fact that this article has managed to piss them off too is what really gets me.
The bigger picture is that we need open drivers so that we're not reliant on you or anyone else. If you want to distribute your own binary driver, go ahead, but the rest of the world needs that driver free.
Oh, and X.Org doesn't want things licensed under the GPL, but the MIT/X license, just like everything else in the tree.
A lot of this article is flamebait. Jon is pretty obviously bitter that the rest of the X developers didn't feel his sense of urgency in moving everything to Xegl right away.
The fundamental difficulty in getting specs to write and maintain open drivers for various video cards still exists, and any move to a fully OpenGL-based system will still have this barrier for a large number of people. If you've ever tried to run sw-based mesa, you know how slow it is, so on a fully OpenGL subsystem a large number of people will have to run it using the proprietary drivers. These work well for some people but for others they crash constantly and integrate poorly with the rest of their system. Ultimately, the X developers have their hands tied with these drivers because they can't fix them. Imagine a world where most everyone running all of X on these drivers, from 3D games to xterm, and you can see a serious problem.
Jon just brushes this off in his article ("believe it or not some people like the proprietary drivers"). Meanwhile, he calls the current effort to actually make the code work a "bandaid" even though it shows great promise to actually deliver useable drivers for a large number of people in a very short amount of time. He laments that X doesn't handle hotplugging well, but ignores the many efforts to implement this (check the X wiki for info) and the fact that no one has really figured out the best way to do it. He willfully ignores the fact that X needs to run on non-Linux systems, and as such it can't rely on many of the facilities he talks about.
Jon's definitely a smart guy, and he understands X incredibly well, but he's unwilling to accept that maybe he's not prioritizing things very well. He certaintly hasn't done a great job of selling Xegl to the rest of the X world, because if he had he might not have written this wonderfully elaborate troll.
Just because a totally random system could create a living system does not mean that's the actual mechanism by which it occurred and is currently occurring. We know natural selection is taking place, and have the evidence to demonstrate it, but there are details about the relative contributions of random (or semi-random) mutations and non-random natural selection to the process that need to be worked out in more detail.
Don't worry, belief in natural selection is about as safe as a belief that matter is made up of atoms.
One day, Steve Jobs won't be around any more and someone else without even a touch of his abilities will come in to run the company.
One day, Apple may well revert to the old Apple of the mid and late 90's.
Then what will you do with your "open enough" operating system?
That's entirely the problem. Debian has a zillion packages but has trouble releasing due to everyone's pet project, be it a pet architecture or a pet library or whatever. Not enough people want to put together a coherent distribution, they just want their little feature taken care of. Witness the number of people working on core pieces of Debian like apt, dpkg, aptitude, etc in comparison to the total number of Debian developers.
I tried using arch to manage my debian packages, which have an upstreamversion-packageversion versioning number scheme. Both tla and baz complained that this wasn't an appropriate version number. This is beyond annoying, it makes arch unusable for my fairly simple needs.
Plus, the UI is completely tied to the implementation, so you have to know a ton about the underpinnings of arch in order to use tla. I don't want to know how arch does what it does. I don't care.
The baz people are working on fixing this, but there's a lot of problems to be fixed (see this for the massive list) and I think it'll take them some time to do so. Currently, baz is pretty buggy for me too, segfaulting on things like branching. That said, I have a lot of faith in both the baz team and Martin Pool, simply because they've thought things through very well. Currently though, tla and baz are nothing but an exercise in pain for me to use, and bzr isn't ready yet. I'll keep checking on them, because I really want to like them, but they make it so hard on me.
Debian Developers all have GPG keys that are signed by other Debian Developers, and are thus in the web of trust. The project would have no way of verifying that someone outside that web of trust even exists. Furthermore, their conduct within the project allows an easy reference point in choosing a candidate.
That was tried before. It didn't work out so well. The mailing list archives were deleted with a nice "fuck you all."
http://lists.debian.org/debian-security-announce/d ebian-security-announce-2004/msg00133.html
Debian has a security team who track and patch issues that apply to the stable distribution, even if upstream has written off that version of the software.