I have run SMTP servers in the past (right now, both at work and at home, it's handled by other people).
Think of it this way: I get a lot of spam, and I download it to my computer. It's annoying to have to look through it. But it clearly doesn't take a lot of resources: it takes a couple of minutes per day to download and almost no CPU time to process. Browsing the web for a few minutes is more effort. Clearly, when looked at it per-user, spam is not a bandwidth or resource problem.
See this reaction
That link shows exactly what is wrong. The guy is complaining that he can't handle thousands of mailboxes on a single SPARC 2. Would he expect to be able to handle thousands of dial-ins on a single SPARC 2? Would he expect to be able to handle switching network connections for thousands of users through a single SPARC 2? Would he expect to be able to cache and proxy the traffic from thousands of web users through a single SPARC 2?
Mail traffic used to be unusually small compared to other traffic and ISPs have gotten used to getting off cheap in terms of hardware and to be able to centralize it. Now it's catching up with other traffic and ISPs are whining.
And if ISPs want to get rid of the problem, there is a very simple solution, at least for broadband providers: give people static IP addresses and let them run their own SMTP servers. They can do that either on their PCs, or the broadband modems or firewalls could acquire store-and-forward functionality for mail. Then, the hardware is distributed, people pay for the level of SMTP service they need and want through their choice of equipment and bandwidth, and ISPs are rid of the problem. My $170 embedded firewall on my broadband connection has more than enough capacity as it is to handle my mail volume.
On a somewhat related note, I think it is stupid that Apple ships kernels without support for system call tracing tools like "strace" or "truss". System call tracing should be part of the standard install of OS X; it is particularly important on non-development machines. (How is this related? It sounds to me like you could use systrace to implement strace, and (less efficiently) vice versa.)
In any case, I thought that one of the promises of Mach was that these kinds of changes should be doable via plug-ins, without creating a new kernel. Why does this require a "new kernel"?
That GNU-Darwin people decides not to link to "proprietary" libraries is, of course, a result of them using the GNU Public License so extensively-- and now the primary supported Darwin platform is not even supported in this project!
Your interpretation is wrong. The GPL allows linking to proprietary system libraries. Otherwise, it would be impossible to use GNU tools on proprietary UNIX systems.
The reason why the GNU-Darwin folks have stopped supporting Apple's platforms is because they are really pissed off at some of Apple's policies and actions, and frankly, I can't blame them.
Where's the fucking logic?
The "fucking logic" is that Darwin is a derivative of an open source kernel; Apple took Mach and built a business around it. The fact that other people bring the formerly open source kernel back into the public arena and build a system around it implies no obligation to blindly accept everything else Apple is doing. In fact, Apple itself has made clear that they want open source not to tread anywhere near creating a work-alike of their system: Cocoa and other parts of Macintosh OS X are highly proprietary and considered the "crown jewels" by Apple.
This is the GPL in action, Mac faithful. Get down and kiss Apple's butt for choosing the BSD license.
This has nothing to do with the GPL.
And, in any case, where did Apple "choose" the BSD license? NeXT took some software under the BSD license and built a large proprietary system around it. Apple also took some GPL'ed software (gcc) and used it. And the open source software Apple is releasing is usually covered by non-BSD licenses. I don't see much of a difference between the two now that the software has been released.
But if Mach had been covered by the GPL, NeXT's changes to it would have become public a long time ago, which means that we might all be running Darwin now instead of Linux. If you like Apple, I think that's something you should have liked.
Apple still has a mostly-proprietary world view, and they seem to use open source only if they think it gives them a short-term business advantage. I think that's going to hurt them in the long term. Something like Cocoa/Quartz, for example, only even stands a chance to become widely used if it gets open sourced and ported to other systems.
Don't get too excited. Think about it: you are looking through a 14" rectangular window from a few feet away. And you can't get much closer than a few feet away because the resolution is too low. And you probably can't move your head too far from side to side either. It's going to be like looking at a scene contained in a shoebox.
There are some 3D scenes that it makes sense to watch that way: 3D molecules, geometric models, etc. But I wouldn't expect the experience to be too realistic for 3D games or pr0n. But realistic or not, I suppose it might still be fun.
We perceive 3D shape in many ways. Stereo vision, which these displays provide is only one, and not really the most important one (many people don't have stereo vision at all). I think what would be much more exciting for games are displays with head tracking and peripheral vision; those give you much more of a feeling of "being there" than stereo vision. The ways to create such immersive displays is via something like "the Cave" (very expensive all-around projection) or head-mounted displays; both are unfortunately still expensive, but technologically, they are perhaps simpler than attempts at providing stereo vision.
Really, if the FCC is going to assign new frequencies for wireless networking, we owe it to ourselves to become acquainted with the technology and the rules thereof. The last thing that anyone needs is to turn 802.11 into another RF wasteland like CB radio.
That's why we have licensing for radio operators: people are supposed to demonstrate a minimum amount of knowledge before they go around hacking radio transmitters.
The real problem is that the law doesn't require licenses for modifications to radio equipment in many cases, and that when they do, people don't know about it and it doesn't get enforced anyway.
For 802.11b and other uses of the "unlicensed" 2.4G and 5G bands, the rules should really prohibit the kinds of modifications to antennas that people are making--operation of those devices by unlicensed operators should only be permitted with the original antennas, and they should be subject to FCC review. Otherwise, we are inviting abuses: if someone aims one of those things at your house, your own equipment may stop working and you won't even be able to figure out why.
I think the rules should also prohibit the use of unlicensed spectrum by B2B or B2C services; extensive use of 802.11b by for-pay ISPs and voice providers may well render the bands useless for their originally intended purpose. Companies wanting to derive a profit by providing services should pay for their own bandwidth.
Yes, spam is annoying. Yes, end-users have a right to complain about it.
But ISPs have little to complain about. All the spam people receive amounts only to a small fraction of their normal Internet bandwidth usage: per day, you almost certainly generate more bandwidth, TCP connections, and server transactions in pop-up ads than in spam. If an ISP's E-mail servers cannot handle that workload for their users, they are doing something wrong. And if they want to off-load the responsibility of running the server, broadband providers should just drop their restrictions on their customers running servers so that everybody can run their own mail drop.
Re:Subversion is far better than CVS
on
Multi-User Subversion
·
· Score: 3, Insightful
But this new file does not have the history of the old file,
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
you can not check out last weeks version of it
Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.
and it is not included in diffs of changes that spanned multiple files.
Huh? Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming.
Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.
Version control works fine across file renames; CVS simply doesn't make it obvious that a rename happened (the old file disappears, a new file with a clean log appears). The simple way of dealing with it is to add a comment to the new file "formerly known as".
If it really confuses you, it's easy to give people a shell script to do the remove/add, add a comment, and optionally, add a copy of the old log. Perhaps the CVS developers should do just that.
has some issues with binary files,
I dunno--they seem to get handled just fine. They aren't diffed, but so what? Perhaps the CVS frontend should finally detect binary files automatically--doing that wouldn't be hard.
the CVS code base has serious design issues.
Lots of widely used big C programs have "serious design issues", at least in some people's eyes. I've come to the conclusion that if it works reliably, it's best not to look under the hood. And CVS works reliably. I'd trust it over a well-designed but new codebase any day.
The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs.
To rename files in CVS, you remove the old file and add it as a new file. The semantics of this are well-defined, and you will get a consistent view of the tree no matter which version you check out. It's simplistic, but it works. The one thing that is a bit clunky is the fact that old, empty directories hang around, but that really isn't a big deal in practice.
People like to complain endlessly about CVS and its quirks. And, yes, it does have quirks. But CVS mature, it works, and its quirks really don't affect day-to-day development in most environments.
Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.
The use of Apache 2 is a show-stopper as far as I'm concerned: we have no interest in migrating to Apache 2 in the foreseeable future. Is there a small, simple standalone server for subversion, or can I run it over ssh? Does subversion work with non-Apache WebDav implementations? Is there a CGI version of its server component?
In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.
Click-through indicates interest on the part of the user. It lets advertisers engage with people who are interested while avoiding annoying potential future customers. Mouse-over does not indicate interest, so it's no better than simply popping up windows randomly, and advertisers can do that already.
is tens of thousands of flying anything buzzing over my backyard everyday and occasionally crashing into it. Please keep the commute traffic on the highways.
If personal aircraft ever become economically viable, you can bet that they will be even more strongly regulated than current aircraft.
datareduced audio could possibly lead to fatal [sic] consequences
I don't think consequences will be quite that serious. Still, it warrants looking into: there is probably some adaptation to compressed audio, and that adaptation may distort the perception of regular sounds.
In Brin's vision, society is transparent to everybody. I think that may be an acceptable tradeoff: I'd be willing to trade my privacy if in return we all can finally know what's going on inside the government, military, corporations, police, etc.
The real problem is one-sided transparency: if the government has all the knowledge, the government is all powerful: it can use its knowledge for blackmail, for constructing "secret evidence" to be used in trials, etc., and ordinary citizens have no way of fighting that.
Take speed traps as an example. As long as the police does not release detailed information on who gets caught where and when, you can argue until you are blue in the face in front of a judge--if a policeman stands up and says you speeded, you will get convicted. If, on the other hand, all related data is available, you might well be able to prove that the policeman didn't calibrate the radar gun, that they are engaging in selective enforcement, that the speed limit at that location is deliberately too low, that the location is being used for "revenue enhancement", etc.
The Bush administration is one of the most secretive governments we have had in a long time. People like Poindexter don't want transparency, they want a large differential in the amount of information available to the government and corporations vs. the amount of information available to individuals. And they want that as a means of control.
And any design that mixes up the images with the text and thereby risks writing 5-10Mbytes every time you save a document is seriously broken. There are better ways of keeping images and text together than OLE structured storage.
Anything that isn't gushing with enthusiasm over Apple and their technology is modded down. Come on, guys, get over the group-think. Arguing that Apple is not going to be a significant technological player in the decades to come is not the same as "trolling". If you disagree, say why, don't mod people down.
Plato might not constitute prior art from a legal point of view because it probably involved multiple users logged into a single mainframe. AOL's patent applies to networks of computers. Personally, I find such distinctions unwarranted, but that's how patent lawyers think.
However, there is plenty of other prior art. Many IRC clients have had buddy lists, alerts, ignores, private chats, and other features for a long time. And the MIT Zephyr messaging platform is almost completely equivalent to modern IM systems in capabilities and functionality.
The rules are indeed different for convicted monopolists, or even companies that dominate a market. It's OK for you to release a broken version of XML for your office suite, it's not necessarily OK for Microsoft.
XML has some clothes. While you may not be able to understand the content of arbitrary XML documents, you can understand their structure. That enables a lot of things that would not be possible with formats like Word's native format or even other markup languages.
For example, being able to understand the structure of XML documents makes reverse engineering much easier. It also lets you embed one XML document inside another and deals with the resulting namespace issues correctly. And there are many other things that XML helps with--it's not sufficient for a universal format, but it takes care of the nitty-gritty that, if not taken care of, can break portability.
RTF has been in office for years and it is an open, portable standard readable on many platforms and with many programs.
I would dispute that RTF is "portable" or "standard". However, whatever it is, it simply does not seem to preserve appearance and markup sufficiently well to be used as an interchange format. Perhaps it could in theory, but in practice, it doesn't seem to.
You are (presumably) not a convicted monopolist, so you can do whatever you want to when it comes to file formats. But Microsoft is a convicted monopolist, and it is proper for the government to tell them what format to save their files in, in particular when their choice of format is one of the principal ways by which they are able to maintain their monopoly.
As for making it the default, if it isn't the default, it won't work. Not only do most users not understand how to save in other file formats, if it isn't the default, it probably will be too buggy to be used. None of the non-Microsoft formats in Word, PowerPoint, or Excel are really usable for day-to-day use because they lose formatting or worse.
it places little or no copyright restrictions on content
Copyright is a legal issue, not a technical one. The "copyright restrictions" on the content are the same as they always have been.
What appears to be the case is that it doesn't try to put a lot of technical DRM restrictions on the content, and that is nice. DRM generally restricts use of content much further than copyright.
Sorry, but I find the premise of the book bad. If there is one thing good about cybersex it's that you can't catch viruses from that. Maybe your computer can, but you can't.
If people acted out more perversions in cyberspace instead of the real world, we'd all be better off.
TFTP is based on UDP--that's not the kind of protocol you want to use over a long-haul, noisy connection.
A TCP-based protocol is exactly the right thing for this application. The only thing they have to watch out for is that they need to increase timeouts and other parameters that have been adjusted downwards in consumer machines for "performance reasons". FTP's use of separate control and data connections also makes it a little more attractive than alternatives.
I doubt authentication was a consideration--FTP is insecure anyway. They probably use firewalls.
Slashdot Mirror
Think of it this way: I get a lot of spam, and I download it to my computer. It's annoying to have to look through it. But it clearly doesn't take a lot of resources: it takes a couple of minutes per day to download and almost no CPU time to process. Browsing the web for a few minutes is more effort. Clearly, when looked at it per-user, spam is not a bandwidth or resource problem.
See this reaction
That link shows exactly what is wrong. The guy is complaining that he can't handle thousands of mailboxes on a single SPARC 2. Would he expect to be able to handle thousands of dial-ins on a single SPARC 2? Would he expect to be able to handle switching network connections for thousands of users through a single SPARC 2? Would he expect to be able to cache and proxy the traffic from thousands of web users through a single SPARC 2?
Mail traffic used to be unusually small compared to other traffic and ISPs have gotten used to getting off cheap in terms of hardware and to be able to centralize it. Now it's catching up with other traffic and ISPs are whining.
And if ISPs want to get rid of the problem, there is a very simple solution, at least for broadband providers: give people static IP addresses and let them run their own SMTP servers. They can do that either on their PCs, or the broadband modems or firewalls could acquire store-and-forward functionality for mail. Then, the hardware is distributed, people pay for the level of SMTP service they need and want through their choice of equipment and bandwidth, and ISPs are rid of the problem. My $170 embedded firewall on my broadband connection has more than enough capacity as it is to handle my mail volume.
In any case, I thought that one of the promises of Mach was that these kinds of changes should be doable via plug-ins, without creating a new kernel. Why does this require a "new kernel"?
Your interpretation is wrong. The GPL allows linking to proprietary system libraries. Otherwise, it would be impossible to use GNU tools on proprietary UNIX systems.
The reason why the GNU-Darwin folks have stopped supporting Apple's platforms is because they are really pissed off at some of Apple's policies and actions, and frankly, I can't blame them.
Where's the fucking logic?
The "fucking logic" is that Darwin is a derivative of an open source kernel; Apple took Mach and built a business around it. The fact that other people bring the formerly open source kernel back into the public arena and build a system around it implies no obligation to blindly accept everything else Apple is doing. In fact, Apple itself has made clear that they want open source not to tread anywhere near creating a work-alike of their system: Cocoa and other parts of Macintosh OS X are highly proprietary and considered the "crown jewels" by Apple.
This is the GPL in action, Mac faithful. Get down and kiss Apple's butt for choosing the BSD license.
This has nothing to do with the GPL.
And, in any case, where did Apple "choose" the BSD license? NeXT took some software under the BSD license and built a large proprietary system around it. Apple also took some GPL'ed software (gcc) and used it. And the open source software Apple is releasing is usually covered by non-BSD licenses. I don't see much of a difference between the two now that the software has been released.
But if Mach had been covered by the GPL, NeXT's changes to it would have become public a long time ago, which means that we might all be running Darwin now instead of Linux. If you like Apple, I think that's something you should have liked.
Apple still has a mostly-proprietary world view, and they seem to use open source only if they think it gives them a short-term business advantage. I think that's going to hurt them in the long term. Something like Cocoa/Quartz, for example, only even stands a chance to become widely used if it gets open sourced and ported to other systems.
There are some 3D scenes that it makes sense to watch that way: 3D molecules, geometric models, etc. But I wouldn't expect the experience to be too realistic for 3D games or pr0n. But realistic or not, I suppose it might still be fun.
We perceive 3D shape in many ways. Stereo vision, which these displays provide is only one, and not really the most important one (many people don't have stereo vision at all). I think what would be much more exciting for games are displays with head tracking and peripheral vision; those give you much more of a feeling of "being there" than stereo vision. The ways to create such immersive displays is via something like "the Cave" (very expensive all-around projection) or head-mounted displays; both are unfortunately still expensive, but technologically, they are perhaps simpler than attempts at providing stereo vision.
That's why we have licensing for radio operators: people are supposed to demonstrate a minimum amount of knowledge before they go around hacking radio transmitters.
The real problem is that the law doesn't require licenses for modifications to radio equipment in many cases, and that when they do, people don't know about it and it doesn't get enforced anyway.
For 802.11b and other uses of the "unlicensed" 2.4G and 5G bands, the rules should really prohibit the kinds of modifications to antennas that people are making--operation of those devices by unlicensed operators should only be permitted with the original antennas, and they should be subject to FCC review. Otherwise, we are inviting abuses: if someone aims one of those things at your house, your own equipment may stop working and you won't even be able to figure out why.
I think the rules should also prohibit the use of unlicensed spectrum by B2B or B2C services; extensive use of 802.11b by for-pay ISPs and voice providers may well render the bands useless for their originally intended purpose. Companies wanting to derive a profit by providing services should pay for their own bandwidth.
But ISPs have little to complain about. All the spam people receive amounts only to a small fraction of their normal Internet bandwidth usage: per day, you almost certainly generate more bandwidth, TCP connections, and server transactions in pop-up ads than in spam. If an ISP's E-mail servers cannot handle that workload for their users, they are doing something wrong. And if they want to off-load the responsibility of running the server, broadband providers should just drop their restrictions on their customers running servers so that everybody can run their own mail drop.
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
you can not check out last weeks version of it
Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.
and it is not included in diffs of changes that spanned multiple files.
Huh? Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming.
Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.
Version control works fine across file renames; CVS simply doesn't make it obvious that a rename happened (the old file disappears, a new file with a clean log appears). The simple way of dealing with it is to add a comment to the new file "formerly known as".
If it really confuses you, it's easy to give people a shell script to do the remove/add, add a comment, and optionally, add a copy of the old log. Perhaps the CVS developers should do just that.
has some issues with binary files,
I dunno--they seem to get handled just fine. They aren't diffed, but so what? Perhaps the CVS frontend should finally detect binary files automatically--doing that wouldn't be hard.
the CVS code base has serious design issues.
Lots of widely used big C programs have "serious design issues", at least in some people's eyes. I've come to the conclusion that if it works reliably, it's best not to look under the hood. And CVS works reliably. I'd trust it over a well-designed but new codebase any day.
To rename files in CVS, you remove the old file and add it as a new file. The semantics of this are well-defined, and you will get a consistent view of the tree no matter which version you check out. It's simplistic, but it works. The one thing that is a bit clunky is the fact that old, empty directories hang around, but that really isn't a big deal in practice.
Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.
In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.
Click-through indicates interest on the part of the user. It lets advertisers engage with people who are interested while avoiding annoying potential future customers. Mouse-over does not indicate interest, so it's no better than simply popping up windows randomly, and advertisers can do that already.
If personal aircraft ever become economically viable, you can bet that they will be even more strongly regulated than current aircraft.
I don't think consequences will be quite that serious. Still, it warrants looking into: there is probably some adaptation to compressed audio, and that adaptation may distort the perception of regular sounds.
The real problem is one-sided transparency: if the government has all the knowledge, the government is all powerful: it can use its knowledge for blackmail, for constructing "secret evidence" to be used in trials, etc., and ordinary citizens have no way of fighting that.
Take speed traps as an example. As long as the police does not release detailed information on who gets caught where and when, you can argue until you are blue in the face in front of a judge--if a policeman stands up and says you speeded, you will get convicted. If, on the other hand, all related data is available, you might well be able to prove that the policeman didn't calibrate the radar gun, that they are engaging in selective enforcement, that the speed limit at that location is deliberately too low, that the location is being used for "revenue enhancement", etc.
The Bush administration is one of the most secretive governments we have had in a long time. People like Poindexter don't want transparency, they want a large differential in the amount of information available to the government and corporations vs. the amount of information available to individuals. And they want that as a means of control.
And any design that mixes up the images with the text and thereby risks writing 5-10Mbytes every time you save a document is seriously broken. There are better ways of keeping images and text together than OLE structured storage.
Anything that isn't gushing with enthusiasm over Apple and their technology is modded down. Come on, guys, get over the group-think. Arguing that Apple is not going to be a significant technological player in the decades to come is not the same as "trolling". If you disagree, say why, don't mod people down.
However, there is plenty of other prior art. Many IRC clients have had buddy lists, alerts, ignores, private chats, and other features for a long time. And the MIT Zephyr messaging platform is almost completely equivalent to modern IM systems in capabilities and functionality.
The rules are indeed different for convicted monopolists, or even companies that dominate a market. It's OK for you to release a broken version of XML for your office suite, it's not necessarily OK for Microsoft.
For example, being able to understand the structure of XML documents makes reverse engineering much easier. It also lets you embed one XML document inside another and deals with the resulting namespace issues correctly. And there are many other things that XML helps with--it's not sufficient for a universal format, but it takes care of the nitty-gritty that, if not taken care of, can break portability.
I would dispute that RTF is "portable" or "standard". However, whatever it is, it simply does not seem to preserve appearance and markup sufficiently well to be used as an interchange format. Perhaps it could in theory, but in practice, it doesn't seem to.
As for making it the default, if it isn't the default, it won't work. Not only do most users not understand how to save in other file formats, if it isn't the default, it probably will be too buggy to be used. None of the non-Microsoft formats in Word, PowerPoint, or Excel are really usable for day-to-day use because they lose formatting or worse.
Copyright is a legal issue, not a technical one. The "copyright restrictions" on the content are the same as they always have been.
What appears to be the case is that it doesn't try to put a lot of technical DRM restrictions on the content, and that is nice. DRM generally restricts use of content much further than copyright.
If people acted out more perversions in cyberspace instead of the real world, we'd all be better off.
A TCP-based protocol is exactly the right thing for this application. The only thing they have to watch out for is that they need to increase timeouts and other parameters that have been adjusted downwards in consumer machines for "performance reasons". FTP's use of separate control and data connections also makes it a little more attractive than alternatives.
I doubt authentication was a consideration--FTP is insecure anyway. They probably use firewalls.