Skype for Asterisk is far from a third party hack. It was designed around the Skype Engine API, at a time when Skype was not providing access to that API to the general public (I think they still aren't providing that level of access). In fact, Skype approached Mark Spencer (original programmer of Asterisk), not the other way around. So while the integration was largely written by Digium programmers, the Skype connector has always been a direct project of Skype's.
As far as Google's communication protocols are concerned, they use all freely and openly licensed protocols, and support for them has long been integrated in Asterisk. (Yes, you can use Google Voice with Asterisk.)
Now lets say you have a huge catalog of songs you'd like to defend. You're a big mega corporation so what you do is you hire developers to analyze songs for fingerprints and -- funny how pedantic algorithms get to be -- submit anything over the 'safe harbor' limit to Control Gate C (that being the legal arm which churns out thousands of take down notices).
If I am the CEO of a mega corporation, then I know the value of good will to generate goodwill and I will put some kind of human at Control Gate C who will put a stopper on the mindless sharks in my legal department who would sully my business' positive reputation by suing dancing toddlers.
As would I, which is probably why neither of us are (or ever will be) CEO of a mega corp.
Actually, there's a very well-known CEO who considers exactly that, and he has been, at one time or another, considered the richest man in the world: Warren Buffett. He famously once said, "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."
Most of these responses are geared towards evaluating people once they're in the door, and that's fine, but if you want to find quality people, the best way to do it is to flip around the question and think about it from the prospective employee's point of view: how do they find you?
Word of mouth is certainly the best way, but I've also found the following ways that work:
Hang around computer groups in your area, talk to people, learn who's good. Many businesspeople will try this once, in that they attend one meeting, they talk to the members of the group, and they leave, and they don't find it very worthwhile. The problem with this approach is that the members are unlikely to open up to you the first time they're meeting you. You need to hang around for several meetings before they will begin to trust your presence and will open up to you, and you can then discover which ones are bullshit artists and which ones truly have talent to share.
Teach programming classes. This is what I do. I teach a weekly class from time to time, on C or Perl. I give the class for free, the class lasts 8-10 weeks, and the ones who turn in their homework assignments, and ask for feedback are the type of people that you want -- they are the type to become superstar programmers, and with a little guidance, they will. This also means that you can hire them on a fair market salary and not have to pay the big bucks. After all, you are looking for motivated individuals who are willing to learn new things. What better way to get the programmers you want than to entice them with a free class in the language you want them to use, and let the ones who are truly motivated show themselves to you. The best place to advertise these classes are the above user groups.
Defendant was required to provide the name and address of each person who used his computer during the three years prior to commencement of the lawsuit.
See Appendix A, a Manhattan phone directory. There, it contains a list of every person who has accessed the computer in the past 3 years, plus a few others. That's within the letter of the decision, and is actually somewhat common in defense. The defense literally floods the plaintiff with thousands of files, of which it is unlikely the plaintiff will be able to sort through to obtain the necessary data in time for trial.
Oh noes! Software doesn't get churned out immediately upon the suggestion of parallel programming! Programmers might actually be debugging their own code!
There's nothing new here: just somebody being impatient. Parallel code is getting written. It is not difficult, nor are the tools inadequate. What we have is non-programmers not understanding that it takes a while to write new code.
If anything, that the world hasn't exploded with massive amounts of parallel code is a good thing: it means that proper engineering practice is being used to develop sound programs, and the jonny-come-lately programmers aren't able to fake their way into the marketplace with crappy code, like they did 10 years ago.
Uh, if you've dealt with exactly zero problems on your FreeBSD boxes, then you have a rather vulnerable box. The BSDs are good, but they aren't THAT good.
Best place to get some experience is with a small local tech company. I am the lead programmer and PBX admin for a small consulting company, located in a small town north of Nashville, TN. We recently had a longtime (2 years, off and on) intern/employee who graduated high school and now is going to college. I trained him myself in Perl, and he worked on a project which scripted Scribus. During the summer he worked full time, and during the school year, he came in on some afternoons after school (although schoolwork always came first).
The key here is that a small local company is the one that will be most likely to let you soar to new heights. Larger companies are going to confine you to largely menial labor helping other tech professionals, which, while it may help you find menial jobs in the future, is not a great experience and doesn't give you good experience that you can put on your resume. (Being a summer copy and errand boy for <insert-company-here> doesn't really speak to your technical qualifications.) A small company is also more likely to be flexible, including letting you stay on part time while school is in session.
I called up Comcast and had a recording saying service was out in some places in my area, so I didn't bother waiting on hold.
All that means is that they have more than 2 service calls in your area. I'm serious. I have friends who work for Comcast, and that is literally what that phrase means.
I had fun of my own when Comcast marketed their voice service to me. At the time, I was having trouble with outages every time it rained, so I posed the question, "How am I going to call Comcast to report an outage, when the service is out?" The answer was priceless. "Don't you have a cell phone?" That pretty much sums up why I don't have Comcast Voice.
Network TV gets explicit permission to edit the movie before showing it. It is well known, for example, that Steven Spielberg withholds permission to show 'Saving Private Ryan' with any cuts whatsoever. If network TV wants to show 'Saving Private Ryan', they have to show the whole movie or not show it at all.
Supposing in an e-government initiative, you signed up to allow the county to send you notices when you had to do various things. For example, the county might send you an email to remind you to pay your property taxes, renew your driver's license, or ask you to show up for jury duty. And suppose that email was blocked by your ISP. While you were not expecting the email, it is highly likely that those notices were all important to you, not only because you signed up for them, but also because if you fail to heed their notices, you're in line for arrest, fines, or jail time.
In other words, not everything which is important to you are things that you expect. In many cases, you are unaware of things that will become very important to you, when you receive the notice.
There are two kinds of people in the world: those who categorize others into nice simple dichotomies and those who realize that most people do not fall into neat little categories, but rather consume the spectrum between multiple points of view.
I think I've already addressed that. Telephony needs a pure multiple of 1,000 to function correctly, and the Zaptel dummy driver that operates on top of RTC by dropping 24 interrupts gets a "close enough" heartbeat to be used. It's not perfect, not optimal, but it will work.
Apparently you feel that because the RTC generates an interrupt, we ought to use that without going through Zaptel. Again, that's already been addressed: the PSTN requires a more exact source of interrupts. Consider trying to interface two Asterisk systems together, one using a 1024Hz clock, the other one using a 1000Hz clock. Sorry, the drift you're going to get is unacceptable. Using a 1000Hz clock everywhere is a much more reasonable approach.
I am also an Asterisk developer and the list of my contributions to Asterisk are about as long as anthm's. While I certainly agree that he's entitled to his opinion, I disagree with him on many of his points.
The modular intentions of Asterisk are great though there is no structure there either.
There is plenty of structure, here, and while in the past some of the lines between different concepts have been blurry, we are continually improving the definitions and coming up with yet better core structures. We're improving. Anthony even made some of these contributions, but we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.
This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid".
We cannot control how other people act in public. Certainly we have a very vibrant community, but the first experience for Asterisk newcomers is generally the mailing list, not the IRC channel. While we certainly try not to feed the trolls, anybody who has been reading Slashdot for more than a week knows that the trolls stick around. And while we might rebuke others for being cruel on IRC, we cannot control how our users interact. For one thing, we cannot monitor the IRC channel 24/7; for another thing, our work is on Asterisk, not on controlling other users.
I would defy anyone to find a vibrant open source software community that does not have people who will respond in sometimes nasty ways to people who have not yet learned to ask Smart Questions.
Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit.
I'll admit that this has been a problem in the past, but we are working hard to correct it. Bugs filed are generally addressed the next day or at least within 7 days of them being posted. While there are certainly bugs that we reject, quite frequently patches go into SVN within hours of them being submitted. There are also complex patches that require more thought and careful consultation with other developers, to ensure they take the code in directions that we wish to go. These are generally the types of bugs which remain open the longest -- not because we're ignoring them, but because we are carefully considering them.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough learned and progressed and became developers. It's terrible that some people have forgotten this.
I could go on for ages documenting more issues but they tend to fall on deaf ears.
They actually didn't fall on deaf ears. Many of anthm's criticisms were taken quite seriously and have been addressed. It's sad to see another developer take his ball and go home, but we continue to move forward, with or without him. We aren't his keeper, and it's certainly his right to develop whatever he likes.
Here I am, doing nothing but IAX2. There is no reason that I should have to load a zaptel driver!
And if you're using IAX2, you don't need to use Zaptel normally. The only reason you'd need to use Zaptel with IAX2 is if you were doing IAX trunking, something which most people do not do.
A little bit of background for those readers unfamiliar with the issues. Telephone systems use a very strict timer of 8000 Hz. Given that this is far too heavy of an interrupt load for the PCI bus, Asterisk compromises and uses a 1000Hz interrupt, moving 8 samples for each interrupt. The RTC is close to 1000, but really isn't: it generates a 1024Hz interrupt. We compensate for the RTC clock in systems which don't have Zaptel hardware by ignoring 24 interrupts per second, thus letting us move the same 8,000 samples per second. Unfortunately, because we have to ignore some interrupts, the samples spacing is not quite equidistant, so there's some audio jitter caused by using RTC. It's not terrible, but it's not optimal.
Zaptel, in additional to the telephony interface needed, whether it be T1, E1, or analog, also generates that nice consistent 1000Hz interrupt. Note that in systems that especially interface to the PSTN digitally (i.e. T1 or E1), we absolutely MUST match the timing of the PSTN exactly. 1024 minus 24 is not "good enough". This is the primary reason why we must have an accurate timer and why Asterisk relies intrinsically upon having such a timer available. Given that you have an accurate timer available, why would you code to anything else?
The zaptel driver is a crude piece of crap that was rejected by the kernel developers. It is unfit for serious use.
I'm unaware that Zaptel has ever been submitted to the kernel developers, let alone rejected. Frankly, the code moves too quickly for us to consider letting it be maintained by the kernel developers. Even if it was in the kernel, the stock kernel driver would be unlikely to be ever used, given that it would almost always be out of date. That's quite simply just wasted effort on maintenance by kernel developers. I'm sure we can all agree that the kernel developers have more important issues to deal with. As to the zaptel driver being "unfit", well, it's used in thousands of Asterisk systems around the world with no problem at all. This declaration that it's unfit sounds suspiciously like FUD.
I have to remind people that C++ was originally implemented in C as a set of macros. While we certainly can miss many of the obscene features of C++, we disambiguate the code by going the simpler route. While C++ implements a lot of nice ideas, remember that these are programming techniques, to make the program easier to read and maintain. They are properly not language features. At the end of the day, it's all object code, anyway.
Seriously, the USA exercises exactly as much control over the namespace each sysadmin chooses to give them.
That cuts both ways. How likely are you to switch your DNS over to a new, untested root server system?
I think it really comes down to the old question, "What if they held a war, and nobody came?", except that in this case, the question will be, "What if they propose a new set of root servers, and nobody used them?"
How about "boyfriend who is a kickass firefighter, but doesn't know shit about Linux"? Several months ago, he got fed up with the spyware removal that he had to do almost everyday, in addition to the viruses and other malware. He asked me to completely wipe the computer and install Linux. I had to twist his arm to get him to backup some of his files before the reinstall.
Now that he's on Mandrake (okay, Mandriva), using KDE 3.3 as his desktop, he hasn't twitched. I completely expected him to try out Linux for about a week, then go back to Windows 2000. It's not for lack of availability of the Windows install disks -- those have been sitting next to his computer where they always have been, still collecting dust.
The only app that he misses (or at least that he's told me about) is iTunes, which is one of those apps that I recommended that he download in the first place (I have a Mac in addition to my Linux desktop). And the additional benefit to him is that when I find a kickass application, like gaym-plugin, I install it on his machine, without ever having to sit down at his machine, like I had to do with Windows. Yes, I know about rdesktop for remote administration of Windows, but I'm not a Windows guy, and I don't pretend to be.
There is no surer conversion story than one from someone who is not CS-inclined.
No, but the zoneinfo files are remarkably simple. I could probably change all timezones that are affected by the US change in DST in an afternoon (the majority of which will simply be coding a dump and undump script for the zoneinfo files). Then it's just a matter of copying the files around to all the deployed machines we maintain.
See tzfile(5) for the format. It's really dead-simple.
Everybody (and Slashdot) just got played. This is par for the course for John Tierney. He lives to make really stupid suggestions in his columns, just to get people to respond. It's his own way of feeling important in the world. If enough people ignore his garbage columns, he will eventually go away.
For more perspective on this, and to see some of the subjects of his past columns, see here.
Slashdot Mirror
Skype for Asterisk is far from a third party hack. It was designed around the Skype Engine API, at a time when Skype was not providing access to that API to the general public (I think they still aren't providing that level of access). In fact, Skype approached Mark Spencer (original programmer of Asterisk), not the other way around. So while the integration was largely written by Digium programmers, the Skype connector has always been a direct project of Skype's.
As far as Google's communication protocols are concerned, they use all freely and openly licensed protocols, and support for them has long been integrated in Asterisk. (Yes, you can use Google Voice with Asterisk.)
Your comparison fails.
Now lets say you have a huge catalog of songs you'd like to defend. You're a big mega corporation so what you do is you hire developers to analyze songs for fingerprints and -- funny how pedantic algorithms get to be -- submit anything over the 'safe harbor' limit to Control Gate C (that being the legal arm which churns out thousands of take down notices).
If I am the CEO of a mega corporation, then I know the value of good will to generate goodwill and I will put some kind of human at Control Gate C who will put a stopper on the mindless sharks in my legal department who would sully my business' positive reputation by suing dancing toddlers.
As would I, which is probably why neither of us are (or ever will be) CEO of a mega corp.
Actually, there's a very well-known CEO who considers exactly that, and he has been, at one time or another, considered the richest man in the world: Warren Buffett. He famously once said, "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."
Most of these responses are geared towards evaluating people once they're in the door, and that's fine, but if you want to find quality people, the best way to do it is to flip around the question and think about it from the prospective employee's point of view: how do they find you?
Word of mouth is certainly the best way, but I've also found the following ways that work:
Hang around computer groups in your area, talk to people, learn who's good. Many businesspeople will try this once, in that they attend one meeting, they talk to the members of the group, and they leave, and they don't find it very worthwhile. The problem with this approach is that the members are unlikely to open up to you the first time they're meeting you. You need to hang around for several meetings before they will begin to trust your presence and will open up to you, and you can then discover which ones are bullshit artists and which ones truly have talent to share.
Teach programming classes. This is what I do. I teach a weekly class from time to time, on C or Perl. I give the class for free, the class lasts 8-10 weeks, and the ones who turn in their homework assignments, and ask for feedback are the type of people that you want -- they are the type to become superstar programmers, and with a little guidance, they will. This also means that you can hire them on a fair market salary and not have to pay the big bucks. After all, you are looking for motivated individuals who are willing to learn new things. What better way to get the programmers you want than to entice them with a free class in the language you want them to use, and let the ones who are truly motivated show themselves to you. The best place to advertise these classes are the above user groups.
DMCA doesn't apply here. There is no technology employed that effectively protects a copyrighted work, which is required for a DMCA prosecution.
Defendant was required to provide the name and address of each person who used his computer during the three years prior to commencement of the lawsuit.
See Appendix A, a Manhattan phone directory. There, it contains a list of every person who has accessed the computer in the past 3 years, plus a few others. That's within the letter of the decision, and is actually somewhat common in defense. The defense literally floods the plaintiff with thousands of files, of which it is unlikely the plaintiff will be able to sort through to obtain the necessary data in time for trial.
Yes, but until he actually resides in university housing, he hasn't incurred any debt. This is a deposit, remember.
The site has been taken down, due to being Slashdotted, but the article has been cached by Google here.
Oh noes! Software doesn't get churned out immediately upon the suggestion of parallel programming! Programmers might actually be debugging their own code!
There's nothing new here: just somebody being impatient. Parallel code is getting written. It is not difficult, nor are the tools inadequate. What we have is non-programmers not understanding that it takes a while to write new code.
If anything, that the world hasn't exploded with massive amounts of parallel code is a good thing: it means that proper engineering practice is being used to develop sound programs, and the jonny-come-lately programmers aren't able to fake their way into the marketplace with crappy code, like they did 10 years ago.
Uh, if you've dealt with exactly zero problems on your FreeBSD boxes, then you have a rather vulnerable box. The BSDs are good, but they aren't THAT good.
Best place to get some experience is with a small local tech company. I am the lead programmer and PBX admin for a small consulting company, located in a small town north of Nashville, TN. We recently had a longtime (2 years, off and on) intern/employee who graduated high school and now is going to college. I trained him myself in Perl, and he worked on a project which scripted Scribus. During the summer he worked full time, and during the school year, he came in on some afternoons after school (although schoolwork always came first).
The key here is that a small local company is the one that will be most likely to let you soar to new heights. Larger companies are going to confine you to largely menial labor helping other tech professionals, which, while it may help you find menial jobs in the future, is not a great experience and doesn't give you good experience that you can put on your resume. (Being a summer copy and errand boy for <insert-company-here> doesn't really speak to your technical qualifications.) A small company is also more likely to be flexible, including letting you stay on part time while school is in session.
I called up Comcast and had a recording saying service was out in some places in my area, so I didn't bother waiting on hold.
All that means is that they have more than 2 service calls in your area. I'm serious. I have friends who work for Comcast, and that is literally what that phrase means.
I had fun of my own when Comcast marketed their voice service to me. At the time, I was having trouble with outages every time it rained, so I posed the question, "How am I going to call Comcast to report an outage, when the service is out?" The answer was priceless. "Don't you have a cell phone?" That pretty much sums up why I don't have Comcast Voice.
Network TV gets explicit permission to edit the movie before showing it. It is well known, for example, that Steven Spielberg withholds permission to show 'Saving Private Ryan' with any cuts whatsoever. If network TV wants to show 'Saving Private Ryan', they have to show the whole movie or not show it at all.
In other words, not everything which is important to you are things that you expect. In many cases, you are unaware of things that will become very important to you, when you receive the notice.
There are two kinds of people in the world: those who categorize others into nice simple dichotomies and those who realize that most people do not fall into neat little categories, but rather consume the spectrum between multiple points of view.
Apparently you feel that because the RTC generates an interrupt, we ought to use that without going through Zaptel. Again, that's already been addressed: the PSTN requires a more exact source of interrupts. Consider trying to interface two Asterisk systems together, one using a 1024Hz clock, the other one using a 1000Hz clock. Sorry, the drift you're going to get is unacceptable. Using a 1000Hz clock everywhere is a much more reasonable approach.
The modular intentions of Asterisk are great though there is no structure there either.
There is plenty of structure, here, and while in the past some of the lines between different concepts have been blurry, we are continually improving the definitions and coming up with yet better core structures. We're improving. Anthony even made some of these contributions, but we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.
This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid".
We cannot control how other people act in public. Certainly we have a very vibrant community, but the first experience for Asterisk newcomers is generally the mailing list, not the IRC channel. While we certainly try not to feed the trolls, anybody who has been reading Slashdot for more than a week knows that the trolls stick around. And while we might rebuke others for being cruel on IRC, we cannot control how our users interact. For one thing, we cannot monitor the IRC channel 24/7; for another thing, our work is on Asterisk, not on controlling other users.
I would defy anyone to find a vibrant open source software community that does not have people who will respond in sometimes nasty ways to people who have not yet learned to ask Smart Questions.
Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit.
I'll admit that this has been a problem in the past, but we are working hard to correct it. Bugs filed are generally addressed the next day or at least within 7 days of them being posted. While there are certainly bugs that we reject, quite frequently patches go into SVN within hours of them being submitted. There are also complex patches that require more thought and careful consultation with other developers, to ensure they take the code in directions that we wish to go. These are generally the types of bugs which remain open the longest -- not because we're ignoring them, but because we are carefully considering them.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough learned and progressed and became developers. It's terrible that some people have forgotten this.
I could go on for ages documenting more issues but they tend to fall on deaf ears.
They actually didn't fall on deaf ears. Many of anthm's criticisms were taken quite seriously and have been addressed. It's sad to see another developer take his ball and go home, but we continue to move forward, with or without him. We aren't his keeper, and it's certainly his right to develop whatever he likes.
And if you're using IAX2, you don't need to use Zaptel normally. The only reason you'd need to use Zaptel with IAX2 is if you were doing IAX trunking, something which most people do not do.
A little bit of background for those readers unfamiliar with the issues. Telephone systems use a very strict timer of 8000 Hz. Given that this is far too heavy of an interrupt load for the PCI bus, Asterisk compromises and uses a 1000Hz interrupt, moving 8 samples for each interrupt. The RTC is close to 1000, but really isn't: it generates a 1024Hz interrupt. We compensate for the RTC clock in systems which don't have Zaptel hardware by ignoring 24 interrupts per second, thus letting us move the same 8,000 samples per second. Unfortunately, because we have to ignore some interrupts, the samples spacing is not quite equidistant, so there's some audio jitter caused by using RTC. It's not terrible, but it's not optimal.
Zaptel, in additional to the telephony interface needed, whether it be T1, E1, or analog, also generates that nice consistent 1000Hz interrupt. Note that in systems that especially interface to the PSTN digitally (i.e. T1 or E1), we absolutely MUST match the timing of the PSTN exactly. 1024 minus 24 is not "good enough". This is the primary reason why we must have an accurate timer and why Asterisk relies intrinsically upon having such a timer available. Given that you have an accurate timer available, why would you code to anything else?
The zaptel driver is a crude piece of crap that was rejected by the kernel developers. It is unfit for serious use.
I'm unaware that Zaptel has ever been submitted to the kernel developers, let alone rejected. Frankly, the code moves too quickly for us to consider letting it be maintained by the kernel developers. Even if it was in the kernel, the stock kernel driver would be unlikely to be ever used, given that it would almost always be out of date. That's quite simply just wasted effort on maintenance by kernel developers. I'm sure we can all agree that the kernel developers have more important issues to deal with. As to the zaptel driver being "unfit", well, it's used in thousands of Asterisk systems around the world with no problem at all. This declaration that it's unfit sounds suspiciously like FUD.
I have to remind people that C++ was originally implemented in C as a set of macros. While we certainly can miss many of the obscene features of C++, we disambiguate the code by going the simpler route. While C++ implements a lot of nice ideas, remember that these are programming techniques, to make the program easier to read and maintain. They are properly not language features. At the end of the day, it's all object code, anyway.
While there certainly are the Vonages of the world, there are far more VoIP services that permit you to connect any phone you like.
Quite sure. Mark Spencer is a personal friend (I'm one of the core developers of Asterisk).
That cuts both ways. How likely are you to switch your DNS over to a new, untested root server system?
I think it really comes down to the old question, "What if they held a war, and nobody came?", except that in this case, the question will be, "What if they propose a new set of root servers, and nobody used them?"
Hey, wow, that is completely original. Nobody else could have possibly thought of this idea before.
Now that he's on Mandrake (okay, Mandriva), using KDE 3.3 as his desktop, he hasn't twitched. I completely expected him to try out Linux for about a week, then go back to Windows 2000. It's not for lack of availability of the Windows install disks -- those have been sitting next to his computer where they always have been, still collecting dust.
The only app that he misses (or at least that he's told me about) is iTunes, which is one of those apps that I recommended that he download in the first place (I have a Mac in addition to my Linux desktop). And the additional benefit to him is that when I find a kickass application, like gaym-plugin, I install it on his machine, without ever having to sit down at his machine, like I had to do with Windows. Yes, I know about rdesktop for remote administration of Windows, but I'm not a Windows guy, and I don't pretend to be.
There is no surer conversion story than one from someone who is not CS-inclined.
See tzfile(5) for the format. It's really dead-simple.
For more perspective on this, and to see some of the subjects of his past columns, see here.