You probably don't have any reason to care about it. N00bs care about it because Linux installation procedures are sufficiently confusing to them that it's worth $20/year to them to avoid having to learn any of it.
People must click on the "Cl1ck H33RE F0R S|0ft V1A_GR_A!!!!!" bullshit or the spamming fuckers would stop sending me this shit 10 times an hour.
Alternate theory: the spammers just think they're gonna make money ; the real money is made by the folks selling mass-mailers and address lists to to the spammers.
The other reason consolidation at the server level isn't necessary is that it's easy to consolidate at the client level, either by running multiple IM programs at once, or by running one multiple-IM program (Gaim, Miranda, Trillian, etc.). Meeting your friend on their turf is often easier than either convincing them to meet on yours, and most certainly easier than establishing a cross-IM gateway (unless the server has already done it, which IIRC has been done for ICQ and AIM).
Any friend who asked me that, if I wasn't filtering them already, I would start thinking about it. More likely I'm filtering the whole world, because I'm in the middle of something requiring unbroken concentration. (Even looking at the caller-ID info takes a conscious effort; custom ring tones could help here.) Or I left the cell phone by the car keys. Or the battery ran out. Or (in the case of our home phone) 99% of the calls are for my wife, and the answering machine is much more reliable at taking and delivering messages than I am.
Work calls are a different matter. Fortunately, my clients grok the tragedy of the commons, and don't bug me about immediate responsiveness unless it really is an emergency. (On the flip side, I can often give them immediate responsiveness anyway by remote-controlling their system.)
A difficult tool is reasonably justified if the overall difficulty of the project is reduced, e.g.
Employees already familiar with it; it's easier for them
End users already have mental block against the easier tool; it's harder for them
Support for the easier tool appears eminently unreliable; it would become harder if this support went away
Difficulty of the tool is outweighed by reducing the number of other packages/developers that one must interface with, and/or reducing the difficulty of said interfaces
What other situations would justify choosing a tool that, in isolation, is not the easiest choice to use?
Which is completely backwards. If your OSS support goes away, you can hire someone else, and they will have access to 100% of the information they need. This is not the end of the story, of course - many proprietary companies are reasonably reliable, and the original author of a program (OSS or proprietary) has a huge head start on anyone else for understanding that program - but it's still an issue worth considering.
Seconded. Symantec AV Corporate 2002, in my case. The one process I recognize (rtvscan.exe) consumes about 19M of memory (I have 768M to start with, so it may be expanding in proportion to what's available) and 0% of CPU.
Anyone with a case of NAV or SAV running like a dog is encouraged to reply with the version, in case it really is just certain ones that have major problems.
Let's say your code is on v4.00 when this occurs, then people misusing stuff via GPL v57 can only misuse v4.00 and prior; they cannot touch v4.01 or any other versions, thus they will keep having to reinvent wheels until/unless they operate under one of the non-evil versions of the GPL.
People generally trust that the FSF will go there only over RMS's dead body. And even if the FSF does someday go there, you can cap the damage by releasing a new version that's only licensed via "GPL v2 through v6.65" (assuming that v6.66 is the first evil version of the GPL), and sticking with that for all future releases.
This is mostly consistent with my experience. I'm part of a small group of contractors. Meetings with clients don't drag, for the reason stated above - unless they're unclear about what they really want, in which case our first job is to get them clear. Meetings within the group usually just consist of e-mailing specs and status updates, with phone calls or face-to-face meetings to work out the occasional thorny bits; they don't drag either, because they either cut into our billable hours, or they are billable hours and thus need to be justifiable to the client.
Mmm, so you have, though it took a good bit of digging through those posts to suss out the intended meaning. (Wikipedia stated it flat-out, as usual, as did answers.com)
I still think that the alternate definition of "workstation" as simply a synonym of "desktop" (#2 in the Computer Desktop Encyclopedia, copyrighted by Sun of all people) is sufficiently ubiquitous that, while the author may be expected to know the difference (depending on how often they write about JPL-type companies), the same expectation cannot be reasonably applied to the general readership.
However, since a significant fraction of the readership does not work at JPL or similar, would you please just explain the darn difference already? (I think someone else did in another sub-branch, but I'd appreciate hearing it from you because your comment launched this portion of the discussion.)
I mentioned RMS; he basically followed the bounty model, years before it became an OSS buzzword. He'd find a client who needed a program badly enough that the value of them getting it for a price outweighed the drawback of their competitors subsequently getting it for free. In particular, consider code that wouldn't get written at all without the bounty.
A lot of the code I write for my day job is custom tailoring for individual clients, so it doesn't really matter whether it's proprietary or OSS (because no one else would want that exact thing anyway). My last employer was big on generalizing and re-selling such things, but that gets messy in a hurry unless you have major economy of scale (on the order of, say, TurboTax's customer base).
Small shareware applications are not too far removed from open-source donationware.
I don't think that software should all be free or open source. I prefer the idea of people who develop software being compensated for it.
These are not always mutually exclusive. You can charge, not for the code itself, but for the service of developing it (RMS routinely did this, still does for all I know) and supporting it. Even if code is open, the original author has a leg up on working with it, due to familiarity.
the RSS built into firefox and ie7 and even many standalone readers are just useless, they just show you whats currently on the site.
But if that's all you want, then they work great. I use Firefox's built-in RSS for Slashdot - if I miss doing it one day, big deal, I'll just catch the dupes later:)
I'm sure it was because the cell phone workaround wasn't generally known; I didn't know about it until I saw the responses to my comment. Mod me down if you feel that strongly about it. (Aww, but I might lose my first ever karma bonus. Oh well.)
The previous poster gave a link to get your own Gmail account without an invite and I just registered.
This is, at best, ambiguous. My parent linked to Google account sign-up; I linked to a FAQ entry saying that it wasn't that simple; one of my children linked to the cell phone workaround. (Okay, I'm being pedantic.)
Why don't you just throw it on a web server and e-mail them the URL?
Or, depending on your situation, set them up to run Terminal Server or something. Then you can upload it directly to their system, and even install it for them. Plus, in many cases, you can use it to do tech support. Much better (for us and for the clients) to spend less time on site visits or tedious walk-the-user-through-some-steps phone calls for otherwise trivial tasks, and more time on development or site visits with meaningful content.
Slashdot Mirror
...aww damn, botched the link. Here's the correct one.
I liked this comment better the first time I read it.
You probably don't have any reason to care about it. N00bs care about it because Linux installation procedures are sufficiently confusing to them that it's worth $20/year to them to avoid having to learn any of it.
Groupware Bad
The other reason consolidation at the server level isn't necessary is that it's easy to consolidate at the client level, either by running multiple IM programs at once, or by running one multiple-IM program (Gaim, Miranda, Trillian, etc.). Meeting your friend on their turf is often easier than either convincing them to meet on yours, and most certainly easier than establishing a cross-IM gateway (unless the server has already done it, which IIRC has been done for ICQ and AIM).
Any friend who asked me that, if I wasn't filtering them already, I would start thinking about it. More likely I'm filtering the whole world, because I'm in the middle of something requiring unbroken concentration. (Even looking at the caller-ID info takes a conscious effort; custom ring tones could help here.) Or I left the cell phone by the car keys. Or the battery ran out. Or (in the case of our home phone) 99% of the calls are for my wife, and the answering machine is much more reliable at taking and delivering messages than I am.
Work calls are a different matter. Fortunately, my clients grok the tragedy of the commons, and don't bug me about immediate responsiveness unless it really is an emergency. (On the flip side, I can often give them immediate responsiveness anyway by remote-controlling their system.)
I see the designers of Flock are up to their old tricks again...
One day in the future...
A difficult tool is reasonably justified if the overall difficulty of the project is reduced, e.g.
What other situations would justify choosing a tool that, in isolation, is not the easiest choice to use?
Which is completely backwards. If your OSS support goes away, you can hire someone else, and they will have access to 100% of the information they need. This is not the end of the story, of course - many proprietary companies are reasonably reliable, and the original author of a program (OSS or proprietary) has a huge head start on anyone else for understanding that program - but it's still an issue worth considering.
Seconded. Symantec AV Corporate 2002, in my case. The one process I recognize (rtvscan.exe) consumes about 19M of memory (I have 768M to start with, so it may be expanding in proportion to what's available) and 0% of CPU.
Anyone with a case of NAV or SAV running like a dog is encouraged to reply with the version, in case it really is just certain ones that have major problems.
Let's say your code is on v4.00 when this occurs, then people misusing stuff via GPL v57 can only misuse v4.00 and prior; they cannot touch v4.01 or any other versions, thus they will keep having to reinvent wheels until/unless they operate under one of the non-evil versions of the GPL.
People generally trust that the FSF will go there only over RMS's dead body. And even if the FSF does someday go there, you can cap the damage by releasing a new version that's only licensed via "GPL v2 through v6.65" (assuming that v6.66 is the first evil version of the GPL), and sticking with that for all future releases.
Seconded. Well, thirded, given the sister comment along the same lines. Whatever it's supposed to mean, Acronym Finder doesn't know about it.
This is mostly consistent with my experience. I'm part of a small group of contractors. Meetings with clients don't drag, for the reason stated above - unless they're unclear about what they really want, in which case our first job is to get them clear. Meetings within the group usually just consist of e-mailing specs and status updates, with phone calls or face-to-face meetings to work out the occasional thorny bits; they don't drag either, because they either cut into our billable hours, or they are billable hours and thus need to be justifiable to the client.
*reads*
Mmm, so you have, though it took a good bit of digging through those posts to suss out the intended meaning. (Wikipedia stated it flat-out, as usual, as did answers.com)
I still think that the alternate definition of "workstation" as simply a synonym of "desktop" (#2 in the Computer Desktop Encyclopedia, copyrighted by Sun of all people) is sufficiently ubiquitous that, while the author may be expected to know the difference (depending on how often they write about JPL-type companies), the same expectation cannot be reasonably applied to the general readership.
However, since a significant fraction of the readership does not work at JPL or similar, would you please just explain the darn difference already? (I think someone else did in another sub-branch, but I'd appreciate hearing it from you because your comment launched this portion of the discussion.)
I mentioned RMS; he basically followed the bounty model, years before it became an OSS buzzword. He'd find a client who needed a program badly enough that the value of them getting it for a price outweighed the drawback of their competitors subsequently getting it for free. In particular, consider code that wouldn't get written at all without the bounty.
A lot of the code I write for my day job is custom tailoring for individual clients, so it doesn't really matter whether it's proprietary or OSS (because no one else would want that exact thing anyway). My last employer was big on generalizing and re-selling such things, but that gets messy in a hurry unless you have major economy of scale (on the order of, say, TurboTax's customer base).
Small shareware applications are not too far removed from open-source donationware.
Whereas the end user's WinZip will Just Work on it. If it must go by e-mail, then yeah, this seems like a good workaround.
Why don't you just throw it on a web server and e-mail them the URL?
Or, depending on your situation, set them up to run Terminal Server or something. Then you can upload it directly to their system, and even install it for them. Plus, in many cases, you can use it to do tech support. Much better (for us and for the clients) to spend less time on site visits or tedious walk-the-user-through-some-steps phone calls for otherwise trivial tasks, and more time on development or site visits with meaningful content.