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.
The issue of open source 3D drivers is a real one, but I think Jon - like perhaps many of us - have accepted that the solutions to this lie at the political level and not at the grassroots campaigning level. Getting a fully open source nVidia driver is not merely a matter of asking forcefully enough, there are real economic and social problems that would need to be resolved first; nobody seems to be working on them.
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". 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.
Now judging from the X server lists there is this fundamental tension between those who believe a graphics architecture that basically requires Linux+accelerated/proprietary 3D drivers is wrong and should not be pushed, and those who like Jon think it is the future and should be supported by everybody. In the first camp are people to whom open source drivers are ideologically important along with BSD+Solaris users who won't get all the video work being done in the Linux kernel nor are they likely to get accelerated drivers from manufacturers. In the latter camp are those who are concerned with Linux being competitive Windows/MacOS X and those who have written off open video drivers as "you win some you lose some". Oh, and then there's Red Hat who are pushing the new architecture and also saying that it's OK because on some obscure/old cards there are open source drivers that accelerate 3D enough to run it.
I do agree with you on Exa - whether it's a bandaid or not, I'm sure it'll help some people.
Those of us with nVidia cards and games will have to wait until somebody, anybody, figures out why nVidia can't enable render acceleration by default in their drivers as apparently nVidia have little incentive to support Exa in their own drivers. Last I heard, they were waiting on a driver test suite for render acceleration.
App to GTK+ is just some function calls and data structure manipulation. Like on any OS widget toolkit.
GTK+ to Cairo is the same: Cairo and GTK+ are both shared libraries. Cairo takes drawing instructions from GTK+ and translates it into low level primitives that map directly to the XRENDER protocol.
XRENDER is just a wire format - a way to tell the X server what to do.
Xgl is an X server. You need a single entity controlling video hardware, otherwise things get complicated very fast. Existing GL drivers don't like being used by lots of apps at once as they were built primarily for games. By centralising control of the hardware you can optimise things and deal with existing hardware/drivers.
GLX->GL->hw - this is only temporary until enough infrastructure has been integrated into the kernel to obsolete the existing X server.
I'd just like to say thanks to Jon Smirl for writing this. I've been following X development for some time on the various mailing lists and so on, but for an outsider looking in it's nearly impossible to get an accurate picture of what's happening and which bits do what let alone what peoples plans are.
I think it's a crying shame Jon has stopped working on Xegl - we can only hope others will pick up from where he left off. It looks like Linux graphics is going to go through a series of half-way steps before arriving at fully OpenGL accelerated graphics: Exa based drivers first to speed up RENDER based graphics, then Xglx running on top of an existing X server to utilise its mode setting and input code, then finally Xegl which eliminates the existing X server entirely in favour of a new one that pipes all its drawing directly into the 3D pipeline.
To be fair to MS, Windows has always been aggressively optimised as they had such tight minimum system requirements. It sounds dumb now, but the colon in the clock doesn't blink because they found it was impacting Windows 95 performance on machines with 4mb of RAM. That sort of coding - perhaps overaggressive in this day and age - continues today as you can see from the often tortuous APIs which allow bizarre or exotic optimisations.
MacOS X on the other hand, started out almost unusably slow. Linux did not but there's still an awful lot of low hanging fruit there to harvest (try comparing boot times of Windows XP vs Fedora Core for instance).
I've been watching the fun you've had on lkml and wanted to say don't give up! The work you and your team are doing is wondeful.
If anything, I think you should stop focussing on getting Reiser4 into the kernel and instead start demonstrating the applications of your ideas on semantics. In other words - put what you've built to work outside the kernel and prove to people that they cannot live without a next-generation filing system. It may even mean doing things you have never done before, like creating a new distro derivative.
I know how emotionally draining free software politics can be, we get a lot of that in my own autopackage project. If it gets too much rather than risk burn out, go off and do your own thing for a while. If you really do have a better way people will join your banner;)
Given that rather shocking list of missing features, I'm assuming they are writing their own server from scratch and they haven't implemented file transfers yet (given how many ways to do that in Jabber there are I'm not surprised). Maybe S2S support is missing for the same reason?
Last I heard the official Jabber servers were pretty scalable but I'd bet a LOT that they were never designed to be scalable to Google sizes. Google writing their own distributed swarm of servers sounds more likely all the time to me.
Well, I was doing exactly the same thing the other day and didn't find it too hard. While you can't drag the text out to the size you want, you can specify the size in points and the text information is preserved just fine in a separate layer. To add effects to it, convert the text to a path. Now you can stroke it (to get an outline), or convert the path to a selection and use any of the standard effects.
Now, I guess that's not totally straightforward, but it's no worse than Photoshop or any other pro paint package. Doing nice effects with these packages requires a basic knowledge of theory like what a path or selection is. I don't think that's unreasonable.
Why would any "Linux Zealots" want Apple to be a competitor - they're even more closed and proprietary than Windows. Competition isn't necessarily good, if it's merely a choice between the lesser of two evils why bother?
Question is, what are the demographics of the UNIX vs Windows desktop users? I've supported secretaries/marketing types on Windows PCs before and yeah it isn't so much fun, but I suspect supporting them on Linux desktops wouldn't be great either... in fact supporting them period kinda sucks:)
I wouldn't read too much into UNIX vs Windows, it probably says more about the types who use those systems than anything else.
This will be fixed by the work Robert O'Callahan is doing with switching Gecko to use the Cairo graphics library. That'll allow "real" zooming for the first time, although text-only zooming is usually what I want.
I'm aware of that, though the writeup there is extremely biased. It makes it sound like cracking the HU stream was some trivial operation - in fact, it involved industrial espionage on a huge scale and at least one guy went to prison for over a decade (for leaking an EEPROM dump of the card).
Anyway, HU was switched off years ago. The current generation - P4 - remains uncracked, as the clock glitching loophole that broke the HU cards was fixed. Since then there have been no other widely available cracks and DirecTV piracy has basically been wiped out.
No, satellite TV streams are uncrackable, the public/private key encryption is too strong and the cipher rotates every 8-10 seconds anyway IIRC. Virtually all TV pirate "hacks" focus on getting the smartcard to decrypt the stream even for channels that you aren't subscribed to, and that involves reverse engineering and modifying the hardware itself which is very hard. Generally, "uncrackable" DRM just means making it so hard to crack that the only people with the skills and time don't bother.
Yeah, but imagine if some company produced the equivalent to the iPod or Firefox for reading e-books: some product that "gets it right". They could take off very quickly in that perspective. After all, I can imagine people saying "MP3s? You can only listen to them on a computer? What a royal pain in the ass!"
This has nothing to do with academic ideals, and as much as Slashdotters love to bitch about DRM and EULAs (which have nothing to do with it either) nobody ever suggests actual... you know... alternatives.
The publishing industry is going to love DRM, and I don't blame them. They saw the music industry get screwed over by wide-spread cultural acceptance of piracy, the movie industry then went through the same thing and now the book industry is about to experience the same thing.
Simply put, if people can steal something in a risk-free easy way, most people will do it. Therefore if you don't like DRM figure out a way to make it unnecessary. I'll give you a hint: the answer doesn't lie with it technology, nor does it involve sitting back and hoping evolution will figure out some new way for content-producers to make money, convenient though that'd be.
The only kinds of comments I'd want to see on a story like this are:
Right on, I wish them the best
or... "Here's an economic model that will allow for unlimited, payment-free distribution of content whilst still allowing musicians/movie producers/authors/programmers to make money - potentially, lots of money".
Perhaps unsurpisingly, it's far easier to make pithy comments about profit and community than read ecomonics textbooks.
Oh, one last thing... for those who think it's impossible to make unbreakable DRM I have a reality check for you: the music industry missed the boat and had no DRM, they got totally screwed. The movie industry did have DRM, but they messed up and there was a weakness in the key generation algorithm - still, it kept them protected from casual piracy for several years. The digital TV companies got it right: most use DRM with no cracks available and have done for years. Given hardware control, as you'd have for any mass-market ebook readers, I see no reason why "unbreakable" DRM cannot be produced. Not provable unbreakable of course, just hard enough to break that nobody bothers, like DirecTV has.
Well, the fact that it can't be parsed by anything is a deliberate design choice. The flexibility we get from exposing an API rather than a fixed package format lets us continue to improve the system for non-technical end users, who make up the vast majority of our users. The number of people who will benefit from the switch to LZMA compression in 1.2 vs the number of people who would benefit from being able to tell ahead of time what files a package would install is significant.
In general the design has always been "figure things out as the package runs, and don't try and guess what we'll need to do ahead of time". Modern Linux distributions are so fragmented and inconsistent it's the only sane way to ensure we can make them run everywhere.
If you look at the use cases for this sort of thing, very rarely do people want to get a dependency tree from an installer on MacOS X or Windows, and as that's where I think we should be heading platform-wise, it makes sense to give those use cases priority.
Autopackage isn't a package format, so Joeys experience is irrelevant. It's a way of distributing programs on Linux that happens to share a few attributes of traditional package systems, and also a few of traditional installer systems. The fact that it can't be parsed using Alien doesn't mean it was designed by monkeys, and anybody who asserts such a thing deserves to have their own credibility questioned.
I guess it would be overly cynical of me to point out that Ubuntu routinely pushes out several hundred megs of updates every few weeks... and the installer insists on downloading them if you have a network connection, wanted or not.
I don't think any distro that practically requires broadband to stay up to date (ie, all of them) is going to cut it for the third world. On the other hand, if you don't have the internet at all, then you don't really need updates do you?
"Supported" means that if it doesn't run, you get tech support. It also means they will continue to run properly in future versions. There are plenty of other apps that are unsupported which work fine though.
It's more difficult because broken, out of date or non-exsistant Wine packages are very common. For instance, where is the Wine package in Fedora? Why did Debian release a update fixing a non-existant security bug in Wine? Why did the official Wine Red Hat packager have to rewrite the Gentoo ebuilds for them as they were so broken?
What's the point of migrating from Windows to OS X? They simply aren't different enough to justify the cost, given that economically they're identical. Unless you really believe that MS is "pure evil" and Apple are saints, there's no evidence that a dominant Apple would be better than a dominant Microsoft.
He does that because that's what the majority of the world does. Red Hat, Novell, Debian... none of these are large enough or have enough mindshare to stand alone. When customers consider what to put on their servers, they think "Windows? Or Linux? Or Solaris?" etc. They don't consider each distro separately because they simply are not that different.
And for what it's worth, their Linux testing labs have all kinds of distros in them. The issues observed are (iirc from past interviews) generally the same.
When somebody says, "Linux has a problem with XYZ" the absolute worst answer you can give is "you used the wrong distro". That's like telling an environmentalist concerned about his car emitting greenhouse gases that he's using the wrong model. Not helpful. Yes, some other make of car may be marginally more green, but they're all in the same boat.
Slashdot Mirror
It does? This is news to me. Firefox as shipped by Fedora DOES use the new system.
The issue of open source 3D drivers is a real one, but I think Jon - like perhaps many of us - have accepted that the solutions to this lie at the political level and not at the grassroots campaigning level. Getting a fully open source nVidia driver is not merely a matter of asking forcefully enough, there are real economic and social problems that would need to be resolved first; nobody seems to be working on them.
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". 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.
Now judging from the X server lists there is this fundamental tension between those who believe a graphics architecture that basically requires Linux+accelerated/proprietary 3D drivers is wrong and should not be pushed, and those who like Jon think it is the future and should be supported by everybody. In the first camp are people to whom open source drivers are ideologically important along with BSD+Solaris users who won't get all the video work being done in the Linux kernel nor are they likely to get accelerated drivers from manufacturers. In the latter camp are those who are concerned with Linux being competitive Windows/MacOS X and those who have written off open video drivers as "you win some you lose some". Oh, and then there's Red Hat who are pushing the new architecture and also saying that it's OK because on some obscure/old cards there are open source drivers that accelerate 3D enough to run it.
I do agree with you on Exa - whether it's a bandaid or not, I'm sure it'll help some people.
Those of us with nVidia cards and games will have to wait until somebody, anybody, figures out why nVidia can't enable render acceleration by default in their drivers as apparently nVidia have little incentive to support Exa in their own drivers. Last I heard, they were waiting on a driver test suite for render acceleration.
App to GTK+ is just some function calls and data structure manipulation. Like on any OS widget toolkit.
GTK+ to Cairo is the same: Cairo and GTK+ are both shared libraries. Cairo takes drawing instructions from GTK+ and translates it into low level primitives that map directly to the XRENDER protocol.
XRENDER is just a wire format - a way to tell the X server what to do.
Xgl is an X server. You need a single entity controlling video hardware, otherwise things get complicated very fast. Existing GL drivers don't like being used by lots of apps at once as they were built primarily for games. By centralising control of the hardware you can optimise things and deal with existing hardware/drivers.
GLX->GL->hw - this is only temporary until enough infrastructure has been integrated into the kernel to obsolete the existing X server.
I think it's a crying shame Jon has stopped working on Xegl - we can only hope others will pick up from where he left off. It looks like Linux graphics is going to go through a series of half-way steps before arriving at fully OpenGL accelerated graphics: Exa based drivers first to speed up RENDER based graphics, then Xglx running on top of an existing X server to utilise its mode setting and input code, then finally Xegl which eliminates the existing X server entirely in favour of a new one that pipes all its drawing directly into the 3D pipeline.
Question is, how long will it take?
MacOS X on the other hand, started out almost unusably slow. Linux did not but there's still an awful lot of low hanging fruit there to harvest (try comparing boot times of Windows XP vs Fedora Core for instance).
I've been watching the fun you've had on lkml and wanted to say don't give up! The work you and your team are doing is wondeful.
If anything, I think you should stop focussing on getting Reiser4 into the kernel and instead start demonstrating the applications of your ideas on semantics. In other words - put what you've built to work outside the kernel and prove to people that they cannot live without a next-generation filing system. It may even mean doing things you have never done before, like creating a new distro derivative.
I know how emotionally draining free software politics can be, we get a lot of that in my own autopackage project. If it gets too much rather than risk burn out, go off and do your own thing for a while. If you really do have a better way people will join your banner ;)
Last I heard the official Jabber servers were pretty scalable but I'd bet a LOT that they were never designed to be scalable to Google sizes. Google writing their own distributed swarm of servers sounds more likely all the time to me.
Now, I guess that's not totally straightforward, but it's no worse than Photoshop or any other pro paint package. Doing nice effects with these packages requires a basic knowledge of theory like what a path or selection is. I don't think that's unreasonable.
Why would any "Linux Zealots" want Apple to be a competitor - they're even more closed and proprietary than Windows. Competition isn't necessarily good, if it's merely a choice between the lesser of two evils why bother?
I wouldn't read too much into UNIX vs Windows, it probably says more about the types who use those systems than anything else.
This will be fixed by the work Robert O'Callahan is doing with switching Gecko to use the Cairo graphics library. That'll allow "real" zooming for the first time, although text-only zooming is usually what I want.
Anyway, HU was switched off years ago. The current generation - P4 - remains uncracked, as the clock glitching loophole that broke the HU cards was fixed. Since then there have been no other widely available cracks and DirecTV piracy has basically been wiped out.
No, satellite TV streams are uncrackable, the public/private key encryption is too strong and the cipher rotates every 8-10 seconds anyway IIRC. Virtually all TV pirate "hacks" focus on getting the smartcard to decrypt the stream even for channels that you aren't subscribed to, and that involves reverse engineering and modifying the hardware itself which is very hard. Generally, "uncrackable" DRM just means making it so hard to crack that the only people with the skills and time don't bother.
Yeah, but imagine if some company produced the equivalent to the iPod or Firefox for reading e-books: some product that "gets it right". They could take off very quickly in that perspective. After all, I can imagine people saying "MP3s? You can only listen to them on a computer? What a royal pain in the ass!"
The publishing industry is going to love DRM, and I don't blame them. They saw the music industry get screwed over by wide-spread cultural acceptance of piracy, the movie industry then went through the same thing and now the book industry is about to experience the same thing.
Simply put, if people can steal something in a risk-free easy way, most people will do it. Therefore if you don't like DRM figure out a way to make it unnecessary. I'll give you a hint: the answer doesn't lie with it technology, nor does it involve sitting back and hoping evolution will figure out some new way for content-producers to make money, convenient though that'd be.
The only kinds of comments I'd want to see on a story like this are:
Perhaps unsurpisingly, it's far easier to make pithy comments about profit and community than read ecomonics textbooks.
Oh, one last thing ... for those who think it's impossible to make unbreakable DRM I have a reality check for you: the music industry missed the boat and had no DRM, they got totally screwed. The movie industry did have DRM, but they messed up and there was a weakness in the key generation algorithm - still, it kept them protected from casual piracy for several years. The digital TV companies got it right: most use DRM with no cracks available and have done for years. Given hardware control, as you'd have for any mass-market ebook readers, I see no reason why "unbreakable" DRM cannot be produced. Not provable unbreakable of course, just hard enough to break that nobody bothers, like DirecTV has.
In general the design has always been "figure things out as the package runs, and don't try and guess what we'll need to do ahead of time". Modern Linux distributions are so fragmented and inconsistent it's the only sane way to ensure we can make them run everywhere.
If you look at the use cases for this sort of thing, very rarely do people want to get a dependency tree from an installer on MacOS X or Windows, and as that's where I think we should be heading platform-wise, it makes sense to give those use cases priority.
Autopackage isn't a package format, so Joeys experience is irrelevant. It's a way of distributing programs on Linux that happens to share a few attributes of traditional package systems, and also a few of traditional installer systems. The fact that it can't be parsed using Alien doesn't mean it was designed by monkeys, and anybody who asserts such a thing deserves to have their own credibility questioned.
I don't think any distro that practically requires broadband to stay up to date (ie, all of them) is going to cut it for the third world. On the other hand, if you don't have the internet at all, then you don't really need updates do you?
"Supported" means that if it doesn't run, you get tech support. It also means they will continue to run properly in future versions. There are plenty of other apps that are unsupported which work fine though.
WineHQs game support has come on tremendously lately, it's not just for apps anymore.
Or ... you could use the "Fonts" control panel applet and disable AA text there!
It's more difficult because broken, out of date or non-exsistant Wine packages are very common. For instance, where is the Wine package in Fedora? Why did Debian release a update fixing a non-existant security bug in Wine? Why did the official Wine Red Hat packager have to rewrite the Gentoo ebuilds for them as they were so broken?
You know, that's one of the key selling points of CrossOver - it comes in a Loki setup. Why no autopackage? Well, I guess Mike is just a slacker ;)
What's the point of migrating from Windows to OS X? They simply aren't different enough to justify the cost, given that economically they're identical. Unless you really believe that MS is "pure evil" and Apple are saints, there's no evidence that a dominant Apple would be better than a dominant Microsoft.
And for what it's worth, their Linux testing labs have all kinds of distros in them. The issues observed are (iirc from past interviews) generally the same.
When somebody says, "Linux has a problem with XYZ" the absolute worst answer you can give is "you used the wrong distro". That's like telling an environmentalist concerned about his car emitting greenhouse gases that he's using the wrong model. Not helpful. Yes, some other make of car may be marginally more green, but they're all in the same boat.