There's a program called Bugnosis which can alert you of single-pixel tracking images like these, but can't block them (yet). It also only works with IE.
What browsers need is an option not to block all single-pixel images, but to block automatic loading of all images that aren't from the same server as the HTML page itself. Most of the tracking images are loaded from servers such as DoubleClick. Netscape has an option for only accepting cookies that are to be returned to the same server as the Web page came from; we need the same thing for images.
It's not that people don't care as much about software design as architecture; it's that when people look at software they see the interface, not the design.
If someone came to your architecture firm and asked for a nice house and you built something that looks beautiful but isn't earthquake-safe and has a slightly leaky basement, the buyer wouldn't be as quick to complain as if it was missing a few bathrooms or whatever. When you look at a house, you don't see behind the walls.
The same is true of software. Microsoft Outlook, for example, looks nice. It isn't visibly obviously broken, and you have to use it for a while to discover that it crashes and it's susceptible to script worms. You can't see the internal structure of the software, so when you run into problems you percieve them as isolated aberrations rather than symptoms of a deep-rooted structural problem.
So when a client asks for software, or for a house, they're asking for a product that looks nice on the surface and has the user-level features they want. They don't worry about the internal details, because that's your job. It just so happens that in architecture the structure is a little more visible to the end user than in software, thanks to the presence of support beams and wall placement and such.
Except XML isn't a predefined markup language; it's a framework for defining your own markup language. XML gives you a standard syntax for writing tags, but leaves it up to you (the application programmer) what the tags should be called and what their attribues mean.
So MS Word might indicate bold text using, say, <format textweight="+2">, while AbiWord might use an HTML-like <bold>, and both would be valid XML but the two programs would still be clearly using different file formats. It would, however, at least make it easier to write "converter" programs.
I agree that open-source office suites need to be able to import "standard" formats such as.doc; otherwise people would be forced to use proprietary products for their work because they need to be able to exchange files with others. Limiting options isn't what open-source software is about.:-)
According to the article, the model number will be printed on the chip instead of the clock speed, i.e. "A1600" for the 1600 model. Well, my 800MHz athlon says "A0800" on it, and the 1.2GHz that I recently borrowed from a friend says "A1200" on it. If they print "A1600" on a 1.4GHz chip, that's beyond obnoxious, it's misleading, because they're printing a higher number than the chip's clock rate in a spot that is established as the place where the clock rate goes.
I agree that they need to focus on educating consumers, in terms that consumers understand. For example, the relationship between clock rate and performance is something like the relationship between a tachometer and a speedometer: if the engine doesn't do much work per cycle, you'll go slower even if you crank it faster.
Education will help more than model numbers will; AMD is well-liked because they make a product that's honestly good, and playing tricks with the apparent clock speed will take away one of the qualities that makes them better than Intel. And especially, even if they use model numbers in marketing materials, they shouldn't hide the clock rate in places that most users don't see but can be very important to a technician, like the BIOS.
I don't quite buy into the GNU worldview that any software which isn't free is worthless and doesn't deserve to exist. There is some excellent commercial software out there, from simple games like Unreal up to insanely-expensive professional packages like Maya.
Nor do I buy into the idealistic OSI position that open-source software is superior to commercial software simply because the code is available.
However, I believe that the open-source development model is an effective way to write good software, and that I'm much more likely to find good free software for a particular task than good commercial software, and at a much better price.
I can understand wanting to "purify" the distribution by removing non-free. If non-free contained only fully-commercial apps, I'd be all for it. But, as many people have pointed out, it also contains lots of software that is only non-free in one tiny aspect. And to remove it would break many of the contrib packages. If Debian supports free software, why harm some of it by pulling its dependencies out from under it?
I think it's clear that there will always be somewhere to download non-free packages from. But if Debian gives up control of this archive, they'll make life more difficult for themselves when it comes time to fix up dependencies for a release. Debian should maintain control of the non-free section. They should make it more clear that non-free is not officially part of the distribution, and move the packages to non-free.debian.org or something like that. But don't just kill non-free. It's true that at some point those packages will no longer be necessary, but we'll know that's happened when none of them are actively maintained anymore.
No, I agree with this. If I hear a song I like, i.e. on the radio, I'll usually download some MP3s to see if there's enough good music on the CD to make it worth buying. But if I like the music, I will buy the CD, because it's worth the money to have the original high-quality printed cover and disc.
Slashdot Mirror
There's a program called Bugnosis which can alert you of single-pixel tracking images like these, but can't block them (yet). It also only works with IE.
What browsers need is an option not to block all single-pixel images, but to block automatic loading of all images that aren't from the same server as the HTML page itself. Most of the tracking images are loaded from servers such as DoubleClick. Netscape has an option for only accepting cookies that are to be returned to the same server as the Web page came from; we need the same thing for images.
It's not that people don't care as much about software design as architecture; it's that when people look at software they see the interface, not the design.
If someone came to your architecture firm and asked for a nice house and you built something that looks beautiful but isn't earthquake-safe and has a slightly leaky basement, the buyer wouldn't be as quick to complain as if it was missing a few bathrooms or whatever. When you look at a house, you don't see behind the walls.
The same is true of software. Microsoft Outlook, for example, looks nice. It isn't visibly obviously broken, and you have to use it for a while to discover that it crashes and it's susceptible to script worms. You can't see the internal structure of the software, so when you run into problems you percieve them as isolated aberrations rather than symptoms of a deep-rooted structural problem.
So when a client asks for software, or for a house, they're asking for a product that looks nice on the surface and has the user-level features they want. They don't worry about the internal details, because that's your job. It just so happens that in architecture the structure is a little more visible to the end user than in software, thanks to the presence of support beams and wall placement and such.
Except XML isn't a predefined markup language; it's a framework for defining your own markup language. XML gives you a standard syntax for writing tags, but leaves it up to you (the application programmer) what the tags should be called and what their attribues mean.
So MS Word might indicate bold text using, say, <format textweight="+2">, while AbiWord might use an HTML-like <bold>, and both would be valid XML but the two programs would still be clearly using different file formats. It would, however, at least make it easier to write "converter" programs.
I agree that open-source office suites need to be able to import "standard" formats such as .doc; otherwise people would be forced to use proprietary products for their work because they need to be able to exchange files with others. Limiting options isn't what open-source software is about. :-)
According to the article, the model number will be printed on the chip instead of the clock speed, i.e. "A1600" for the 1600 model. Well, my 800MHz athlon says "A0800" on it, and the 1.2GHz that I recently borrowed from a friend says "A1200" on it. If they print "A1600" on a 1.4GHz chip, that's beyond obnoxious, it's misleading, because they're printing a higher number than the chip's clock rate in a spot that is established as the place where the clock rate goes.
I agree that they need to focus on educating consumers, in terms that consumers understand. For example, the relationship between clock rate and performance is something like the relationship between a tachometer and a speedometer: if the engine doesn't do much work per cycle, you'll go slower even if you crank it faster.
Education will help more than model numbers will; AMD is well-liked because they make a product that's honestly good, and playing tricks with the apparent clock speed will take away one of the qualities that makes them better than Intel. And especially, even if they use model numbers in marketing materials, they shouldn't hide the clock rate in places that most users don't see but can be very important to a technician, like the BIOS.
I don't quite buy into the GNU worldview that any software which isn't free is worthless and doesn't deserve to exist. There is some excellent commercial software out there, from simple games like Unreal up to insanely-expensive professional packages like Maya.
Nor do I buy into the idealistic OSI position that open-source software is superior to commercial software simply because the code is available.
However, I believe that the open-source development model is an effective way to write good software, and that I'm much more likely to find good free software for a particular task than good commercial software, and at a much better price.
I can understand wanting to "purify" the distribution by removing non-free. If non-free contained only fully-commercial apps, I'd be all for it. But, as many people have pointed out, it also contains lots of software that is only non-free in one tiny aspect. And to remove it would break many of the contrib packages. If Debian supports free software, why harm some of it by pulling its dependencies out from under it?
I think it's clear that there will always be somewhere to download non-free packages from. But if Debian gives up control of this archive, they'll make life more difficult for themselves when it comes time to fix up dependencies for a release. Debian should maintain control of the non-free section. They should make it more clear that non-free is not officially part of the distribution, and move the packages to non-free.debian.org or something like that. But don't just kill non-free. It's true that at some point those packages will no longer be necessary, but we'll know that's happened when none of them are actively maintained anymore.
No, I agree with this. If I hear a song I like, i.e. on the radio, I'll usually download some MP3s to see if there's enough good music on the CD to make it worth buying. But if I like the music, I will buy the CD, because it's worth the money to have the original high-quality printed cover and disc.