A retired PC doesn't necessarily work well as a file or web server, particularly a low-traffic home server. It probably consumes more power and makes more noise than a "proper" solution, for example.
A kitchen computer ideally should take up little desk space (most kitchens are already cramped, which is why kitchen audio players typically mount under a cabinet), and be protected against a harsh environment. An easily-cleaned touchscreen computer is probably the most ideal solution, not an old CRT iMac.
Your PDA alarm clock is problematic as well. It almost certainly consumes a lot more power than any $10 alarm clock. I can't even remember when I last replaced the batteries to my alarm clock.
While I agree with your general sentiment against the disposable culture, there is a point past which insistence on old technology doesn't make sense either in terms of money, time, comfort, or environmental concerns. Proponents of a counterculture need to use old things better than "just because" for the argument to be convincing.
You mean, Apple has pulled back software after it has been released to the Internet? That's rich! Did that work for the DeCSS code?
Apple has done it before, but this doesn't appear to be simply a case of making something disappear. The nature of the program does not subvert Apple product features, etc, and doesn't appear to hurt Apple overtly.
Ownership of the code means much more than being able to pull it. It means they can enhance it and integrate it into a future product. Without support or hope of future versions, and with an Apple-branded enhanced version as competition, any copies that are floating around probably aren't worth worrying about.
Releasing a reproducing bio-weapon with no known antidote requires a level of insanity unmatched in human history. Never before could anything truly endanger the entire human race, not even in the worst nuclear holocaust scenarios of the Cold War.
You are wrong. The prevailing nuclear doctrine of the Cold War was known as "Mutually Assured Destruction", in which both powers knew that escalated use of nuclear weapons will lead to doom for all. A hypothetical unstoppable virus has the same effect, so a doomsday virus to ward off attacks is terrifying, but not insane. That's what nuclear weapons aimed at other nuclear states have been for decades.
If I say, "motorcycles are ready for the road," will people think that means that everybody who uses a car should be able to get on a motorcycle and start riding around?
No, it's more like saying "the Segway is ready for the road". But only about 5% of the existing roads, so your mileage may vary. It is technically true, but meaningless to a large percentage of people.
Linux can compete with Windows in it's market.
Linux is competitive with Windows in under 5% of the Windows market. The fact is that most computer users (including some savvy experienced users) will not consider primarily using Linux for a variety of reasons. Again, you like to use phrases that are technically true, but semantically misleading.
"Linux is ready for desktop use. It may or may not be able to provide your desktop needs." I don't think most people will have any trouble understanding that.
It all has to do with context. If you are speaking to a convention of librarians, then the qualification is extraneous. Either Linux is ready for them or it is not. If you are speaking to an unspecifiable general audience (an article for a mainstream magazine, for instance), then the qualification is necessary but your message is diminished. Your readers will still walk away not knowing if Linux will work for them.
This appears to be the way you like to talk or write, and I'm not going to expend too many bits trying to change that. I'm just pointing out that making a bold initial statement and following up with a YMMV caveat is usually not effective communication. Think tabloid headlines.
Your thinking makes no sense to me. Linux is ready for the desktop, and has been for some time. It is not ready for everybody's desktop
I don't disagree with your point, but we can't always insist on the most precise language if we wish to be understood. If I tell somebody "Linux is ready for the desktop", they'll probably think it means that Linux is ready to compete directly against Windows XP and Mac OS X in their respective markets. By declaring that prematurely, you will irritate the people who believed you (heard what they think you said), tried Linux, and became disappointed. I imagine you can see how that is counterproductive, and how the same users might discount your words in the future.
Communication does not end when the words leave your mouth. They end when the words enter the listener's brains and are comprehended correctly.
Why on earth would anyone want to use such a cliched effect anyway?
Wow, the skeptics are on the offensive today.
I cited that as an example of a familiar special effect. However, there are other things you can do with multiple cameras. For example, a 360-degree photograph of an animate object, like a rabbit or a baby. You can build yourself a toy "3-D" camera (stereo vision) for $11 x 2, rather than $37 x 2.
You can also think of shots where the camera itself is sacrificed, or potentially sacrificed. For example, a custom modification can allow the camera to fit in impossibly tight spaces. It can also be embedded into a remote-control car or plane.
Use your imagination.
And why would they spend several thousand dollars to do so?
That's the whole point. With the $11 camera, you can buy 50 of them with just $550. With the $37 camera, it'll cost $1,850. The difference can make or break the effect for a small film, for instance.
You had an excellent argument right up the point where you said "synchronize their shutters" - which is impossible with this particular camera
If you read the articles linked, you might have found the following line:
I then used Mark Hopkins' freeware disassembler "Dis8051" to translate the binary code to human-readable format (I fixed a major bug and added improvements - download here).
So yes, people have been able to modify the firmware to a limited degree. It may also be possible to simply use a hardware hack on the "shoot" buttons. Among the hackers' objectives is to shoot in a lower JPEG quality to store more shots and to shoot continuously (webcam), so I think a synchronized trigger is not terribly far-fetched.
The point is, somebody asked, why not use a $37 camera? I responded, if I wanted to do the Matrix effect, using the Dakota will cost me $1,300 less for 50 cameras.
you can get a logitech pocket digital for like 37 dollars; basically same specs, but looks a whole lot nicer and does exactly the same thing
Really? What if I want to set up 50 of these things and synchronize their shutters to take Matrix-style motion effects shots? Suddenly the price difference is $1,300.
how should one go about testing systems to obtain the fairest results?
All benchmarks are fair unless you deliberately picked the criteria to favor one candidate over the other, or overgeneralize the collected results beyond reason. The bigger question is whether they are representative or real performance in real application.
What compilers are evenly matched amongst different hardware?
Compilers are not evenly matched among different source code, nevermind different hardware. I don't see how you can possibly achieve this, especially with a free compiler where developer interest and expertise (which is mostly beyond your control) direct how well it will perform on each platform.
Finally, should such tests take into account the sub-systems available, such as 3D performance and the various Quake-FPS metrics?
Depends on what you're testing. If it's a CPU versus CPU comparison, perhaps not. If it's a system versus system comparison, definitely.
I would suggest taking code from various free projects. For example:
use Gecko or KHTML to render some known complicated web pages
use POV-Ray to render some complex scenes
use GIMP graphics filters to modify big images
You can also start with a CS data structures book, and implement various basic and well-known algorithms and apply them to big data sets.
I mean how many distributions are perfect, the first time around.
I thought one major advantage of free software was that we could afford to release only when ready, rather than when the marketing department demanded? The article wasn't demanding "perfect". Some RPMs included in the distribution that wouldn't install!
I'm not anti-Linux. I like it so much that I want us to use on it the same (or higher) standards we judge software we pay for.
When executives who buy Linux-based phones note how reliable the OS is on their phone, it's a short mental leap to see it's reliability on the internet, servers, phone systems, and eventually the growing server and desktop.
First of all, they are unlikely to know or care what OS the phone runs. Secondly, you are asking for a (possibly correct) conclusion based on faulty reasoning, which is a terribly slippery slope. There are many phone (or PDA) operating systems, and most of them are utterly unsuitable on servers, the phone system, or a desktop computer. Finally, neither cellular carriers nor the OEMs who make the phones have strong incentives to emphasize "Linux", because they each have their own brand to promote.
I like Linux, too, but I fear you are overly optimistic.
You're assuming that the only revenue is coming from the iTMS.
No, I'm not. The point is, complaining about the $0.01 royalty in an iTMS context seems misplaced. Even if Steve Jobs gave your artist friend 100% of the revenue, it still won't make a significant difference. Whether at $0.99 per song or $0.01 per song, your friend doesn't sell enough records on the iTMS for the difference to matter. IOW, I agree your friend suffers at the hands of greedy middlemen, but he or she is not a good example for the point you seem to be trying to make.
I personally know an artist that has stated they make only $0.01 per song sold on the iTMS. His last months check entailed less than $1.00 from songs sold on the iTMS. $1.00 per month for a whole year doesn't add up to much.
Sorry to be cruel, but by what moral right does an artist who sells less than 100 songs a month deserve to live off his or her musical talent alone? Even if he got 100% of the iTMS revenue, that's still just under $100 a month, on which you still cannot afford to be a professional musician in the US.
these "professional musicians" will end up even more broke than they already are.
If they can't sell enough music to feed themselves, they cannot be professional musicians.
Note that I'm not implying your friend or any amateur musician is not skillful and talented. Those are almost unrelated to the ability to sell records.
if it were true that Apple's intentions were to only make money off the ipod, they WOULD support.wmv. However, they don't because they want CONTROL over online music distribution
I agree that Apple doesn't just want to sell iPods, but the "control" conclusion you jump to isn't necessarily justified, either. Another not-so-secret Apple objective is to get you to buy a Mac, which also makes supporting WMV a silly proposition. The 99 cent songs are trojans to get you to buy an iPod, and the iPod/iTunes combination on Windows are trojans to get you to buy a Mac.
Most problems with security deal with angry employees. Hard to find them in a FLOS project.
Which is why projects never fork because of personality conflicts, right?
The truth is, anger in the "workplace" can happen whether you are paid or not. In fact, not even getting paid can significantly lower one's tolerance for poor treatment. In any case, the point is that free software is just as vulnerable (if not more, given the lack of legal penalties) to "employee" sabotage.
Maybe not, but they're a pretty good place to start if somebody wants to put in convenient ways for interested people to correct the data. The CDDB is a good example of how this can work.
So keep buying audio CDs. The market is the ultimate in "democracy", where every dollar spent is a vote in favor of a technology or product. As long as enough people buy CDs to the exclusion of their potential replacements, there will be people selling them.
Just don't be surprised if (if, not when) the market refuses to cater to a very small minority if that's what people like you turn out to become.
And if a trusted employer were to do this, all those security measures would come to nothing. It is impossible to secure a program against backdoors inserted by it's own developers whether the source code is public or not.
Well, it's not really impossible, but it is very difficult. This is why it is incorrect to compare this outsider attack (which companies generally fend off) with known insider attacks in closed source software.
The difference is, with public source, such backdoors are much more likely to be found, because more people see the code.
You are right, but this is only true of the few high profile open source projects, which are best-in-class examples in a very large pool. Smaller projects get a lot fewer eyeballs, and may be no more secure in this regard than closed source software.
OpenSSH and Sendmail both suffered trojan horse releases last year, even as upthread critics lambasted commercial software for releasing trojans.
If a web browser makes itself the default, it does not prevent another browser from accessing the www.
Sure, but it certainly undermines the other browser. In this case, Apple is disabling another software's ability to access its own product if you choose to install Apple's software, and nobody seems to have any proof that this was not a technical necessity driven by legitimate features (even if those features themselves aren't necessities).
Therefore, it is probably premature and unfair and call it sabotage.
No, I think you overestimate it. Showing a correlation is not that difficult.
I'm not going to argue this point incessantly, because what I'm really trying to understand is the threshold of proof that is required for you to act. It appears much lower than your initial post suggested. I was not suggesting that a spare planet is required, but asking if you'd accept anything short of that kind of proof.
You say "What if objective data is unknowable?" and we get to some sort of agreement about how to act in such a situation. But you've connected the question to a real situation (e.g., global warming), so the agreement on the hypothetical gets connected to an act on the real situation.
Whether the data is unknowable or not depends on how much proof it takes to get you to act. If you insist on causality beyond any doubt, then we may have to be talking about a second experimental planet. The hypothetical was placed there to illustrate that if your demands for proof are too high, we may never act.
This is a typical line of reasoning of activists, but it's a straw man argument. You assume that not enforcing Kyoto is "sitting around doing nothing".
No, that line was still a continuation of the hypothetical. In fact, way too much of my post dwelled on the hypothetical. Sorry for the confusion.
What I detected, probably falsely, from your earliest post was an extreme skeptic demanding essentially zero objective doubt before acting. You wrote:
it's paramount that it be clearly demonstrated that: [...] Global warming is shown to be caused by greenhouse gases.
I think you might agree that this sounds like a pretty high bar.
All of the vulnerabilities I listed made it into official releases before being patched. The bug this story is about didn't make it one day in the source tree, let alone into an official release.
Security is about risk management, and open source projects that allow public submissions are actually riskier than equivalent closed source projects. A company has firewalls and user lists to protect its source tree (not to mention an audit trail that can show who checked in what changes), which means that in many cases the sabotage can only come from within. If an insider trusted by Linus Torvalds were to do this, it may have been inserted as a trojan legitimately, and may not be found without a real source code audit, just like for commercial software.
In other words, to put this particular attack in perspective, compare it to somebody trying to hack into Microsoft to put a few lines of code into the Windows Longhorn source tree. Comparing it to employee sabotage is not appropriate.
I hate the whole "open in browser window" thing. I would much rather have the browser download the file and pass it off to another application with its own GUI.
You probably don't hate it as much as you say you do. Do you want your browser to display plain text externally? How about gzipped HTML files? I'm guessing you'd want these displayed by the browser.
I think what is more important is how well the interaction model for the particular document type fits with the browser's. PDFs are jarring because "Back" and "Forward" doesn't work as expected in them. However, if properly integrated you may not mind it as much.
"Sabotage" requires more than knowingly breaking a competitor's product. It requires that the action be done outside of reasonable technical considerations. That is, a legitimate technical reason is always fair defense against charges of sabotage, unless you have a confession that the intent was to sabotage a competitor. AFAIK, not even MusicMatch is alleging sabotage.
By the way, plenty of software deliberate break competitors this way. Web browsers frequently ask if you want to make it the default, which "breaks" other browsers, for example. Media player applications also do this.
A kitchen computer ideally should take up little desk space (most kitchens are already cramped, which is why kitchen audio players typically mount under a cabinet), and be protected against a harsh environment. An easily-cleaned touchscreen computer is probably the most ideal solution, not an old CRT iMac.
Your PDA alarm clock is problematic as well. It almost certainly consumes a lot more power than any $10 alarm clock. I can't even remember when I last replaced the batteries to my alarm clock.
While I agree with your general sentiment against the disposable culture, there is a point past which insistence on old technology doesn't make sense either in terms of money, time, comfort, or environmental concerns. Proponents of a counterculture need to use old things better than "just because" for the argument to be convincing.
Apple has done it before, but this doesn't appear to be simply a case of making something disappear. The nature of the program does not subvert Apple product features, etc, and doesn't appear to hurt Apple overtly.
Ownership of the code means much more than being able to pull it. It means they can enhance it and integrate it into a future product. Without support or hope of future versions, and with an Apple-branded enhanced version as competition, any copies that are floating around probably aren't worth worrying about.
You are wrong. The prevailing nuclear doctrine of the Cold War was known as "Mutually Assured Destruction", in which both powers knew that escalated use of nuclear weapons will lead to doom for all. A hypothetical unstoppable virus has the same effect, so a doomsday virus to ward off attacks is terrifying, but not insane. That's what nuclear weapons aimed at other nuclear states have been for decades.
Take a quick look at the sample shots taken with the camera. Their visual quality easily match or exceed stills from digital video cameras.
No, it's more like saying "the Segway is ready for the road". But only about 5% of the existing roads, so your mileage may vary. It is technically true, but meaningless to a large percentage of people.
Linux can compete with Windows in it's market.
Linux is competitive with Windows in under 5% of the Windows market. The fact is that most computer users (including some savvy experienced users) will not consider primarily using Linux for a variety of reasons. Again, you like to use phrases that are technically true, but semantically misleading.
"Linux is ready for desktop use. It may or may not be able to provide your desktop needs." I don't think most people will have any trouble understanding that.
It all has to do with context. If you are speaking to a convention of librarians, then the qualification is extraneous. Either Linux is ready for them or it is not. If you are speaking to an unspecifiable general audience (an article for a mainstream magazine, for instance), then the qualification is necessary but your message is diminished. Your readers will still walk away not knowing if Linux will work for them.
This appears to be the way you like to talk or write, and I'm not going to expend too many bits trying to change that. I'm just pointing out that making a bold initial statement and following up with a YMMV caveat is usually not effective communication. Think tabloid headlines.
I don't disagree with your point, but we can't always insist on the most precise language if we wish to be understood. If I tell somebody "Linux is ready for the desktop", they'll probably think it means that Linux is ready to compete directly against Windows XP and Mac OS X in their respective markets. By declaring that prematurely, you will irritate the people who believed you (heard what they think you said), tried Linux, and became disappointed. I imagine you can see how that is counterproductive, and how the same users might discount your words in the future.
Communication does not end when the words leave your mouth. They end when the words enter the listener's brains and are comprehended correctly.
Wow, the skeptics are on the offensive today.
I cited that as an example of a familiar special effect. However, there are other things you can do with multiple cameras. For example, a 360-degree photograph of an animate object, like a rabbit or a baby. You can build yourself a toy "3-D" camera (stereo vision) for $11 x 2, rather than $37 x 2.
You can also think of shots where the camera itself is sacrificed, or potentially sacrificed. For example, a custom modification can allow the camera to fit in impossibly tight spaces. It can also be embedded into a remote-control car or plane.
Use your imagination.
And why would they spend several thousand dollars to do so?
That's the whole point. With the $11 camera, you can buy 50 of them with just $550. With the $37 camera, it'll cost $1,850. The difference can make or break the effect for a small film, for instance.
If you read the articles linked, you might have found the following line:
So yes, people have been able to modify the firmware to a limited degree. It may also be possible to simply use a hardware hack on the "shoot" buttons. Among the hackers' objectives is to shoot in a lower JPEG quality to store more shots and to shoot continuously (webcam), so I think a synchronized trigger is not terribly far-fetched.The point is, somebody asked, why not use a $37 camera? I responded, if I wanted to do the Matrix effect, using the Dakota will cost me $1,300 less for 50 cameras.
Really? What if I want to set up 50 of these things and synchronize their shutters to take Matrix-style motion effects shots? Suddenly the price difference is $1,300.
All benchmarks are fair unless you deliberately picked the criteria to favor one candidate over the other, or overgeneralize the collected results beyond reason. The bigger question is whether they are representative or real performance in real application.
What compilers are evenly matched amongst different hardware?
Compilers are not evenly matched among different source code, nevermind different hardware. I don't see how you can possibly achieve this, especially with a free compiler where developer interest and expertise (which is mostly beyond your control) direct how well it will perform on each platform.
Finally, should such tests take into account the sub-systems available, such as 3D performance and the various Quake-FPS metrics?
Depends on what you're testing. If it's a CPU versus CPU comparison, perhaps not. If it's a system versus system comparison, definitely.
I would suggest taking code from various free projects. For example:
- use Gecko or KHTML to render some known complicated web pages
- use POV-Ray to render some complex scenes
- use GIMP graphics filters to modify big images
You can also start with a CS data structures book, and implement various basic and well-known algorithms and apply them to big data sets.I thought one major advantage of free software was that we could afford to release only when ready, rather than when the marketing department demanded? The article wasn't demanding "perfect". Some RPMs included in the distribution that wouldn't install!
I'm not anti-Linux. I like it so much that I want us to use on it the same (or higher) standards we judge software we pay for.
First of all, they are unlikely to know or care what OS the phone runs. Secondly, you are asking for a (possibly correct) conclusion based on faulty reasoning, which is a terribly slippery slope. There are many phone (or PDA) operating systems, and most of them are utterly unsuitable on servers, the phone system, or a desktop computer. Finally, neither cellular carriers nor the OEMs who make the phones have strong incentives to emphasize "Linux", because they each have their own brand to promote.
I like Linux, too, but I fear you are overly optimistic.
No, I'm not. The point is, complaining about the $0.01 royalty in an iTMS context seems misplaced. Even if Steve Jobs gave your artist friend 100% of the revenue, it still won't make a significant difference. Whether at $0.99 per song or $0.01 per song, your friend doesn't sell enough records on the iTMS for the difference to matter. IOW, I agree your friend suffers at the hands of greedy middlemen, but he or she is not a good example for the point you seem to be trying to make.
Sorry to be cruel, but by what moral right does an artist who sells less than 100 songs a month deserve to live off his or her musical talent alone? Even if he got 100% of the iTMS revenue, that's still just under $100 a month, on which you still cannot afford to be a professional musician in the US.
these "professional musicians" will end up even more broke than they already are.
If they can't sell enough music to feed themselves, they cannot be professional musicians.
Note that I'm not implying your friend or any amateur musician is not skillful and talented. Those are almost unrelated to the ability to sell records.
I agree that Apple doesn't just want to sell iPods, but the "control" conclusion you jump to isn't necessarily justified, either. Another not-so-secret Apple objective is to get you to buy a Mac, which also makes supporting WMV a silly proposition. The 99 cent songs are trojans to get you to buy an iPod, and the iPod/iTunes combination on Windows are trojans to get you to buy a Mac.
Here are the links you asked for: OpenSSH Sendmail
In both cases the download sites were compromised by intruders to insert trojan code.
Which is why projects never fork because of personality conflicts, right?
The truth is, anger in the "workplace" can happen whether you are paid or not. In fact, not even getting paid can significantly lower one's tolerance for poor treatment. In any case, the point is that free software is just as vulnerable (if not more, given the lack of legal penalties) to "employee" sabotage.
Maybe not, but they're a pretty good place to start if somebody wants to put in convenient ways for interested people to correct the data. The CDDB is a good example of how this can work.
So keep buying audio CDs. The market is the ultimate in "democracy", where every dollar spent is a vote in favor of a technology or product. As long as enough people buy CDs to the exclusion of their potential replacements, there will be people selling them.
Just don't be surprised if (if, not when) the market refuses to cater to a very small minority if that's what people like you turn out to become.
Well, it's not really impossible, but it is very difficult. This is why it is incorrect to compare this outsider attack (which companies generally fend off) with known insider attacks in closed source software.
The difference is, with public source, such backdoors are much more likely to be found, because more people see the code.
You are right, but this is only true of the few high profile open source projects, which are best-in-class examples in a very large pool. Smaller projects get a lot fewer eyeballs, and may be no more secure in this regard than closed source software.
OpenSSH and Sendmail both suffered trojan horse releases last year, even as upthread critics lambasted commercial software for releasing trojans.
Sure, but it certainly undermines the other browser. In this case, Apple is disabling another software's ability to access its own product if you choose to install Apple's software, and nobody seems to have any proof that this was not a technical necessity driven by legitimate features (even if those features themselves aren't necessities).
Therefore, it is probably premature and unfair and call it sabotage.
I'm not going to argue this point incessantly, because what I'm really trying to understand is the threshold of proof that is required for you to act. It appears much lower than your initial post suggested. I was not suggesting that a spare planet is required, but asking if you'd accept anything short of that kind of proof.
You say "What if objective data is unknowable?" and we get to some sort of agreement about how to act in such a situation. But you've connected the question to a real situation (e.g., global warming), so the agreement on the hypothetical gets connected to an act on the real situation.
Whether the data is unknowable or not depends on how much proof it takes to get you to act. If you insist on causality beyond any doubt, then we may have to be talking about a second experimental planet. The hypothetical was placed there to illustrate that if your demands for proof are too high, we may never act.
This is a typical line of reasoning of activists, but it's a straw man argument. You assume that not enforcing Kyoto is "sitting around doing nothing".
No, that line was still a continuation of the hypothetical. In fact, way too much of my post dwelled on the hypothetical. Sorry for the confusion.
What I detected, probably falsely, from your earliest post was an extreme skeptic demanding essentially zero objective doubt before acting. You wrote:
it's paramount that it be clearly demonstrated that: [...] Global warming is shown to be caused by greenhouse gases.
I think you might agree that this sounds like a pretty high bar.
Security is about risk management, and open source projects that allow public submissions are actually riskier than equivalent closed source projects. A company has firewalls and user lists to protect its source tree (not to mention an audit trail that can show who checked in what changes), which means that in many cases the sabotage can only come from within. If an insider trusted by Linus Torvalds were to do this, it may have been inserted as a trojan legitimately, and may not be found without a real source code audit, just like for commercial software.
In other words, to put this particular attack in perspective, compare it to somebody trying to hack into Microsoft to put a few lines of code into the Windows Longhorn source tree. Comparing it to employee sabotage is not appropriate.
You probably don't hate it as much as you say you do. Do you want your browser to display plain text externally? How about gzipped HTML files? I'm guessing you'd want these displayed by the browser.
I think what is more important is how well the interaction model for the particular document type fits with the browser's. PDFs are jarring because "Back" and "Forward" doesn't work as expected in them. However, if properly integrated you may not mind it as much.
"Sabotage" requires more than knowingly breaking a competitor's product. It requires that the action be done outside of reasonable technical considerations. That is, a legitimate technical reason is always fair defense against charges of sabotage, unless you have a confession that the intent was to sabotage a competitor. AFAIK, not even MusicMatch is alleging sabotage.
By the way, plenty of software deliberate break competitors this way. Web browsers frequently ask if you want to make it the default, which "breaks" other browsers, for example. Media player applications also do this.