FTP Is 40 Years Old 253
An anonymous reader writes "FTP celebrates its 40th birthday tomorrow. Originally launched as the RFC 114 specification, which was published on 16 April 1971, FTP is arguably even more important today than when it was born. Frank Kenney, vice president of global strategy for US managed file transfer company Ipswitch, said that the protocol we know as FTP today is 'a far cry from when Abhay Bushan, a student at MIT, wrote the original specifications for FTP.' According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.'"
Oh please (Score:5, Interesting)
FTP is a hideous protocol. The client connects to the server with one TCP connection, and then when a file (or directory listing) is requested, the server opens up another TCP connection back to the client. This is a nightmare for firewalls. There is also passive mode where the client initiates the second connection to the server, but it is only slightly less hideous.
As awful as HTTP is, it is infinitely better than FTP. Sadly HTTP is mostly one way, but these days for anything that isn't being broadcast to the public (the web), you are betterm off using ssh/scp.
Let FTP die already.
mod parent up (Score:2, Insightful)
Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.
Re:mod parent up (Score:4, Informative)
I agree (though if you are going to consider sftp, please also consider ftps), but it has been surprisingly durable. Rivals, historically, have included fsp, scp, rsync, uucp, WAIS, gopher and ftpmail. Some, like WAIS and gopher, also provided a far superior interface to the traditional FTP client.
Of these, scp and rsync are the only ones still in use today and I don't know of any anonymous FTP sites that provides scp, though I think kernel.org provides rsync.
About the only significant change to FTP since it began was that people used to use archie to find programs. (Archie, for those too young to remember, was a search engine specifically for anonymous FTP sites. You gave it a regexp, it gave you every site that had files that matched and the full directory path of those files. Because it was specialized, there was no risk of clutter. Equally, there was no chance it would survive into the era of web crawlers and generalized search engines.
Re: (Score:2, Funny)
I agree (though if you are going to consider sftp, please also consider ftps), but it has been surprisingly durable. Rivals, historically, have included fsp, scp, rsync, uucp, WAIS, gopher and ftpmail. Some, like WAIS and gopher, also provided a far superior interface to the traditional FTP client.
Of these, scp and rsync are the only ones still in use today and I don't know of any anonymous FTP sites that provides scp, though I think kernel.org provides rsync.
About the only significant change to FTP since it began was that people used to use archie to find programs. (Archie, for those too young to remember, was a search engine specifically for anonymous FTP sites. You gave it a regexp, it gave you every site that had files that matched and the full directory path of those files. Because it was specialized, there was no risk of clutter. Equally, there was no chance it would survive into the era of web crawlers and generalized search engines.
) . . . . . . whew!
Re:mod parent up -NOT FTPS (Score:3)
Re: (Score:3)
scp doesn't distract people with popups, doesn't eat resources, tends to be more stable, doesn't require a GUI interface, won't allow people to get distracted with porn and/or Cowboy Neil (or, indeed, porn of Cowboy Neil), is far friendlier to network resources than HTTP (HTTP is =HORRIBLE= for file transfers), and prevents people listening in to what you download.
From a security standpoint, very few FTP sites provide signatures, FTP and HTTP can suffer mitm attacks (all it takes is a trojaned machine anywh
Re: (Score:3)
I find your assertation that HTTP servers have to maintain more state and are heavier than scp servers insane.
Do you actually know how either of those protocols work? HTTP servers don't maintain ANY state, at all. The protocol is literally: Open a TCP connection, send a single line with a file path, send a newline, get some headers, a newline, and the file. That's it. A full featured HTTP server can be implemented with a 15 line shell script run from inetd.
It is much lighter weight than scp could ever dre
Re: (Score:3)
Quote FTFA "Join us in a toast to FTP - at 40 years of age, it’s lasted well and looks like it will remain a relevant technology for years to come."
That is like saying we should still be driving the Model T and expect it to still be around.
Re: (Score:2)
Whilst I don't own a Model T or a car from 1971, I would personally prefer any of the cars from the Brighton Rally anyway. Much classier.
Re:mod parent up (Score:4, Funny)
You expect me to hire a portrait-man? I adjust my monocle and twirl my mustache in indignation, you son of a loose woman!
Re: (Score:2)
Compared to other cars of that vintage, it was. Ford sold mass-produced cars that were stocked high and sold cheap. The Fry's or Walmart of the car industry. They were popular because people could afford them, not because they worked well.
Re: (Score:2)
Re: (Score:2)
Is there any tech still in widespread use that is that old or older?
How about uucp?
Re: (Score:2)
Not sure UUCP is in common use. The initial specs for Telnet appear in RFC 97 and are dated 15 February 1971. I think that if we're considering modern FTP to be a continuation of the original FTP, then modern Telnet is a continuation of RFC 97. I think that's the oldest protocol. ICMP is often considered IPv0, so that might be older still, but Telnet has FTP beat.
Re: (Score:2)
How about the fact that you need to use hideous hackery to make it work through firewalls, it can be used to proxy connections to hide your identity, etc.
FTP is well past its use by date and more secure, easily deployed alternatives exist (SCP, etc).
FTP needs to die.
Re: (Score:2)
For files where you don't care about security, like say plopping some Linux ISOs on a server somewhere then FTP is as good as any.
No. For servers where you don't care about security, FTP will transfer files. Given that the cost is sending your password en clair it's just not worth it.
Re:Oh please (Score:4, Informative)
FTP is evil for simple firewalls but most advanced firewalls can rewrite the control commands or read them to open the right ports.
SFTP is something totally different, but since it uses a tunnel it isn't that bad for firewalls.
FTPS is the a nightmare! It has the random port problems of FTP but also encrypts the commands so there is no way for the firewall to figure out what ports will be used.
Re: (Score:2)
Huh? I use FTPS all the time with Filezilla server and connect with a variety of FTPS clients and never have issues. This is through a variety of firewalls- expensive cisco's and sonicwalls and cheapo netgears and linksys.
Both FTP and FTPS require passive mode to work properly and a passive range forwarded. That's it. Once configured correctly on the server-side there's nothing else to do.
Honestly, it scares me that vanilla FTP is so widely used and the defacto way to transfers files for so many services.
Re: (Score:2)
Honestly, it scares me that vanilla FTP is so widely used and the defacto way to transfers files for so many services. Its completely unencrypted.
Er, not everything needs to be encrypted. Having it as an option is great, but for non-sensitive data (e.g., source code that I'm already making available to the world) I'll take the protocol with the lower overhead.
Re: (Score:2)
Your password is usually pretty sensitive data.
Re: (Score:2)
Re: (Score:2)
Yes, many things can be left unencrypted; your password is not one of them. Using FTP for anything other anonymous FTP is irresponsible and stupid.
Eh, there are ways to do it that are reasonable in terms of risk. For example, one-time passwords.
I wouldn't recommend it, but to dismiss it outright for that reason isn't correct.
(Disclaimer: As a former firewall administrator in a scientific computing facility, I hate FTP.)
Re: (Score:2)
"Having it as an option is great, but for non-sensitive data (e.g., source code that I'm already making available to the world) I'll take the protocol with the lower overhead."
I would do that too.
But to me, the lower overhead doesn't come from FTP but from SCP. It's just like Telnet.
More and more, the expensive part of the equation is the labour hours; since FTP is more or less the same than SCP (or SSH the same as Telnet), I prefer knowing and using one tool better than two.
Re: (Score:2)
When talking about FTP its not far removed from running a transparent http proxy. Thats used all over the place.
Re: (Score:2, Insightful)
Defense in depth in all but really Firewalls suck, and break the Internet. Its not FTP that is broken its systems that need firewalling that are. That said there is no operating system in common use, Linux included, that should not be behind a firewall, at the very least a local software based one.
The control channel being on a separate socket from the data channel allows FTP to do things like XFTP where a client can broker a transfer between servers without needing to participate in it.
Re: (Score:2)
Which is a hideously broken idea that is abused by spammers, etc the world over.
Re: (Score:3)
That anology doesn't quite work though. Modern OS's and applications don't leave the door open. The problem is that they are complex enough that there are always places where unintended interactions will happen, and those interactions can be exploited by malicious code or users. In essence, it's akin to find a weak spot in the wall of your house and drilling an entrance hole. So I think the grandparent's po
Re: (Score:2)
Re: (Score:2)
Active mode FTP is hideous where NAT is involved, because it requires the server to initiate an active connection to the client.
Sadly, passive mode is horrible because it uses ephemeral ports on both ends, so you have no way to easily allow ftp and nothing else.
This leaves you in the situation of absolutely requiring an ftp proxy, because you only allow active mode on site, but passive mode is needed to get off site...
FTP is a nightmare. It has only remained because A) no command line HTTP file transfer c
Re:Oh please (Score:5, Informative)
no command line HTTP file transfer clients ever sprang up
Let me introduce you to wget [gnu.org] and curl [curl.haxx.se].
Re: (Score:2)
no command line HTTP file transfer clients ever sprang up
Let me introduce you to wget [gnu.org] and curl [curl.haxx.se].
"sprang up" is the key phase
Okay, introduce wget or curl to a website of ill-repute.
Re: (Score:2)
FTP is a nightmare. It has only remained because A) no command line HTTP file transfer clients ever sprang up, and B) The OpenSSH folks didn't allow you to choose unencrypted data connections for "anonymous" and non sensitive data. Either of the two would blow FTP out of the water so fast it would make your head spin. FTP is just that horrible.
Why does OpenSSH need an unencrypted option (for sFTP?) to make it popular? What advantage is there to having unencrypted file transfers?
I don't think I've ever owned a PC that couldn't encrypt/decrypt at the speed of my WAN connection, and my fastest LAN transfer uses less than 15% of my CPU.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Lots of people grousing about how awful FTP is. I bet not one of you will ever write a piece of software that is still hugely popular and under active development 40 years later.
Except, FTP isn't a piece of software. It's a Protocol. As far as I can tell from a cursory search, no particular FTP daemon is still in wide use that was written 40 years ago.
Re: (Score:2)
Lots of people grousing about how awful FTP is. I bet not one of you will ever write a piece of software that is still hugely popular and under active development 40 years later.
By "piece of software" I think you mean "communications protocol", and I take exception to your statement.
Sincerely,
Arthur C. W. Aldis
P.S. Yes, I am 200 years old, and I know how to use a web browser.
Re: (Score:2)
Except it was designed back before people had firewalls, or had even thought about firewalls. It's easy to criticize something in hindsight (why'd the make the first wheel out of stone, that's stupid).
Re: (Score:2)
Re: (Score:2)
Sadly HTTP is mostly one way
WTF are you talking about? HTTP requires an inbound connection from the client to the server, and the session is always controlled by the client, but the data can flow as strongly as desired in either direction. I routinely use an HTTPS-based file transfer tool that I wrote some 10 years ago to transfer files of any size, well into the GBs from the client to the server. (it's called POST and isn't particularly tough to do)
Simple. Secure. Reliable. Why does SFTP have to be such a pain in the neck to do right
Re: (Score:2)
Sadly HTTP is mostly one way
WTF are you talking about? HTTP requires an inbound connection from the client to the server, and the session is always controlled by the client, but the data can flow as strongly as desired in either direction. I routinely use an HTTPS-based file transfer tool that I wrote some 10 years ago to transfer files of any size, well into the GBs from the client to the server. (it's called POST and isn't particularly tough to do)
I think that's the problem - you use a tool that you wrote. Whenever that tool is available pretty much out of the box for nearly every operating system out there, then HTTP will replace FTP for file transfers.
Re: (Score:2)
Sadly HTTP is mostly one way
WTF are you talking about? HTTP requires an inbound connection from the client to the server, and the session is always controlled by the client, but the data can flow as strongly as desired in either direction. I routinely use an HTTPS-based file transfer tool that I wrote some 10 years ago to transfer files of any size, well into the GBs from the client to the server. (it's called POST and isn't particularly tough to do)
I think that's the problem - you use a tool that you wrote. Whenever that tool is available pretty much out of the box for nearly every operating system out there, then HTTP will replace FTP for file transfers.
I know a lot of architectural practices who operate FTP servers so they can access files remotely. They could use something like WebDAV instead. I think it is just momentum which ties them to old protocols.
Re: (Score:3)
I have to agree. For non-authenticated transfers, HTTP and rsync are better, for authenticated transfers, sftp/scp is better.
Fortunately at work virtually all the companies we deal with now use scp/sftp instead of ftp.
Re: (Score:2)
The issue there is that passive mode works, unless the server is behind a firewall. Which it should be, if you're only serving up files and web pages, there's absolutely no good reason to have any more ports open than you absolutely need to, and having extra ports open is just plain silly. And since FTP mandates that those ports be randomly assigned there's no good way of knowing which ports are going to be used.
Re: (Score:2, Insightful)
Using a firewall to close ports is the most ridiculous thing ever.
Just tell the bloody program that opened the port not to open it!
If you actually do that, the firewall isn't needed because you actually have a clue and configured the system correctly.
Re: (Score:2)
Re: (Score:2)
Next time, read the post you are replying to to the end before wielding your keyboard in anger.
Re: (Score:2)
Next time, please check your facts.
Funny, for someone who just got his facts wrong about how passive mode works. There are still two TCP connections in passive mode. Essentially, it's just flipping the listener on the data connection from the client to the server.
Re: (Score:2)
Its still brain damaged because it embeds the IP address into the protocol itself, thus breaking horribly through nat without deep packet inspection and various "fixup" bullshit that your firewall needs to do.
Again, better, free, easily configured alternatives are available, and have been for at least 15-20 years. Let FTP die. It may have been all good in the hippy free-love era of the early internet, but in the commercial, dog eat dog, spammer infested world we live in today, it has well outlived its
The cloud? (Score:5, Insightful)
Re:The cloud? (Score:5, Funny)
Of course we do. It's imperative in today's business environment to deploy file transfer protocols based on integrated models that work in the cloud with compliance. Just imagine what FTP was like before it had compliance in the cloud. I don't get how anyone got anything done.
Re: (Score:2)
Re: (Score:3)
No points. I spent mine modding up the first posts.
Re: (Score:2)
I don't get how anyone got anything done.
I'm not cognizant of how team members brought elements to completion under that scenario. FTFY.
Re: (Score:2)
Well let's see.. the guy who said it is...
Ah well there you are. He's a VP. So yes, I believe he really does need to bring buzzwords into everything. He's probably contractually obligated to.
...and it shows (Score:2)
I'd instead say "and in internet years, that's about 400 years, and it shows. retire the poor thing already!" It's a royal pain for firewalls and it sends text in the clear. Move into the 21st century and use scp...
Happy birthday FTP (Score:5, Funny)
Now die!
Re: (Score:2)
Re: (Score:2)
But almost nobody sends files via http. Way too primitive. FTP is still king there, followed by torrent.
Re: (Score:2)
Rapidshare, megaupload, oron, upload.me, depositfiles, and many others would disagree with you. FTP is not king of the file transfer world. How many times recently have you used it compared to downloading an update usually via a HTTP connection from some updateserver somewhere?
I have used FTP exclusively for connecting to a web server and putting files on there. I do that maybe once every 2 months. Now at 100 hits per day average I wonder... how much of my website gets transferred via FTP compared to HTTP?
Re: (Score:2)
How often do you download Firefox? In all fairness to other vendors, I think we should know so the figures can be adjusted.
Re: (Score:2)
Don't mind me, just karma-whoring: http://mywiki.wooledge.org/FtpMustDie [wooledge.org]
Re:Happy birthday FTP must die... (Score:3)
The effects of middle-age software ... (Score:3)
When software gets to be around 40 years of age, wrinkles that were once minor are more and more apparent, what was once new and exciting isn't so much anymore, and it gets rather set in its ways and resistant to change. Decisions made in its youth often become a cause of later regret, and there's a certain amount of jealously of those who are now doing the same job it once did but in a snazzier way.
But at the same time, it's likely to be far more established and dependable than its younger counterparts. You can count on it getting the job done, one way or another. It won't be flashy, but it will work.
Re: (Score:2)
"But at the same time, it's likely to be far more established and dependable than its younger counterparts. You can count on it getting the job done, one way or another. It won't be flashy, but it will work.
"
That's what she said.
Re: (Score:2)
But at the same time, it's likely to be far more established and dependable than its younger counterparts
But I thought we were talking about FTP?
Re: (Score:2)
First thing I did on the wife's Android phone was install an FTP client/server. Why not?
Biased much? (Score:5, Insightful)
Asking the vice president of global strategy of a company built around its FTP client to comment on the relevance of FTP is a bit like asking an Adobe marketing executive about the importance of Flash, no?
Re: (Score:3)
It's biased, yes. But that doesn't necessarily mean "wrong" or "without value."
If somebody can build a business around FTP, I think that's a testament to its relevancy right there. And who better to comment on it than somebody who deals with it and clients who use it every day?
I wouldn't ask the guy if his product is the best on the market, but as a comment on the underlying protocols... why not?
Re: (Score:3)
Anyone can build a business around any concept, regardless of value or worth. Success isn't necessarily a testament to the value of the product or its constituent elements. This is a good example of that.
Re: (Score:3)
Kenny Should Learn History (Score:4, Informative)
According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.
Actually, FTP predates TCP by 10 years and 679 RFCs. Hint: TCP is defined in RFC 793.
Re:Kenny Should Learn History (Score:5, Informative)
Re: (Score:2)
Which is why we should scrap TCP and UDP, using SCTP and DCCP instead.
Re: (Score:3)
Actually, TCP was first defined as an RFC in RFC 675 [ietf.org]...
Still, 10 years or 3 years, as you say FTP was clearly not originally specified to work over TCP...
come on (Score:3)
IHFTP (Score:2)
IHFTP
Why all the hate? (Score:2)
Re: (Score:2)
every OS has an FTP client built-in
Um, no. Not anymore. The ftp server went several years ago, and the ftp client has started disappearing too.
tftp is still alive, but that's a different type of beast.
ftp, on the other hand, is now on life support and will presumably and hopefully die before uucp does.
RIP (Score:4, Funny)
FTP died in 1993, murdered by httpd and the Mosaic browser. I watched it die. I shed no tears.
Nothing against FTP, (Score:3)
but I need to say SFTP is the only option in today's world of HIPAA and net neutrality. FTP-SSL, still, is just another layer over the already ubiquitous FTP.
Yes, SFTP is yet another wrapper against FTP, but it is much more secure compared to FTP over SSL. SSL only offers limited encryption options. SFTP, on the other hand, can encrypt data flowing over public keys with encryption streams 1024-bit or higher.
Re:Nothing against FTP, (Score:5, Informative)
SFTP [wikipedia.org] has nothing to do with FTP, nor is it a wrapper. It is based on SSH, not FTP.
The wrong FTP (Score:2, Informative)
The FTP we know today originated in RFC 765, published June 1980, and was designed to work over TCP. RFC 114 defines a completely different protocol for file transfer that has nothing to do with FTP.
Exactly one advantage to FTP - FXP (Score:5, Interesting)
The only nonsucky thing about FTP is that you can use FXP [wikipedia.org] to transfer files between two remote servers without piping it through your client. For example, suppose you have FTP logins on two servers and each has a nice, fast Internet connection. You are on dialup and need to copy database backups from one server to the other. You can use FTP to tell the first to upload to the second's IP address, and tell the second to recv a file from the first's IP address. Nothing but the status messages go through your poor local modem.
You can do the same with by ssh'ing to the first server and scp'ing a file from it to the second, but that requires generating keypairs and copying the public keys around. If you're nitpicky about having separate keypairs on each SSH client machines (and you really should be!), and you have 20 hosts, then you'd have to copy 19 public keys to each machine. With FTP+FXP, you need an FTP login on each of the hosts. That's especially nice if the sending server is a public repository where you don't have anything but anonymous FTP access.
This isn't exactly a killer feature for most people, but it's kind of slick if you ever actually need it.
Re: (Score:2)
Re: (Score:2)
Or send fairly difficult to trace spam, etc.
Its a theoretical advantage that has a work around for that one time in a thousand that you need that functionality, for the cost of a commonly abused security issue.
Re: (Score:2)
Check out SSH Agent Forwarding some time.
Re: (Score:3)
This is nonsensical.
A) You should have ONE ssh key, which is password-protected.
B) You start ssh-agent, ssh-add your key, and use agent forwarding (enabled by default). You can now jump around between any and all SSH/SFTP servers freely.
You only feel
Re: (Score:3)
I dunno man, I kind of like being to re-start aborted transfers, too. I wish the W3C would tack that onto HTTP.
Re: (Score:2)
Not everything has to be secure. Maybe it's an Ubuntu ISO. Maybe it's a GPG-encrypted file. And as I pointed out, maybe you're downloading some from a public server where you have no privileges beyond a plain ol' anonymous FTP account.
Yes, scp is nicer than FTP - if you can use it. That's not always true, and it's not always even an advantage.
It's the lowest common denominator (Score:3)
As recently as 5 years ago, I set up an FTP server for use by a number of financial firms to send orders into a specialized stock trading system
$100M worth of orders were FTPed into that system using PGP encrypted text files (with public key fingerprints verified via telephone to make sure that all of the keys were valid). IP filtering was used to give a small additional layer of security.
This system was set up in a short period of time (3 weeks from inception including writing the file spec and setting up the servers) and FTP was the one thing that all parties could count on having (client operating systems included Windows, various flavors of Unix, IBM VM, and I think one customer had Tandem Nonstop). Pushing files via HTTP PUT is possible, but it's a lot easier to script an FTP file transfer.
One advantage? (Score:2)
Hmmm (Score:2)
Slow new day?
Still beats the hell out of bittorrent (Score:2)
With ftp I can download whole folders with boatloads of files and more folders, and the rest my network stay up just fine. Transfer speeds are top notch. It lets other traffic through.. Bittorrent? I might put it on when I crash for the night.
ftp through a nice private tunnel.. hasn't failed me yet..
security (Score:2)
FTP ... provides ... security ...
I viewed the conversation on this topic mostly to see the revulsion at that series of words. There isn't enough. I would be pissed to see that statement anywhere, and probably mention something about fact-checking. It's on the front page of slashdot. There's no way timothy didn't look at it, recognize that it is a bald faced lie and that everyone here would know it, and endorse it anyway. What the hell?
FTP hasn't evolved. It's been replaced. As others have pointed out, there's https for the masses, a
Re: (Score:2)
https only works one way and doesn't offer authentication of any kind really.. it's just http wrapped in SSL. .torrent files be sent to the user before he can download.. it distributes load, yes, but it's not meant to let someone grab some files from a host somewhere.
scp/sftp is beyond the average GUI user.
torrent requires that
ftps is as secure as any other secure socket connection assuming it was implemented well. badly implemented ssl is not restricted to ftps.
The three "generations" of FTP (Score:5, Informative)
Here's a little more background on the various generations of the FTP protocol.
First Generation (1971-1980)
The original specification for FTP (RFC 114) was published in 1971 by Abhay Bhushan of MIT. This standard introduced down many concepts and conventions that survive to this day including: ASCII vs. "binary" transfers, Username authentication (passwords were "elaborate" and "not suggested" at this stage) , "Retrieve", "Store", "Append", "Delete" and "Rename" commands, Partial and resumable file transfer , A protocol "designed to be extendable", Two separate channels: one for "control information", the other for "data", and Unresolved character translation and blocking factor issues
Second Generation (1980-1997)
The second generation of FTP (RFC 765) was rolled out in 1980 by Jon Postel of ITI. This standard retired RFC 114 and introduced more concepts and conventions that survive to this day, including: A formal architecture for separate client/server functions and two separate channels, Site-to-site transfers, Passive (a.k.a. "firewall friendly") transfer mode and The 3-digits-followed-by-text command response convention. ...and RFC 765 was replaced by RFC 959 (which formalized directory navigation) in 1985.
Third Generation (1997-current)
The third and current generation of FTP was a reaction to two technologies that RFC 959 did not address: SSL/TLS and IPv6.
Most FTP software now conforms to RFC 2228 for FTPS. Oddly enough, there are still a LOT of file transfer packages that still don't have IPv6 or EPSV support. The RFCs beyond IPv6 and EPSV support are pretty well baked, so if you're still dealing with a vendor without those attributes, consider that a big red flag.
Also keep an eye on draft-ietf-ftpext2-hash and draft-peterson-streamlined-ftp-command-extensions - that's where the action is in FTP today.
FTP? Bah! (Score:2)
sendfile forever!
FTP and security in the same sentence (Score:3)
That just made me rofl
Re: (Score:2)
it's time to send ftp to where gopher is
Only if we can bring back Archie, Veronica, and WAIS.
Re:Too bad (Score:4, Informative)
that the grand FTP sites like Walnut Creek didn't last this long. RIP cdrom.com, RIP gamehead, RIP happypuppy, RIP filefactory, RIP gamesdomain, and RIP sunet.se
n00b.
RIP wsmr-simtel20.army.mil
Re: (Score:2)
Yes please any good tips here guys? I'm a CLI n00b but I need to connect to servers a lot doing web design. There must be a better wayyyyy.
There's no reason why you *have* to use a CLI to use FTP. Try Filezilla - it will do FTP, SFTP and FTPS.