And even if that were the case, why do you suppose that would be? Because so many in the media refuse to run advocacy ads disputing the connection between drugs and terrorism?
Just because your OK with goosestepping into a future of shit doesn't mean the rest of us have to be.
Re:Hey, if we're talking about CBS...
on
Superbowling
·
· Score: 1
Re:Hey, if we're talking about CBS...
on
Superbowling
·
· Score: 1
CBS has a long standing policy of rejecting ads "for the advocacy of viewpoints on controversial issues of public importance."
Bullshit. They're running another one of these goddamned "drug-use equals terrorism" ads from the White House Office of National Drug Control Policy again this year.
They always run this kind of crap. But only when it suits their political point-of-view.
Re:Hey, if we're talking about CBS...
on
Superbowling
·
· Score: 4, Interesting
That had nothing to do with the ad, it has to do with the fact that TV networks don't air "issue ads," or political ads not endorsing a certain political candidate.
Not true, they air such ads all the time when they come from the Democrats and/or the Republicans.
Basically, they're too controversial and the networks don't want to show anything that might make people want to change the channel.
And ads for three different drugs that induce erections aren't?
Yup, sucks...
Yes, it does. Hence my pointing it out.
but that's the way things work.
Or to put it another way, we live in a totalitarian state.
And this has nothing to do with the first amendment, CBS is a corporation, the first amendment only applies to the government.
A very simplistic reading of the situation. Those our are airwaves. The very fact that the networks can be given exclusive access to those airwaves on the one hand and then be allowed to suppress speech is de facto government censorship.
Hey, if we're talking about CBS...
on
Superbowling
·
· Score: 0, Redundant
If you had done me the same favor at the outset, we could have saved ourselves both a bit of time.
but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.
I never said this either, except in the most general sense.
how do you propose to replace programatic use of AppleScript in the ways I've described?
I'm not interested in your uses. Again, if you could actually bother yourself to read what I am writing here, you're a programmer, and I'm not interested in a programmer's experience with AppleScript. Programmers have any number of ways of solving problems without having to resort to AppleScript. I am however interested in end users who want to be productive but who aren't necessarily code literate. Everything I am saying is in this context, but you just don't seem to understand the distinction--a distinction I might add that is supposed to separate the Mac from the other computers--and I'm not going to waste any more time beating you over the head with it.
Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook...
Which makes my point exactly. I don't know for sure which versions of OS X Python comes preinstalled on either. You may want to call this first-class support, but I don't, and certainly no one who has to support a large user base does either.
You want it all, but aren't willing to do a lick of work to get it.:)
What is your problem? Python is not a peer to Java or Objective-C, regardless of whatever lame observations you make to the contrary. If you want to do tech support for a user base of thousands of people who don't read documentation and then start complaining because the app doesn't work right, then by all means, knock yourself out.
Given all the discounts college students get simply for being college students, these complaints strike me as being little more than whining.
Why do I have to pay full-price for educational materials simply because I don't attend a university? Why is my learning any less important or relevant than yours?
The reason I only rarely record my AppleScript is that I often can't record what I want to do.
You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?
For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk...
That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.
I have never had a problem with doing things this way...
Again, you're a programmer. AppleScript's promise was to expose new ways of automating tasks to non-programmers. I think a lot of your issues derive from this basic misunderstanding.
Using my example, how do you think AppleScript or the app should support those kinds of things?
Again, your example is atypical and not particularly relevant here.
I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default.
Python only comes with the Developer Tools CD, IIRC.
What's so hard about having your users install a framework first, and then double-clicking your app?
I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.
However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.
Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.
I would also suggest that AppleScript should be usable by non-programmer types. Maybe *you* don't need to use it, but others could get a lot of mileage from it.
Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action.
It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.
A Python-Objective C bridge has been around since OpenStep days.
Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.
If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH.:)
You're right. The glass is half-full. And the earlier point regarding OSA is a good one, although I've always seen this as a trump card Apple could play in showcasing the Mac's excellent i18n support. I mean, how many other OS's out there will let you code in, say, Arabic, for instance?
The problem is that to be truly useful, you want *every* application to support whatever scripting language you end up using, since so much of the power comes from being able devise useful solutions by connecting different applications together.
And there is a good deal of support for AppleScript already. So much pain, misery and wailing went into providing even the limited functionality we see today... I don't think developers are going to embrace throwing all that work away.
You've fallen for the most blatant lie that gets brought up in these debates. You have no rights to the music, unless you have purchased it.
I never said I did, and it is *you* who are falling for the industry lie here.
I do however have the right to record music, to copy data, and to view a movie I've purchased on the platform/device of my choice -- just to name a few common computer-related tasks -- and the actions of the RIAA/MPAA works to, if not deprive me of these rights, then to at least tax or otherwise burden me to such a degree that the right otherwise starts resembling a privilege.
That is the plain and simple truth of the matter. They cannot make their business model succeed without infringing on our rights, and as long as that remains the case, people will continue to download/rip/burn/etc.
AppleScript would rock if people started writing really good AppleScript-aware applications. But they don't. Most everything out there is crap, for one simple reason: almost no one supports recordability.
An AppleScript-recordable application lets you record your interaction with an application and play it back later. But it's more than just keystrokes and mouse-clicks. The events that make up your interaction are recorded at the semantic level, which makes them a whole lot more useful.
It also would address what everybody keeps saying is the chief shortcoming of AppleScript: it's terrible syntax. I agree it's pretty unwieldy in places, but the thing of it is, you shouldn't be writing scripts, you should be recording them! And once you've recorded a script, it's a pretty easy task to go in there and make simple changes if you need to.
The problem is compounded by people releasing software that claims to be recordable but really isn't. BBEdit is an example... they claim to be recordable, but they're not. All they let you do is screw around with window positions and basic UI crap like that. But do they let you actually record your interactions with the text within the document? No. And so people go buy BBEdit, see that the box says it's recordable, try it out and come away thinking that AppleScript sucks. It doesn't. It's BBEdit that sucks.
What's especially frustrating is that the purchase of Next should have helped remedy this situation. One of the reasons so few really good recordable applications are out there is because it's really hard to write a really good recordable application. You have to factor your code with AppleScript foremost in mind, so what was once a single function becomes four or five. And the API is a little convoluted. And you have to create and maintain an object hierarchy that may or may not correspond to the hierarchy of classes used in your code.
Cocoa/Objective-C could've gone a long way towards solving these problems. I detest Objective-C on other grounds, but I do appreciate that it would be a great boon in the creation of AppleScript-recordable applications. Alas, the guys from NeXT who seem to be running the show over there these days have taken a "not invented here" attitude to the language.
That's really too bad. Because you may all think the syntax is absurdly verbose and superficially English-like today, but just wait until we start talking to our computers as a matter of course. AppleScript would rule your desktop.
If I were running Apple, I'd make Python a first-class language, give it access to everything Cocoa and Carbon have access to, and put together a truly awesome AppleScript module that would let developers create AppleScript-recordable applications just as easily as you would, well, write a program in Python.
It is the consumers who brought this on themselves by not respecting other people's rights.
You have it backwards. We, the people, are the ones with rights. Not the MPAA. Not the RIAA.
Their inability to create a viable business model that does not violate my rights is not my concern, and their continuing efforts to deny me my rights in pursuit of the existing model will continue to be met with hostility.
We do not need the MPAA. We do not need the RIAA. Artists will have to find new ways to make money (performing, cutting out the middle-man, etc.) If the only business models available to them that do not violate my rights do not generate the income they desire, then they can consider another occupation.
If the MPAA were to combat shoplifting in the same way they combat file-trading, they would demand that consumers (ahem, customers) be made to wear lead helmets that would prevent them from being able to watch or listen to a movie unless they first invoked a key obtained when purchasing one of their products. Only then would you be able to remove this helmet, and then only for as long as they were watching that movie.
They could, if they wanted to. They're in a position to use the Eolas patent to say, "Hey, these software patents are stupid! Let's change the system!"
But will they? Of course not. The stupid patents are stupid to Microsoft only when they prevent Microsoft from writing code. It's true that they haven't been litigating violations of their own patents to date (at least I think that's true) but it does appear that that's all about to change as they resort to bare knuckles tactics with the OSS community; the ridiculous Office XML patent being a good case in point.
Given their history of underhanded dealings this wouldn't surprise me one bit. This attack only helps SCO. They get sympathy. What do the worm writers get?
Given the rumors of Episodes VII, VIII & IX, I think there's a good chance that Lucas has been slapped out of whatever doldrums that produced I & II and that he understands that III has to be put out of the park.
In other words, if Episode III is the Star Wars equivalent of Star Trek: Nemesis, then he loses the franchise.
My brother coded this SPF implementation in a day, but then he was using Python.
Everybody should start using SPF. No, it's not the perfect solution. Think Saving Private Ryan. SPF is like the guys in the front of the boat who get gunned down when the doors open. But without them, the other guys (other to-be-developed protocols-or-whatever) wouldn't stand a chance..
It' s also a rather pointless excersise. A normal Knoppix HD install is faster, can be updated through the apt-get update/upgrade routine and it also cannot be damaged when using non-root accounts (as you should).
Well, there are other considerations here. I wanted this to be set up in such a way as to demand as little of my time as possible, which the Knoppix image approach achieves. I was also concerned about liability... had I done a normal install, then I would be root, and then I would conceivably be liable for any exploits performed on that machine. Remember that this isn't my day job by any stretch of the imagination; this is me doing a favor.
And I'm not sure I buy the notion that a default install is secure simply because you're making your users use non-root accounts. I've heard of too many exploits that take advantage of local access to the box.
You failed your users because you didn't offer them a solution which fitted with *their* expectations.
Again, they really aren't *my* users. This was supposed to be about me spending less than an hour slapping the thing together and maybe visiting once a month to see if it was still running when I go to pay my rent. I was getting nothing in return from this arrangement, so considering that their alternative was wrestling with a barely-limping Win98 install, I think I did well by them.
Now, had I gotten into the second-stage of the project, that is, getting into all the i18n crap, then yeah, I'd have gone for the full install and would've worked out some indemnity arrangement with the manager's office.
Just one more note... once the system was booted and Konqueror was running in full screen mode the system was actually quite responsive. Most of the users were interested only in doing webmail and assorted browsing, and what was truly remarkable was how they didn't notice or care that it wasn't an IE box, despite (I'm assuming) that being their only previous experience. I think the people who were upset with the performance was management, because they had to turn on the machine in the morning and I guess waiting three minutes for everything to load was just too much. So, I think it really depends on the situation you're in... with just the slightest change in environment--like if they left the machine on all night for instance--it would have probably been a successful setup.
I'd like to evangelize for Linux though, so I don't want to do Linux installs that only serve to make people think Linux is slow.
I'd like people to walk away thinking, "Hey, that Linux is pretty cool!", and then when they walk into a Walmart a year later, and they see the Linux PC selling for less than the Windows PC...
Slashdot Mirror
Harpoon... check
Name I can't pronounce... check
10 years before getting some... check
I just have the class not to make a big deal out of it.
There's no credible organization stepping forward to say that there is no link between illegal drugs and terrorism...
So what? I see no such requirement in the policy CBS puts forward in defense of this onerous decision.
You're grasping at straws.
And who says that the ACLU and the Drug Policy Alliance aren't credible?
And even if that were the case, why do you suppose that would be? Because so many in the media refuse to run advocacy ads disputing the connection between drugs and terrorism?
Just because your OK with goosestepping into a future of shit doesn't mean the rest of us have to be.
Be more specific...
You mean like this earlier reply to you?
CBS has a long standing policy of rejecting ads "for the advocacy of viewpoints on controversial issues of public importance."
Bullshit. They're running another one of these goddamned "drug-use equals terrorism" ads from the White House Office of National Drug Control Policy again this year.
They always run this kind of crap. But only when it suits their political point-of-view.
That had nothing to do with the ad, it has to do with the fact that TV networks don't air "issue ads," or political ads not endorsing a certain political candidate.
Not true, they air such ads all the time when they come from the Democrats and/or the Republicans.
Basically, they're too controversial and the networks don't want to show anything that might make people want to change the channel.
And ads for three different drugs that induce erections aren't?
Yup, sucks...
Yes, it does. Hence my pointing it out.
but that's the way things work.
Or to put it another way, we live in a totalitarian state.
And this has nothing to do with the first amendment, CBS is a corporation, the first amendment only applies to the government.
A very simplistic reading of the situation. Those our are airwaves. The very fact that the networks can be given exclusive access to those airwaves on the one hand and then be allowed to suppress speech is de facto government censorship.
...then let's not forget their decision to not carry MoveOn.org's advocacy ad.
Did you record that script? No.
But thanks for playing anyways.
Read the post, man.
:)
If you had done me the same favor at the outset, we could have saved ourselves both a bit of time.
but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.
I never said this either, except in the most general sense.
how do you propose to replace programatic use of AppleScript in the ways I've described?
I'm not interested in your uses. Again, if you could actually bother yourself to read what I am writing here, you're a programmer, and I'm not interested in a programmer's experience with AppleScript. Programmers have any number of ways of solving problems without having to resort to AppleScript. I am however interested in end users who want to be productive but who aren't necessarily code literate. Everything I am saying is in this context, but you just don't seem to understand the distinction--a distinction I might add that is supposed to separate the Mac from the other computers--and I'm not going to waste any more time beating you over the head with it.
Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook...
Which makes my point exactly. I don't know for sure which versions of OS X Python comes preinstalled on either. You may want to call this first-class support, but I don't, and certainly no one who has to support a large user base does either.
You want it all, but aren't willing to do a lick of work to get it.
What is your problem? Python is not a peer to Java or Objective-C, regardless of whatever lame observations you make to the contrary. If you want to do tech support for a user base of thousands of people who don't read documentation and then start complaining because the app doesn't work right, then by all means, knock yourself out.
I have better things to do.
This conversation is over.
Given all the discounts college students get simply for being college students, these complaints strike me as being little more than whining.
Why do I have to pay full-price for educational materials simply because I don't attend a university? Why is my learning any less important or relevant than yours?
The reason I only rarely record my AppleScript is that I often can't record what I want to do.
You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?
For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk...
That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.
I have never had a problem with doing things this way...
Again, you're a programmer. AppleScript's promise was to expose new ways of automating tasks to non-programmers. I think a lot of your issues derive from this basic misunderstanding.
Using my example, how do you think AppleScript or the app should support those kinds of things?
Again, your example is atypical and not particularly relevant here.
I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default.
Python only comes with the Developer Tools CD, IIRC.
What's so hard about having your users install a framework first, and then double-clicking your app?
I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.
However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.
:)
Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.
I would also suggest that AppleScript should be usable by non-programmer types. Maybe *you* don't need to use it, but others could get a lot of mileage from it.
Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action.
It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.
A Python-Objective C bridge has been around since OpenStep days.
Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.
If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH.
You're right. The glass is half-full. And the earlier point regarding OSA is a good one, although I've always seen this as a trump card Apple could play in showcasing the Mac's excellent i18n support. I mean, how many other OS's out there will let you code in, say, Arabic, for instance?
I agree, to a point.
The problem is that to be truly useful, you want *every* application to support whatever scripting language you end up using, since so much of the power comes from being able devise useful solutions by connecting different applications together.
And there is a good deal of support for AppleScript already. So much pain, misery and wailing went into providing even the limited functionality we see today... I don't think developers are going to embrace throwing all that work away.
I'm talking about actually treating the text of a document as an AppleScript object. You should be able to do things like and so forth.
In other words, BBEdit doesn't support the Text Suite, one of the standard (and first) suites of AppleScript commands published back in the 80's.
To not support even this basic level of functionality and then call yourself recordable is really misleading.
You've fallen for the most blatant lie that gets brought up in these debates. You have no rights to the music, unless you have purchased it.
I never said I did, and it is *you* who are falling for the industry lie here.
I do however have the right to record music, to copy data, and to view a movie I've purchased on the platform/device of my choice -- just to name a few common computer-related tasks -- and the actions of the RIAA/MPAA works to, if not deprive me of these rights, then to at least tax or otherwise burden me to such a degree that the right otherwise starts resembling a privilege.
That is the plain and simple truth of the matter. They cannot make their business model succeed without infringing on our rights, and as long as that remains the case, people will continue to download/rip/burn/etc.
AppleScript would rock if people started writing really good AppleScript-aware applications. But they don't. Most everything out there is crap, for one simple reason: almost no one supports recordability.
An AppleScript-recordable application lets you record your interaction with an application and play it back later. But it's more than just keystrokes and mouse-clicks. The events that make up your interaction are recorded at the semantic level, which makes them a whole lot more useful.
It also would address what everybody keeps saying is the chief shortcoming of AppleScript: it's terrible syntax. I agree it's pretty unwieldy in places, but the thing of it is, you shouldn't be writing scripts, you should be recording them! And once you've recorded a script, it's a pretty easy task to go in there and make simple changes if you need to.
The problem is compounded by people releasing software that claims to be recordable but really isn't. BBEdit is an example... they claim to be recordable, but they're not. All they let you do is screw around with window positions and basic UI crap like that. But do they let you actually record your interactions with the text within the document? No. And so people go buy BBEdit, see that the box says it's recordable, try it out and come away thinking that AppleScript sucks. It doesn't. It's BBEdit that sucks.
What's especially frustrating is that the purchase of Next should have helped remedy this situation. One of the reasons so few really good recordable applications are out there is because it's really hard to write a really good recordable application. You have to factor your code with AppleScript foremost in mind, so what was once a single function becomes four or five. And the API is a little convoluted. And you have to create and maintain an object hierarchy that may or may not correspond to the hierarchy of classes used in your code.
Cocoa/Objective-C could've gone a long way towards solving these problems. I detest Objective-C on other grounds, but I do appreciate that it would be a great boon in the creation of AppleScript-recordable applications. Alas, the guys from NeXT who seem to be running the show over there these days have taken a "not invented here" attitude to the language.
That's really too bad. Because you may all think the syntax is absurdly verbose and superficially English-like today, but just wait until we start talking to our computers as a matter of course. AppleScript would rule your desktop.
If I were running Apple, I'd make Python a first-class language, give it access to everything Cocoa and Carbon have access to, and put together a truly awesome AppleScript module that would let developers create AppleScript-recordable applications just as easily as you would, well, write a program in Python.
Sigh. If only.
It is the consumers who brought this on themselves by not respecting other people's rights.
You have it backwards. We, the people, are the ones with rights. Not the MPAA. Not the RIAA.
Their inability to create a viable business model that does not violate my rights is not my concern, and their continuing efforts to deny me my rights in pursuit of the existing model will continue to be met with hostility.
We do not need the MPAA. We do not need the RIAA. Artists will have to find new ways to make money (performing, cutting out the middle-man, etc.) If the only business models available to them that do not violate my rights do not generate the income they desire, then they can consider another occupation.
Thank you for playing.
If the MPAA were to combat shoplifting in the same way they combat file-trading, they would demand that consumers (ahem, customers) be made to wear lead helmets that would prevent them from being able to watch or listen to a movie unless they first invoked a key obtained when purchasing one of their products. Only then would you be able to remove this helmet, and then only for as long as they were watching that movie.
They could, if they wanted to. They're in a position to use the Eolas patent to say, "Hey, these software patents are stupid! Let's change the system!"
But will they? Of course not. The stupid patents are stupid to Microsoft only when they prevent Microsoft from writing code. It's true that they haven't been litigating violations of their own patents to date (at least I think that's true) but it does appear that that's all about to change as they resort to bare knuckles tactics with the OSS community; the ridiculous Office XML patent being a good case in point.
I wish I was wrong. But I'm not.
I mean, c'mon, that's half the difficulty in building these things.
nt
Given their history of underhanded dealings this wouldn't surprise me one bit. This attack only helps SCO. They get sympathy. What do the worm writers get?
Nothing.
Given the rumors of Episodes VII, VIII & IX, I think there's a good chance that Lucas has been slapped out of whatever doldrums that produced I & II and that he understands that III has to be put out of the park.
In other words, if Episode III is the Star Wars equivalent of Star Trek: Nemesis, then he loses the franchise.
My brother coded this SPF implementation in a day, but then he was using Python.
Everybody should start using SPF. No, it's not the perfect solution. Think Saving Private Ryan. SPF is like the guys in the front of the boat who get gunned down when the doors open. But without them, the other guys (other to-be-developed protocols-or-whatever) wouldn't stand a chance..
It' s also a rather pointless excersise. A normal Knoppix HD install is faster, can be updated through the apt-get update/upgrade routine and it also cannot be damaged when using non-root accounts (as you should).
Well, there are other considerations here. I wanted this to be set up in such a way as to demand as little of my time as possible, which the Knoppix image approach achieves. I was also concerned about liability... had I done a normal install, then I would be root, and then I would conceivably be liable for any exploits performed on that machine. Remember that this isn't my day job by any stretch of the imagination; this is me doing a favor.
And I'm not sure I buy the notion that a default install is secure simply because you're making your users use non-root accounts. I've heard of too many exploits that take advantage of local access to the box.
You failed your users because you didn't offer them a solution which fitted with *their* expectations.
Again, they really aren't *my* users. This was supposed to be about me spending less than an hour slapping the thing together and maybe visiting once a month to see if it was still running when I go to pay my rent. I was getting nothing in return from this arrangement, so considering that their alternative was wrestling with a barely-limping Win98 install, I think I did well by them.
Now, had I gotten into the second-stage of the project, that is, getting into all the i18n crap, then yeah, I'd have gone for the full install and would've worked out some indemnity arrangement with the manager's office.
Just one more note... once the system was booted and Konqueror was running in full screen mode the system was actually quite responsive. Most of the users were interested only in doing webmail and assorted browsing, and what was truly remarkable was how they didn't notice or care that it wasn't an IE box, despite (I'm assuming) that being their only previous experience. I think the people who were upset with the performance was management, because they had to turn on the machine in the morning and I guess waiting three minutes for everything to load was just too much. So, I think it really depends on the situation you're in... with just the slightest change in environment--like if they left the machine on all night for instance--it would have probably been a successful setup.
I'd like to evangelize for Linux though, so I don't want to do Linux installs that only serve to make people think Linux is slow.
I'd like people to walk away thinking, "Hey, that Linux is pretty cool!", and then when they walk into a Walmart a year later, and they see the Linux PC selling for less than the Windows PC...