It's not even that. Neither M$ nor "open source" are particularly innovative. In fact, the most innovative thing about "open source" is the model itself, not any results from it. Too much is taking what everyone else has done and trying to do it better, sometimes succeeding and sometimes not.
Saying that open source is not innovative is a furphy. Open source is a licensing model for software. Whether the software is or is not innovative has nothing to do with whether the software is open source.
I would rather say that most software is not innovative.
The hostility mystifies me. I'm a semi-active participant in the GCC mailing list, and the people who work on GCC are very helpful, open, and communicative. Some even thank me for my QA efforts.
Hostile people tend to shout the loudest.
I liked your article and hope to see more of them in the future.
On slashdot someone will complain that this charitable act is just an attempt to push his company's products on college students and the mods will make it +5 insightful.
Even worse, Slashdot will be crapflooded with dozens of people preemptively complaining about the Slashdot bias, and they will be moderated to +5 Insightful as well.
I can't be the only geek left that's used Linux for more than 5 years that actually prefers Gnome. But sometimes I feel like it.
Linux user since 1992 (and UNIX user since well before that) and using GNOME 2.6 here on an Apple PowerBook. Absolutely adore it. Sometimes find it hard to believe that the free desktops have gotten so good, so quickly.
I honestly think that this was just because Sun doesn't necessarily have a say in what goes into OpenOffice.org. Without this, the open-source world could simply just stick any technology into the OpenOffice.org codebase, and viola,
How would you stick a string instrument into OpenOffice?
I never would have been able to tell the difference until they hooked them up to some seriously high end speakers and lo and behold, you really could tell a difference.
Of course you can hear a difference. The valve is distorting the almighty crap out of the signal.
I'd rather hear what the artist recorded. Not some distorted butchery from a non-hifi.
You are now telling me that I have a social responsibility to "share" the fruits of my hard labor with some dumbass who made the poor decision to throw their life away on drugs or being too irresponsible?
Spot the US citizen. He's all "me me me, screw the poor, gimme what's mine". No wonder their society is screwed.
What sort of firewalls/antivirus programs are available for Linux? Are these integrated into the OS, or even necessary?
Some distributions integrate a firewall. For example, Fedora Core (new name for Red Hat) has an integrated firewall with GUI manager. All of the good distributions should do the same.
I'm not aware of any Linux distribution that integrates an antivirus program. There are free antivirus programs but they're aimed at people building mail servers and the like. Nothing for home users as far as I know. There aren't too many viruses for Linux though.
I'm looking for something that would give me a very general understanding of what's involved in setting up and maintaining a Linux system (I'm thinking Mandrake at the moment). Basically, I want just enough information to decide whether it's worth the bother to give it a try.
Ask yourself two questions:
What do I use my computer for?
What benefits do I expect from Linux?
If you're happy with your current software then don't bother. If you're unhappy with your current software then tell us what you dislike and we can tell you if Linux is better or worse.
Also bear in mind that Linux was weak areas (eg, games, off-the-shelf software). If any of those weak areas are relevant to you then don't bother.
If you're simply curious then try one of the many Live CDs (eg, Suse, Knoppix). Minimal fuss and you get a roughly accurate Linux experience.
Chances are you were running your X server with unaccelerated drivers - which offloads all the hard work to the CPU. In Panther, Quartz Extreme allows the transform and lighting engine of your GPU do all the hard work, leaving the CPU for things that a CPU should be doing it.
It's partly that. But Quartz is also fast on a plain unaccelerated 2D framebuffer. To prove this, simply run Panther inside Mac-On-Linux on the Linux PowerBook. Transparent windows and drop shadows are noticeably faster inside MOL than on the Linux desktop.
The issue is apparently the interaction between XAA (XFree86 Acceleration Architecture) and the XFree86 driver model. It isn't designed to handle Composite and Render properly. There is a hack in the 6.8 release so drivers will work, but suboptimally. There is considerable work going into a new driver architecture called Keith's Driver (kdrive) and XAA which will give near-Panther performance. But the powers that be have decided to leave those improvements until X.org 6.9. They want the extensions out there now, even if they're slow, so GNOME/KDE/others can start designing applications that use them.
Really great work, guys. I'm pround to see progress. But aside from these uses, what good will it do?
Well, I personally like the drop shadows. Makes it easier to see the outlines of windows.
But the real benefit is in the extensions themselves. The first extension is Render. It gives us hardware accelerated alpha-compositing rendering. Even if you never turn on drop shadows or transparency, you will benefit from this extension. It will allow applications to render fonts faster, draw images on screen much faster, etc. This extension lets you use your video hardware instead of wasting your CPU. The Cairo library is implementing vector graphics using Render, so all apps will have hardware accelerated vector graphics.
The second great extension is Composite. All windows are rendered offscreen and "composited" together on the display. That means clients no longer need to redraw their windows after an expose event! So your CPU will spend less time redrawing window contents, windows drags will be smoother, etc. Even better, you will be able to scale windows. Imagine proper zoom effects (like the MacOS X Genie effect) when you minimise a window, or scaling up a window to get a better look at it.
The third great extension is Damage. The current demonstration of Damage is transparency (when combined with Render and Composite) but it can do so much more. Consider your pager window (aka your virtual desktops). The miniature representations of the windows in the pager don't show the actual contents of the windows. With the Composite extension it is possible for the pager to draw a scaled down version of the actual window contents, and with the Damage extension the pager will know when the contents have changed. This can be done very efficiently because all the video data stays server side.
So even if you aren't impressed by the glossy demo, the underlying technology is very useful. I'm using an X.org build right now and dragging windows around is noticeably faster. No CPU is wasted on expose events when I bring a window to the foreground. There is less flicker because the windows aren't redrawing. And that's just a single extension. When GNOME/KDE start to use all the functionality offered by these new extensions we will see some impressive speedups.
You may want to take a closer look at the GPL. It does not forbid charging money for the program. You're just not allowed to charge more than a modest "copy fee" for the source. Since the source is still available for free, I fail to see how Zed is in violation.
The source code for the UNIX version is available for free. Apparently he is no longer providing the source code for the Windows version, despite the fact that several patches for the Windows version were supplied by the community.
I think he is on thin ice. Of course, there won't be any reprecussions unless somebody sues for copyright violation. The GPL itself has no teeth. Copyright law provides the teeth and you and I have no copyright claims to X-Chat.
If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.
It is about choice. You can choose to put the USB hook back and maintain the Philips webcam driver indefinitely in a separate kernel tree. The current kernel developers have the choice to drop that USB hook and tell the Philips webcam guy to find another way. The Philips webcam guy has the choice to reimplement the Philips webcam driver in userspace using libusb. Though as it is, he chose to have a hissy fit. His choice.
The mistake you've made is in thinking that "choice" is equivalent to "kernel developers give you all the options and you just choose a precanned solution from a checklist". That's not how it works. Get off your lazy butt and make things happen. Stop complaining that the kernel developers aren't doing things the way you want them to be done. That's their choice to make, not yours. Exercise your freedom of choice but don't expect others to do the work for you.
YOu mean like the firmware required to run the Hauppauge PVR250/350 cards? Or perhaps some of the SCSI drivers which require binary firmware to be downloaded? Hell I even think there are a few network cards which require it, too.
The kernel does support firmware. In fact, there has been significant effort recently to standardise the way that firmware is loaded to hardware by the kernel. The kernel developers don't seem to have a problem with firmware. Their beef is with binary drivers that run in the same address space as the rest of the kernel. I can see the kernel developer's point of view: they don't want to waste their time debugging around binary drivers.
And unless I'm misunderstanding the basic premise behind what's going on here this is likely only the start because, as I've mentioned, there are plenty of cards already supported by the kernel which require non-OSS parts to be part of the driver. What's next?
Hopefuly the nvidia drivers. As much as I like the nvidia company - they have some of the best minds in the business, they are good contributors to the state of the art, they pump significant money into R&D, and they play (mostly) nicely with the standards bodies - their binary drivers are retarding the future of Linux. If the nvidia binary drivers stopped working tomorrow then we'd hear the howls from millions of Linux users, but after the howling stopped there would be some real progress on pushing DRM and Xorg DDX forwards.
I think you are missing the point. Not every user cares what is in their kernel, much the same was as Windows users don't. They just want stuff to work.
True. Not every users cares. However in Linux land it's the kernel developers who make all the decisions. So what the kernel developers care about is all that matters. The most influential kernel developers (eg, Linus, Alan) have been consistent in their stance that they will not go out of their way to support binary modules. If a binary module breaks then tough luck.
If the kernel developers are wrong then the market will sort things out. One of the distros will produce a distribution with the USB hook patched back in. But I wouldn't hold my breath.
It is a victory for obsessive kernel-purists but a major loss for all Linux users.
Talk about flagrantly showing your bias. How about we rephrase that last sentence as...
It is a victory for kernel developers who do not have to waste their time with crash dumps from kernels linked to binary modules, for users who benefit from a more stable kernel, and for the advancement of Linux because it is not held back by archaic binary interfaces.
This is only a loss to those silly people who think that their $50 web cam is so damn important that all of the kernel developers should support binary interfaces to cater for undocumented video hardware. The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.
As for this..
So what's going to happen next? Well, I'm pulling the plug completely. I'm cleaning up this website, removing the downloads, documentation, FAQs, etc.
Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.
So what can you do about it? Not much, unless the kernel maintainers ease up a little, and stop being such fundamentalistic turds.
XFree86 wastes quite a bit of time on expose events, rather than remembering the contents of windows.
That is true in practise, though XFree86 has offered backing store for windows for ages. It just seems nothing ever used backing store, thus the expose events. The new Composite extension means that all windows effectively have backing store because all windows are drawn offscreen. With Composite running you can see a difference: exposed windows redraw significantly faster. That's because the exposed area is redrawn from the offscreen window instead of the exposed area being recalculated by the client. This also avoids a round-trip between the server and client (it's all done server side). The failing is that there is still some tearing because the redraw isn't sync'd to the vertical retrace. I think Keith and Jim have plans to resolve that problem as well.
Finally, even when client and server are on the same machine, display data typically needs to be copied, making performance about half as good as it could be.
That bit is not true. The X11 protocol stream is copied, not the display data. The performance hit was measured in the mid-90s at between 3-5% for operations like line draws, rectangle fills, screen blits, etc. The costs are dependent on the CPU speeds; as CPUs have gotten faster the costs of the X11 socket have decreased. I wouldn't be surprised if the actual costs of the socket are now sub-1%.
Of course, there are exceptional cases where significant display data is sent over the pipe. For example, Pixmaps and 3D texture data. There are extensions to handle those cases with zero copies.
In principle, I see what you're saying.. but in the end it is a business. If every business gave away everything they built, that would be called communism.
No that would NOT be communism. Communism is a scheme which abolishes inequalities in the possession of property, as by distributing all wealth equally to all, or by holding all wealth in common for the equal use and advantage of all.
Free software does NOT change the possession of property. It establishes a license which allows participation and distribution - an altruistic action - but the business or individual who wrote the code still owns the code insofar as copyright permits. It's the complete opposite of communism.
Free software is altruistic capitalism. NOT COMMUNISM.
My level of understanding on this is pretty low, but what differentiates DRI from SHM and DGA?
DGA is Direct Graphics Access. It allows a client to directly access the framebuffer. The client needs to handle all the pixel packing models (eg, RGB555, RGB888, RGBA8888) and work out the line strides and so on.
MIT-SHM is MIT Shared Memory. Though the magic of shared memory, the client and server share a piece of memory containing an XImage or a Pixmap. The client can change the contents and then tell the server to render the image/pixmap to screen.
DRI is the most complicated of the bunch. It stands for Direct Rendering Infrastructure. The basic explanation is that it allows a client to send commands directly to the video card. At the moment the only DRI implementation is OpenGL. So for example, quake3 links to libGL.so which is a DRI aware library. The library finds out which video card you have and loads the appropriate video card driver. This driver knows how to turn OpenGL commands into the hardware commands for your video card. These commands are shoved into a buffer which is provided by DRM (the DRI kernel module) and then blasted off to the video card. X only gets involved to setup cliplists and create windows; the actual 3D rendering is all done from the client directly to the hardware.
Those 3 extensions take care of the biggest bottlenecks in X: framebuffer access, image transfers, and 3D streams. There are some other issues with the X pipe - things like latency moreso than throughput - but I'm not sure that removing the X pipe would solve those problems.
The biggest issues with X on Linux right now are things like latency, single-threading, libraries that block, lack of double buffering, lack of synchronisation between window managers and widgets and clients, etc.
Slashdot Mirror
Yeah, but the military might bought with that 300 billion dollars is such a deterrent that nobody would dare attack US citizens on US soil.
Troll or insightful... both are correct.
Sorry dude. You yanks might think you have a right and a left but the rest of the world just sees a right and a more right.
You guys are so right of centre that you have long since lost sight of the true left.
Saying that open source is not innovative is a furphy. Open source is a licensing model for software. Whether the software is or is not innovative has nothing to do with whether the software is open source.
I would rather say that most software is not innovative.
Hostile people tend to shout the loudest.
I liked your article and hope to see more of them in the future.
Even worse, Slashdot will be crapflooded with dozens of people preemptively complaining about the Slashdot bias, and they will be moderated to +5 Insightful as well.
As society sees fit. That you can't fathom the difference is very enlightening.
Linux user since 1992 (and UNIX user since well before that) and using GNOME 2.6 here on an Apple PowerBook. Absolutely adore it. Sometimes find it hard to believe that the free desktops have gotten so good, so quickly.
How would you stick a string instrument into OpenOffice?
Of course you can hear a difference. The valve is distorting the almighty crap out of the signal.
I'd rather hear what the artist recorded. Not some distorted butchery from a non-hifi.
Spot the US citizen. He's all "me me me, screw the poor, gimme what's mine". No wonder their society is screwed.
Some distributions integrate a firewall. For example, Fedora Core (new name for Red Hat) has an integrated firewall with GUI manager. All of the good distributions should do the same.
I'm not aware of any Linux distribution that integrates an antivirus program. There are free antivirus programs but they're aimed at people building mail servers and the like. Nothing for home users as far as I know. There aren't too many viruses for Linux though.
Ask yourself two questions:
If you're happy with your current software then don't bother. If you're unhappy with your current software then tell us what you dislike and we can tell you if Linux is better or worse.
Also bear in mind that Linux was weak areas (eg, games, off-the-shelf software). If any of those weak areas are relevant to you then don't bother.
If you're simply curious then try one of the many Live CDs (eg, Suse, Knoppix). Minimal fuss and you get a roughly accurate Linux experience.
It's partly that. But Quartz is also fast on a plain unaccelerated 2D framebuffer. To prove this, simply run Panther inside Mac-On-Linux on the Linux PowerBook. Transparent windows and drop shadows are noticeably faster inside MOL than on the Linux desktop.
The issue is apparently the interaction between XAA (XFree86 Acceleration Architecture) and the XFree86 driver model. It isn't designed to handle Composite and Render properly. There is a hack in the 6.8 release so drivers will work, but suboptimally. There is considerable work going into a new driver architecture called Keith's Driver (kdrive) and XAA which will give near-Panther performance. But the powers that be have decided to leave those improvements until X.org 6.9. They want the extensions out there now, even if they're slow, so GNOME/KDE/others can start designing applications that use them.
Well, I personally like the drop shadows. Makes it easier to see the outlines of windows.
But the real benefit is in the extensions themselves. The first extension is Render. It gives us hardware accelerated alpha-compositing rendering. Even if you never turn on drop shadows or transparency, you will benefit from this extension. It will allow applications to render fonts faster, draw images on screen much faster, etc. This extension lets you use your video hardware instead of wasting your CPU. The Cairo library is implementing vector graphics using Render, so all apps will have hardware accelerated vector graphics.
The second great extension is Composite. All windows are rendered offscreen and "composited" together on the display. That means clients no longer need to redraw their windows after an expose event! So your CPU will spend less time redrawing window contents, windows drags will be smoother, etc. Even better, you will be able to scale windows. Imagine proper zoom effects (like the MacOS X Genie effect) when you minimise a window, or scaling up a window to get a better look at it.
The third great extension is Damage. The current demonstration of Damage is transparency (when combined with Render and Composite) but it can do so much more. Consider your pager window (aka your virtual desktops). The miniature representations of the windows in the pager don't show the actual contents of the windows. With the Composite extension it is possible for the pager to draw a scaled down version of the actual window contents, and with the Damage extension the pager will know when the contents have changed. This can be done very efficiently because all the video data stays server side.
So even if you aren't impressed by the glossy demo, the underlying technology is very useful. I'm using an X.org build right now and dragging windows around is noticeably faster. No CPU is wasted on expose events when I bring a window to the foreground. There is less flicker because the windows aren't redrawing. And that's just a single extension. When GNOME/KDE start to use all the functionality offered by these new extensions we will see some impressive speedups.
The source code for the UNIX version is available for free. Apparently he is no longer providing the source code for the Windows version, despite the fact that several patches for the Windows version were supplied by the community.
I think he is on thin ice. Of course, there won't be any reprecussions unless somebody sues for copyright violation. The GPL itself has no teeth. Copyright law provides the teeth and you and I have no copyright claims to X-Chat.
The FLOSS community doesn't claim to be the innovators. Microsoft does claim to be an innovator, though clearly they are not.
It is about choice. You can choose to put the USB hook back and maintain the Philips webcam driver indefinitely in a separate kernel tree. The current kernel developers have the choice to drop that USB hook and tell the Philips webcam guy to find another way. The Philips webcam guy has the choice to reimplement the Philips webcam driver in userspace using libusb. Though as it is, he chose to have a hissy fit. His choice.
The mistake you've made is in thinking that "choice" is equivalent to "kernel developers give you all the options and you just choose a precanned solution from a checklist". That's not how it works. Get off your lazy butt and make things happen. Stop complaining that the kernel developers aren't doing things the way you want them to be done. That's their choice to make, not yours. Exercise your freedom of choice but don't expect others to do the work for you.
The kernel does support firmware. In fact, there has been significant effort recently to standardise the way that firmware is loaded to hardware by the kernel. The kernel developers don't seem to have a problem with firmware. Their beef is with binary drivers that run in the same address space as the rest of the kernel. I can see the kernel developer's point of view: they don't want to waste their time debugging around binary drivers.
Hopefuly the nvidia drivers. As much as I like the nvidia company - they have some of the best minds in the business, they are good contributors to the state of the art, they pump significant money into R&D, and they play (mostly) nicely with the standards bodies - their binary drivers are retarding the future of Linux. If the nvidia binary drivers stopped working tomorrow then we'd hear the howls from millions of Linux users, but after the howling stopped there would be some real progress on pushing DRM and Xorg DDX forwards.
True. Not every users cares. However in Linux land it's the kernel developers who make all the decisions. So what the kernel developers care about is all that matters. The most influential kernel developers (eg, Linus, Alan) have been consistent in their stance that they will not go out of their way to support binary modules. If a binary module breaks then tough luck.
If the kernel developers are wrong then the market will sort things out. One of the distros will produce a distribution with the USB hook patched back in. But I wouldn't hold my breath.
Talk about flagrantly showing your bias. How about we rephrase that last sentence as...
This is only a loss to those silly people who think that their $50 web cam is so damn important that all of the kernel developers should support binary interfaces to cater for undocumented video hardware. The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.
As for this..
Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.
What a wanker.
That is true in practise, though XFree86 has offered backing store for windows for ages. It just seems nothing ever used backing store, thus the expose events. The new Composite extension means that all windows effectively have backing store because all windows are drawn offscreen. With Composite running you can see a difference: exposed windows redraw significantly faster. That's because the exposed area is redrawn from the offscreen window instead of the exposed area being recalculated by the client. This also avoids a round-trip between the server and client (it's all done server side). The failing is that there is still some tearing because the redraw isn't sync'd to the vertical retrace. I think Keith and Jim have plans to resolve that problem as well.
That bit is not true. The X11 protocol stream is copied, not the display data. The performance hit was measured in the mid-90s at between 3-5% for operations like line draws, rectangle fills, screen blits, etc. The costs are dependent on the CPU speeds; as CPUs have gotten faster the costs of the X11 socket have decreased. I wouldn't be surprised if the actual costs of the socket are now sub-1%.
Of course, there are exceptional cases where significant display data is sent over the pipe. For example, Pixmaps and 3D texture data. There are extensions to handle those cases with zero copies.
Yes! And those binary drivers should be for PPC32 because that's what I use.
What's that you say? You want the binary drivers to be for x86? Bingo. You understand the problem.
A "doona" is a big padded blanket. Typically stuffed with either feathers or wool. It's a bit like a quilt but without the fancy stitching.
"Hog" means to take selfishly. So if you "hog the doona" it means you've taken the majority share of the doona, leaving your partner freezing.
If you think that's hard to follow, wait until you hear Aussie rhyming slang: "take a butcher's at the trouble and strife, she's a corker".
No that would NOT be communism. Communism is a scheme which abolishes inequalities in the possession of property, as by distributing all wealth equally to all, or by holding all wealth in common for the equal use and advantage of all.
Free software does NOT change the possession of property. It establishes a license which allows participation and distribution - an altruistic action - but the business or individual who wrote the code still owns the code insofar as copyright permits. It's the complete opposite of communism.
Free software is altruistic capitalism. NOT COMMUNISM.
DGA is Direct Graphics Access. It allows a client to directly access the framebuffer. The client needs to handle all the pixel packing models (eg, RGB555, RGB888, RGBA8888) and work out the line strides and so on.
MIT-SHM is MIT Shared Memory. Though the magic of shared memory, the client and server share a piece of memory containing an XImage or a Pixmap. The client can change the contents and then tell the server to render the image/pixmap to screen.
DRI is the most complicated of the bunch. It stands for Direct Rendering Infrastructure. The basic explanation is that it allows a client to send commands directly to the video card. At the moment the only DRI implementation is OpenGL. So for example, quake3 links to libGL.so which is a DRI aware library. The library finds out which video card you have and loads the appropriate video card driver. This driver knows how to turn OpenGL commands into the hardware commands for your video card. These commands are shoved into a buffer which is provided by DRM (the DRI kernel module) and then blasted off to the video card. X only gets involved to setup cliplists and create windows; the actual 3D rendering is all done from the client directly to the hardware.
Those 3 extensions take care of the biggest bottlenecks in X: framebuffer access, image transfers, and 3D streams. There are some other issues with the X pipe - things like latency moreso than throughput - but I'm not sure that removing the X pipe would solve those problems. The biggest issues with X on Linux right now are things like latency, single-threading, libraries that block, lack of double buffering, lack of synchronisation between window managers and widgets and clients, etc.