Shutting down FTP services (kernel.org) [LWN.net]

FTP vs HTTP

Posted Jan 29, 2017 19:13 UTC (Sun) by epa (subscriber, #39769) [Link] (38 responses)

Yes, I never really understood why people persisted with FTP sites when HTTP does the same job better for read-only access. About the only advantage I can think of is that FTP has the concept of a directory listing, so you can list files programmatically.

FTP vs HTTP

Posted Jan 29, 2017 19:15 UTC (Sun) by johill (subscriber, #25196) [Link] (4 responses)

Well, FTP isn't even really standard (or at least compliant) for listings - might as well try to parse the listings the HTTP servers usually give you ... or just use DAV for that purpose, I guess?

FTP vs HTTP

Posted Jan 29, 2017 19:28 UTC (Sun) by donbarry (guest, #10485) [Link] (3 responses)

I understand it, support it, but there is something wistful that connects with the bygone days when I would ftp in, browse into kernel/v2.0 directory to see whether a new release had come out. (LWN wasn't founded until a year and a half after that branch went live).

I haven't done that in many, many a year, but just to know that one *could*....

FTP vs HTTP

Posted Jan 30, 2017 9:37 UTC (Mon) by joib (subscriber, #8541) [Link] (2 responses)

I'm sure it's possible to create an application that would work more or less like a classical interactive command-line ftp client except it'd use http(s) instead of ftp over the wire. In fact, I'm almost sure such a thing already exists, I just can't come up with the name of it.

FTP vs HTTP

Posted Jan 30, 2017 10:12 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)

I am pretty sure lftp

lftp http://ftp.kernel.org/

Commands like 'ls' function as expected, I considered finding out how and decided I didn't care enough.

FTP vs HTTP

Posted Jan 31, 2017 6:24 UTC (Tue) by nhippi (subscriber, #34640) [Link]

This was pretty awesome to find out. I guess if you are already parsing "ls -al" output, the jump to parse uri's from html is not that big anymore.

FTP vs HTTP

Posted Jan 30, 2017 8:48 UTC (Mon) by Jonno (subscriber, #49613) [Link] (32 responses)

FTP(S) do *not* support machine readable directory listings. All they provide are human readable text files, usually (but not universally) auto-generated by `ls -la` (or equivalent) on the server. Trying to parse those in an ftp client is a pain in the ass, as the format will vary with the FTP daemon version, OS version, locale setting, and administrator options on the server...

HTTP(S) *do* (optionally) support machine readable directory listings (using the WebDAV specification). Of course you can still get human readable files, often (but not universally) auto-generated by the server. As they are typically structured html documents, where each entry is hyper-linked, parsing those reliably are usually *easier* than parsing the text files from FTP(S).

Of course, there not being any alternative to parsing the human readable text files from FTP(S), more developer hours have been put to solving that problem, so it generally works better than parsing the human readable html files from HTTP(S), where the typical response is "You're doing it wrong, use WebDAV!"...

FTP vs HTTP

Posted Jan 30, 2017 9:07 UTC (Mon) by grawity (subscriber, #80596) [Link]

Well, if you allow extensions like WebDAV, then FTP(S) very well does support machine-readable directory listings under the MLST and MLSD commands.

(Admittedly firewalls do sometimes choke on those.)

FTP vs HTTP

Posted Jan 30, 2017 9:18 UTC (Mon) by drag (guest, #31333) [Link] (28 responses)

Outside of a certain class of Microsoft Windows users I don't think I've ever seen anybody actually use "FTPS". There is 'sftp', but that's a completely different beast.

Ftp as a protocol should, at this point, be long dead. It's still nice in a nostalgic way, but that's about it.

Now Email should be dead as well, but unfortunately that is something people still actually use. Oh well.

FTP vs HTTP

Posted Jan 30, 2017 10:08 UTC (Mon) by tao (subscriber, #17563) [Link] (21 responses)

And what, exactly, is the replacement for e-mail that you'd advocate instead? There are plenty of replacements for ftp, but I cannot think of any good substitute for e-mail.

FTP vs HTTP

Posted Jan 30, 2017 10:26 UTC (Mon) by drag (guest, #31333) [Link] (20 responses)

There are a number of instant/secure messaging apps and protocols out there. Probably any one of them would be better then email. Anything that verifies the sender is the actual sender would be better. Email sets the bar pretty low.

If I was to try to create a email replacement tomorrow I'd probably make a jabber extension that supports a intermediate offline receive and store with html formatted messages.

But you are missing the point a bit, I expect. Email not used because of any sort of technical excellence in it's protocol. but due to social reasons. Convincing people to use _anything_ else is the problem.

FTP vs HTTP

Posted Jan 30, 2017 12:46 UTC (Mon) by dskoll (subscriber, #1630) [Link] (15 responses)

The beauty of email is that you can anonymously and quickly dash off an email to someone you've never met, and it's asynchronous... they don't have to read it or answer it right away.

That's also its downfall, of course.

FTP vs HTTP

Posted Jan 30, 2017 13:25 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (7 responses)

Yes, the social expectations of email are vastly different than instant messenger of any form. Usually the sender can see if you are online and (and even for texting) may expect prompt responses. Lack of a response can either invoke a feeling of panic for the recipient or resentment for a perceived shunning.

FTP vs HTTP

Posted Jan 30, 2017 16:54 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

It's like complaining why hasn't the phone replaced snail-mail? They serve very different purposes. If it was going to happen, that should have done so nigh on a century ago!

Cheers,
Wol

FTP vs HTTP

Posted Jan 31, 2017 11:32 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

> It's like complaining why hasn't the phone replaced snail-mail?

That does not resemble anything I said at all.

FTP vs HTTP

Posted Feb 3, 2017 11:31 UTC (Fri) by Tet (guest, #5433) [Link] (1 responses)

It's actually exactly what you said. You're comparing synchronous and asynchronous communication mechanisms. Just like phone and snail mail. Instant messaging will never replace email because they do different things.

FTP vs HTTP

Posted Feb 3, 2017 19:06 UTC (Fri) by raven667 (subscriber, #5198) [Link]

There is certainly a continuum of communication technologies, we could go crazy and say

stone ->
books ->
web pages ->
email ->
IM ->
voice ->
video ->
in-person ->
telepathic?

FTP vs HTTP

Posted Feb 2, 2017 7:40 UTC (Thu) by micka (subscriber, #38720) [Link] (2 responses)

I don't know what the social expectations for IM are _in general_, but most people don't expect me to actually answer quickly. Maybe that's because I inadvertantly groomed everybody like this by disabling notifications (I do have notifications for mail on the other hand) and usually responding between 10 seconds and... very long. Worst case I had was more than 24 hours, being seen as online all this time.

FTP vs HTTP

Posted Feb 2, 2017 9:22 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

One thing that makes a difference is that modern IM services show you a richer set of statuses than just "online", "away", and "offline"; you have a per-message status telling you whether the message is still private to you, has reached the recipient but not been seen yet (is visible in the chat window, but the user has not interacted with the chat window since the message became visible), or has probably been seen (you've opened the chat window with the message in, and interacted with a UI element that's visually below the message, typically), plus usually a "typing" indicator to tell you that the recipient is crafting a response.

Thus, if I'm communicating with someone like you, I can see that the message is available for you to read, but that you haven't yet seen it. I can also see that you've probably seen it, and aren't yet typing a response, and I can see that you've seen it, but that you're crafting the perfect reply and I should wait for you to finish typing before I poke again.

In some situations, that extra information is useful - it reassures me that the lack of a response is not you ignoring me, but you ignoring the machine completely. In others, perhaps not so much - do you want your boss to know that you've seen a message they think is polite and reasonable but that you're ignoring it for 24 hours while you calm down enough to reply nicely?

FTP vs HTTP

Posted Feb 2, 2017 11:03 UTC (Thu) by pabs (subscriber, #43278) [Link]

Personally I would disable that sort of data leakage, ick.

FTP vs HTTP

Posted Jan 31, 2017 11:28 UTC (Tue) by drag (guest, #31333) [Link] (6 responses)

I understand that.

I wasn't claiming that you would replace email with IM. The example I gave was a possible way you could extend jabber to use it for offline messages.

It's not the concept of Email that sucks.. it's the email protocol that sucks. It's insecure, spam is a constant problem and it's a nightmare to manage.

So far the best approach that people have discovered to deal with email is 'Lets all use Gmail and let Google deal with this nonsense'.

FTP vs HTTP

Posted Feb 1, 2017 4:54 UTC (Wed) by Frogging101 (guest, #113180) [Link] (2 responses)

Which is a bad thing because it centralizes email to Google.

FTP vs HTTP

Posted Feb 1, 2017 13:15 UTC (Wed) by hkario (subscriber, #94864) [Link] (1 responses)

all the other protocols centralise IM to some provider too, and unlike for Jabber, Google will need to remain compatible with external providers

FTP vs HTTP

Posted Feb 3, 2017 5:54 UTC (Fri) by marcH (subscriber, #57642) [Link]

Indeed: gmail *does* "deal with all that non-sense" required to communicate with the outside world. All alternatives ignore the problem by simply not talking to each other! We're in 2017 and there's still no open and universal messaging solution that doesn't suck; what a shame.

FTP vs HTTP

Posted Feb 2, 2017 2:47 UTC (Thu) by dskoll (subscriber, #1630) [Link] (2 responses)

I think you'll find that despite email's problems, it's almost certainly the most important communication mechanism in business. I know that in my job, 95% of my communication (other than actual face-to-face interaction) is via email. And I would hate to use any sort of non-email-like tool in its place.

Email for personal communication is (for me) less important. In a pinch, I could get by texting, Facebook messaging, IM, etc. But I still like email the best in many situations.

FTP vs HTTP

Posted Feb 8, 2017 10:39 UTC (Wed) by k8to (guest, #15413) [Link] (1 responses)

Just left a startup where they were using primarily Slack for communication, with email barely ever used.

For discussion-oriented stuff, this worked well, where parties were feeding off each others ideas in relatively tight timescales.

For asynchronous communication that shouldn't be dropped, it was horrifyingly awful. And they were uninterested in changing the pattern. I couldn't understand it at all.

FTP vs HTTP

Posted Feb 8, 2017 14:02 UTC (Wed) by anselm (subscriber, #2796) [Link]

The problem with Slack is that once something has scrolled off the top of the browser window it is very inconvenient to refer to. Sure, you can always scroll back to look at it, but if you want to reply to something somebody said three screenfuls ago it is a hassle to re-establish the proper context.

Some of the open-source Slack competitors (such as Mattermost or Rocketchat) actually do this better, at least to a certain degree.

FTP vs HTTP

Posted Jan 30, 2017 13:30 UTC (Mon) by tao (subscriber, #17563) [Link] (3 responses)

The problem is that the most popular of those instant/secure messaging apps (Whatsapp) is proprietary and locked to phones (there's a web client, but you need your phone running to use it). Skype is proprietary too. I guess you could include Facebook too.

There are free protocols, it is possible to do offline storage, but none of the solutions actually *exist*.

And then there's the whole bit about threaded discussions. How would you possibly handle that?

No thanks. I love chat clients, but they do not replace e-mail. They complement e-mail nicely.

FTP vs HTTP

Posted Jan 31, 2017 11:35 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

I didn't say they didn't have problems.

The first requirement in something replacing email is going to be that it needs to be widespread as email. This is not a technical problem.

> And then there's the whole bit about threaded discussions. How would you possibly handle that?

Email is extremely bad at this.

FTP vs HTTP

Posted Jan 31, 2017 12:11 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

Email is extremely bad at this.

With e-mail this is largely up to the client program one is using. Some of them do a reasonably decent job, and if threaded discussions are important to you you can pick one that does.

On the other hand, with most IM services you get exactly one client program (possibly per platform). If that program decides threaded discussions aren't worth bothering with, then you're stuck with it whether you like that or not.

In a wider sense, in the end e-mail is just files that you can deal with (format, sort, save, forward, print, backup, …) however you wish. IM messages are usually bits of data on a server that you can't access except through the official IM client. I know what I prefer.

FTP vs HTTP

Posted Jan 31, 2017 12:50 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> With e-mail this is largely up to the client program one is using. Some of them do a reasonably decent job, and if threaded discussions are important to you you can pick one that does.

Some clients mangle the relevant headers, breaking threads for everyone. I can stitch them back together in mutt, but unfortunately they don't sync with offlineimap.

FTP vs HTTP

Posted Jan 30, 2017 10:33 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (4 responses)

Offering FTPS is definitely something you tend to see more of in the corporate and Microsoft-friendly world. FTP is a product of a different era, in which we were concerned about things like maybe the machine you're connecting to has a different idea how files work, or maybe file "transfer" is supposed to include transcoding somehow, and probably everybody should have an account with a password on every site... OK, we didn't entirely get away from that craziness yet.

SFTP is often misunderstood as a protocol rather than a sub-protocol of SSH. All the authentication, key exchange and so on happen up in the SSH layer, keeping SFTP itself simpler. There is a reserved port 115 labelled 'SFTP' but that's because a very long time ago there was a Simple File Transfer Protocol, never widely implemented and now obsolete, the SFTP we rely on today will appear as a sub-protocol offered by a SSH server (typically on port 22).

BR ballot 169 - which was intended to standardise domain validation for the Web PKI, but stalled out due to patent wrangling - mentions SFTP and port 115 due to what I have only been able to assume is this misunderstanding. Once the game of musical chairs caused by IPR lawyers stops I may try once again to get people to fix that part.

FTP vs HTTP

Posted Jan 30, 2017 12:02 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

a very long time ago there was a Simple File Transfer Protocol, never widely implemented and now obsolete

Network booting still relies on it.

FTP vs HTTP

Posted Jan 30, 2017 12:12 UTC (Mon) by farnz (subscriber, #17727) [Link]

Most systems I netboot use TFTP on port 69, not SFTP on port 115.

SFTP was meant to be somewhere between TFTP's simplicity and FTP's complexity, and never really took off - it had just enough of FTP's complexity to be challenging to implement if you're resource constrained (TCP, transfer modes, file system manipulation commands), while not being complex enough to be a worthwhile replacement for FTP.

FTP vs HTTP

Posted Jan 30, 2017 12:12 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

That would be the Trivial File Transfer Protocol (TFTP).

FTP vs HTTP

Posted Feb 16, 2017 18:13 UTC (Thu) by nix (subscriber, #2304) [Link]

Oh yes, how stupid of me for mixing the two up, particularly given that I was just dealing with the little monsters a few days before.

FTP vs HTTP

Posted Feb 2, 2017 15:06 UTC (Thu) by diegor (subscriber, #1967) [Link]

The problem is that there is not one ftps but at least two kind of ftps: implicit and explicit. Note that they are not compatible. But what is really incompatible with modern internet world, is that use a secondary connection for data trasfer. So you have to use passive mode, because originally the client should connect to the server on a random port for data trasfert, but firewall usually block incoming connection on unknown port.

Recent firewall can do protocol inspection, for enabling specific dynamic port used by a known ftp session. But what happen if you use ssl with ftp? No more packet inspection :-D.

At work, I had to evaluate the possibility to use ftps for secure file trasfert, and my response was "I've tried, but is too complex, too clumsy. Let's use sftp." And even sftp, server side, was not so easy to setup, configuration was tricky, but much more reliable.

FTP vs HTTP

Posted Jan 30, 2017 10:53 UTC (Mon) by cesarb (subscriber, #6266) [Link] (1 responses)

> All they provide are human readable text files, usually (but not universally) auto-generated by `ls -la` (or equivalent) on the server.

Weren't they actually generated by running /bin/ls -la *within* the ftp server's chroot? As in, every ftp server had within its exported tree a "bin" directory, and within it a "ls" executable in the appropriate architecture, visible to the world?

FTP vs HTTP

Posted Jan 30, 2017 12:17 UTC (Mon) by anselm (subscriber, #2796) [Link]

Old-fashioned FTP servers used to do it that way, back when people didn't worry about security. It was a complete pain in the tuckus to set up.

Modern FTP servers like PureFTPd or vsftpd generate “ls -la” lookalike listings without actually using the system's /bin/ls program, which makes life a lot easier. For example, it is now straightforward to chroot each FTP user into their own home directory, which on the older FTP servers would have meant recreating the environment for /bin/ls (including libraries, devices and /etc/{passwd,group}) for every user.

Shutting down FTP services (kernel.org)

Posted Jan 29, 2017 19:47 UTC (Sun) by welinder (guest, #4699) [Link]

And...

4. Next to nobody is using it anyway.

I hope.

Shutting down FTP services (kernel.org)

Posted Jan 29, 2017 20:04 UTC (Sun) by Sesse (subscriber, #53779) [Link] (4 responses)

I still think it's sad finger.kernel.org went away…

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 14:19 UTC (Mon) by sb (subscriber, #191) [Link] (3 responses)

> I still think it's sad finger.kernel.org went away…

https://www.kernel.org/kdist/finger_banner

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 14:28 UTC (Mon) by Sesse (subscriber, #53779) [Link] (2 responses)

I know, but it's not accessible via finger. It was nice being able to just “finger @finger.kernel.org” from the command line instead of having to reach for a browser (or wget-ing that rather long URL).

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 14:35 UTC (Mon) by mricon (subscriber, #59252) [Link] (1 responses)

alias kfinger='wget -q -O- https://kernel.org/finger_banner'

Shutting down FTP services (kernel.org)

Posted Jan 31, 2017 1:15 UTC (Tue) by welinder (guest, #4699) [Link]

No weasel

also NSIDC is shutting down FTP services

Posted Jan 29, 2017 20:28 UTC (Sun) by tnoo (subscriber, #20427) [Link]

this seems to be a trend

> NASA National Snow and Ice Data Center Distributed Active Archive Center (NSIDC
DAAC) will transition data distribution protocols from FTP to HTTPS on 31 January 2017.

Shutting down FTP services (kernel.org)

Posted Jan 29, 2017 21:17 UTC (Sun) by amacater (subscriber, #790) [Link]

ftp is still useful but I have to say I much prefer anything rsync accessible days and rsync.kernel.org still resolves :)

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 5:45 UTC (Mon) by kloczek (guest, #6391) [Link] (18 responses)

So Linux file systems really so sucks tat FTP must be blamed?
Still none of Linux developers are able to develop something like ZFS ARC?

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 6:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

You mean, caching in Solaris sucks so much that they had to invent a completely separate cache for ZFS? But don't worry, Solaris is dead.

Here it probably means that FTP content can't be cached by CDNs that are globally distributed and are able to survive DDoS attacks or huge loads.

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 9:25 UTC (Mon) by marduk (subscriber, #3831) [Link]

Also browser caching and HTTP caches.

Shutting down FTP services (kernel.org)

Posted Jan 31, 2017 18:35 UTC (Tue) by kloczek (guest, #6391) [Link] (15 responses)

Caching should be as close to slow devices as it is possible.
In most cases VFS caching is ineffective. This observation was one of the fundamental causes of integrating coaching into ZFS.

PS. I see notes that Solaris is dead from almost 20 years and still Solaris is around and it still better than Linux on exactly the same hardware especially if comes to host heavy IO workload.

Shutting down FTP services (kernel.org)

Posted Jan 31, 2017 19:13 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Sure. You'll lose memory twice - once for buffer cache and another time for mapped files. But hey, that's just more profit for SnOracle.

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 3:15 UTC (Wed) by kloczek (guest, #6391) [Link]

Even Linux does not copies memory between VFS and block layer caching. Why Solaris should be doing this?
Did you heard ever about memory mapping?

Shutting down FTP services (kernel.org)

Posted Jan 31, 2017 23:26 UTC (Tue) by flussence (guest, #85566) [Link] (11 responses)

> PS. I see notes that Solaris is dead from almost 20 years and still Solaris is around and it still better than Linux on exactly the same hardware especially if comes to host heavy IO workload.
I'm sure that's great news for the dwindling population enslaved to Oracle's despotic per-core licensing fees for their one remaining relevant software product.

When people want ZFS specifically, they run BSD.

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 3:19 UTC (Wed) by kloczek (guest, #6391) [Link] (7 responses)

What is in *BSD it is not ZFS. It is OpenZFS and it bases on +6 year old ZFS code.
In mean time Solaris ZFS made many steps forward which only part has been reimplemented (basing on general idea) in OpenZFS.
OpenZFS can be used as will with Linux so you do't need to use *BSD.

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 6:49 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

"It is OpenZFS and it bases on +6 year old ZFS code."

Oracle has made Solaris proprietary again including their implementation of ZFS, resulting in many forks. OpenZFS is not a single codebase. It is the name of a umbrella project of the different forks with feature flags to maintain compatibility.

Shutting down FTP services (kernel.org)

Posted Feb 2, 2017 18:38 UTC (Thu) by kloczek (guest, #6391) [Link] (2 responses)

And that is make using OpenZFS a bit messy. Isn't it?

Shutting down FTP services (kernel.org)

Posted Feb 2, 2017 19:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> And that is make using OpenZFS a bit messy. Isn't it?

That is the price of Free and open source software. People make branches and push code forward.

Shutting down FTP services (kernel.org)

Posted Feb 3, 2017 0:06 UTC (Fri) by jschrod (subscriber, #1646) [Link]

> And that is make using OpenZFS a bit messy. Isn't it?

Maybe. But for sure it's one of the reason our clients cite for not trusting Oracle and why they migrate everything away from Solaris as fast as possible.

Cheers, Joachim
(CEO of a company who earns money from customers who want Solaris => Linux migrations)

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 11:01 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

> In mean time Solaris ZFS made many steps forward which only part has been reimplemented (basing on general idea) in OpenZFS.

My understanding is that the reverse is also true. And because OpenZFS is still copyleft, Oracle can't use them (unless the copyright maximalist wants to get embroiled in a case aiming the other way).

Shutting down FTP services (kernel.org)

Posted Feb 2, 2017 18:39 UTC (Thu) by kloczek (guest, #6391) [Link] (1 responses)

OK, please make a list of things which Oracle may want to incorporate in Solaris code.

Shutting down FTP services (kernel.org)

Posted Feb 3, 2017 23:19 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I don't use ZFS (though I might on FreeBSD if I ever get time), but I'd imagine anything on this page[1] would be useful. I have no idea if it is a complete list and I really couldn't care what Oracle does because I try to avoid things they've got an undue influence in, but if they did want anything the community implemented, they shut themselves out of that party of their own accord.

[1]http://www.open-zfs.org/wiki/Features

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 3:30 UTC (Wed) by kloczek (guest, #6391) [Link] (2 responses)

> I'm sure that's great news for the dwindling population enslaved to Oracle's despotic per-core licensing fees for their one remaining relevant software product.

1) you don't need to buy Solaris support if you don't need it. It is exactly the same as with Linux.
2) per core licensing is not in case Solaris but Oracle DB engine. Solaris support is per CPU *socket* (first level is for 1 to 4 sockets and next is for +5)
https://shop.oracle.com/apex/product?p1=OracleSolarisPrem...
3) please compare support costs in case RHEL and Solaris on the same hardware.

Shutting down FTP services (kernel.org)

Posted Feb 1, 2017 6:37 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> 1) you don't need to buy Solaris support if you don't need it. It is exactly the same as with Linux.

Nope. You have to agree to the following license to even download the software.

Oracle Technology Network Developer License Terms

"We grant you a perpetual (unless terminated as provided in this agreement), nonexclusive, nontransferable, limited License to use the Programs only for the purpose of developing, testing, prototyping and demonstrating your applications, and not for any other purpose. "

Shutting down FTP services (kernel.org)

Posted Feb 3, 2017 19:04 UTC (Fri) by flussence (guest, #85566) [Link]

I never said *Solaris* was the relevant product. It's not.

Shutting down FTP services (kernel.org)

Posted Feb 16, 2017 18:17 UTC (Thu) by nix (subscriber, #2304) [Link]

In most cases VFS caching is ineffective. This observation was one of the fundamental causes of integrating coaching into ZFS.

Well, that says rather bad things about the Solaris VFS cache, then, because the Linux VFS cache is exceedingly effective. Throw enough RAM on a box and you'll never access the disk at all except to populate the cache for the first time and flush writes out. (In the case of RAID, the writes might incur WMR reads, as well, though.)

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 12:05 UTC (Mon) by zoobab (guest, #9945) [Link] (5 responses)

Any equivalent to lftp mirror?

I mean this is one command on lftp to mirror a directory.

I hate HTTP, I don't understand why kernel.org wants to get rid of FTP.

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 12:36 UTC (Mon) by paravoid (subscriber, #32869) [Link]

Sure! "lftp mirror" is your replacement. Works fine with HTTP(S) URLs:

$ lftp https://www.kernel.org/pub/
cd ok, cwd=/pub
lftp www.kernel.org:/pub> ls
drwxr-xr-x -- /
drwxr-xr-x - 2011-12-01 19:56 dist
drwxr-xr-x - 2014-11-11 21:50 linux
drwxr-xr-x - 2008-09-23 23:35 media
drwxr-xr-x - 2013-08-03 04:00 scm
drwxr-xr-x - 2013-08-09 17:23 site
drwxr-xr-x - 2011-11-27 17:31 software
drwxr-xr-x - 2008-04-30 22:31 tools

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 12:36 UTC (Mon) by ovitters (guest, #27950) [Link]

The reasoning has been explained. Instead of saying "I don't understand" please explain what is unclear. Else it seems that you just didn't bother to read.

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 12:53 UTC (Mon) by mbunkus (subscriber, #87248) [Link]

lftp's mirror functionality has already been mentioned. wget can mirror, too:

> wget --mirror --no-parent url…

The "--no-parent" prevents wget from going to URLs that are upwards from the start URL (e.g. it won't try to download https://www.kernel.org/ if your start URL is https://www.kernel.org/somewhere/). This is especially important if the site to mirror has links to its home page (even indirectly); otherwise you'd suck the whole site down.

Shutting down FTP services (kernel.org)

Posted Jan 30, 2017 14:10 UTC (Mon) by mricon (subscriber, #59252) [Link] (1 responses)

Use rsync for mirroring.

rsync rulez

Posted Feb 3, 2017 6:09 UTC (Fri) by marcH (subscriber, #57642) [Link]

Use rsync for everything; it's that good.

This is rsync's only issue: http://qdosmsq.dunbar-it.co.uk/blog/2013/02/rsync-to-slas...
(I suspect this trailing slash confusion exists to make rsync idempotent:
http://unix.stackexchange.com/questions/228597/how-to-cop... )