Because SFTP doesn't have an un-authenticated connection mode like HTTP does, or a standard "fake" credentials set like FTP has.
No. It's meant for doing secure transfers, that's what you should use it for, if you don't want a secure transfer you use a different protocol, which is how it should be.
DNS can't support LFS tyep sizes, you would actually need to change the protocol. HTTP on the other hand has worked fine with LFS for a _long_ time, just not if you are using apache-httpd.
Ok, so it's something apache should support. But it's not something to get excited about, because you shouldn't ever be using it.
Caching proxies, esp. helpful at large organisations where many people will be requesting the same data
True, and working in exactly the same way for FTP.
proxies... often it's the _only_ way out of the network (well you can somtimes do FTP over HTTP).
Would you then say that http should support e.g. video straming?
indeed you could easily do the HTTP by hand, this is _much_ harder with FTP
Huh? Is it not just a question of knowing the commands for either?
If anything is more "suitable" for large transfers it'd probably be bittorrent, not FTP... but even then bittorrent has one plus but fails most of the above
The point is there are various protocols designed especially for transferring files, and they are (or at least should be, I'll admit FTP has a lot of things wrong with it) better at it than http which seems to be pretty much a general-purpose protocol these days.
One option, quite possibly.... an option that I have access to setting behind a corporate firewall?
It should be how it's set up, though I appreciate it may not be.
They may be "fringe cases," but there are valid uses for transmitting files over HTTP.
Of course there are - there are always cases where you don't have any other choice. Being able to transfer more than 2gb over http is a nice option to have for emergencies, sure - but it shouldn't be something you ever plan on having to use.
Another possibility where it may be desired is transmitting confidential data over HTTPS. While I admit that 2GB is a lot of data and there are probably more efficient was to transmit that much data securely (such as a good old-fashioned courier) that doesn't mean people won't try it:).
Why not use sftp, which is specifically designed for doing just that?
I'm not sure which motherboards you're using, but the ones I buy commonly have 3 or 4 RAM slots.
Mine always used to, but when I went to buy my latest machine I could not find a "desktop"-oriented one with more than 2 slots. I'm not happy about it, but it was that or nothing.
Are you saying that because we (probably) won't need 64-bit processors on the desktop for a few short years, we shouldn't bother preparing for them now? That's just plain short-sighted. Take a look at the history of computers and you'll see that every time somebody has made a claim like that, it's been a mistake.
By all means prepare for them. But to say we need to move to 64 bits is at least premature.
This tells your FTP client to connect to 172.17.2.1 on port 33005. This port is entirely random.
Can you not use PORT to change it if it's unsuitable?
So even passive FTP is not guarenteed to work in a NAT/Firewalled environment if outgoing traffic is port filtered (which isn't uncommon).
Point, yes, if you're filtering outgoing stuff you need to track FTP connections. But that's just a question of enabling one option in every decent firewall I've seen.
I use it every day and have never needed to transfer a file bigger than a few hundred k. Heck, I think I have a space limit of 250mb. And I'd use sftp instead if I wanted to transfer a file bigger than one or two meg.
True, but it's a bit lazy for the program to want to just map all the files into memory. We solved that problem in text editors back in the day. Sure, more memory is always nice, but I don't think there's a real need for that much.
I understood that the encryption used a key, and the break consisted of finding a way to decrypt it without the key (but requiring a bit more cpu power). With a well designed encryption algorithm this would of course be impossible, but that is not a description which applies to CSS.
Nope. Dead wrong there. Using something for what it isn't designed for will always give you more risk overall.
When was the last time you downloaded a file from a DNS server?
When the story about how to transfer files over DNS hit this site. It's somewhat cool, but not really a good idea.
Sure, RAM. 3D work, CAD, video. What are you saying, 4gb should be enough for anyone?:)
I almost am. I'll certainly say that normal desktops don't seem likely to come anywhere near breaking 4gb for at least a few years - most motherboards sold today only have 2 or even 1 memory slot, and I've yet to see even a 2gb dimm, yet alone more. There are certainly areas where you need 64-bit, but I don't think we need it on the desktop, at least for a few years.
Yes, it's reasonably efficient, but it's far better to use a protocol designed for doing stuff like that, such as FTP as he mentioned. Use the right tool for the right job.
And who the hell would want to run a server from behind a firewall? What a ridiculous idea.
There's no reason to be doing that outside a large (corporate or similar) network setting, and in that case you should know what you're doing.
I see you've never configured a firewall then.
It'll be one extra line/tickbox at most in any firewall worth its salt.
He gave some perfectly valid reasons for wanting LFS - WebDAV for one. You ignored them, probably because you didn't understand them. And then you called him an idiot.
I made no special reference to webdav because it changes nothing. Using webdav to transfer files that big is just as idiotic, for just the same reasons.
AIUI the encryption was broken because it's quite simple, but the breaking process still requires effort, and takes more CPU than decrypting the dvd the "corect" way.
For those of you saying you don't need to transfer >2GB it reminds me of comments like, "640k is enough for anybody", "64-bit isn't needed on the desktop", "no advantage to dual core" etc etc.
The point is not that you don't need to do it, it's that if you're using http to do it you're an idiot. Claiming that http servers need to support over 2gb is like claiming that DNS servers need to. And show me a real reason to go for 64-bit on the desktop.
HTTP works where FTP has problems when dealing with complex networks (firewalls/NAT etc etc).
No it doesn't unless you try and run a server from behind a firewall. Just use passive mode and it will just work just as well as http.
'Insightful?' Puh-lease.
This is just made up garbage
Welcome to slashdot.
Assuming it is not, are you able to point to a single place anywhere on/. where someone suggested a firefox extension to fix a security hold where it was received as 'all well and good?'
It's possible to have a machine slow enough that you're forced to rip dvds to play them under linux (because of the overhead involved in breaking the encryption).
That would be a fix for a feature request, not a security patch. I've yet to hear of a real security patch being offered up as an extension (the one instance that happened, Firefox 1.0.1 or something, was because it was a simple pref change and not something to requires a rebuild).
The per-domain javascript whitelisting one quite frequently is. There was a real patch released as soon at the exploit I'm thinking of became known, but people were getting +5s for saying "that's why I use this extension, I'm not vulnerable at all".
Basicly, instead of assigning copyright, just assign a limited right to release under future GPL versions (which you could also do today with GPLv2, but I don't know of anyone that does).
I think there are projects which require you to give them a BSD-style license to it rather than complete copyright assignment.
Indeed, and any graphical gpg shell will have the same. But given that the OP is saying you can't use encryption without having a degree in IT, he presumably thinks that even this is too difficult for the average user.
Slashdot Mirror
If what you mean were true, surely there would be no such thing as indirect or subconscious copying?
Of course it is. They've copied the game, like copying a story it doesn't have to be word-for-word.
No. It's meant for doing secure transfers, that's what you should use it for, if you don't want a secure transfer you use a different protocol, which is how it should be.
Ok, so it's something apache should support. But it's not something to get excited about, because you shouldn't ever be using it.
Caching proxies, esp. helpful at large organisations where many people will be requesting the same data
True, and working in exactly the same way for FTP.
proxies ... often it's the _only_ way out of the network (well you can somtimes do FTP over HTTP).
Would you then say that http should support e.g. video straming?
indeed you could easily do the HTTP by hand, this is _much_ harder with FTP
Huh? Is it not just a question of knowing the commands for either?
If anything is more "suitable" for large transfers it'd probably be bittorrent, not FTP ... but even then bittorrent has one plus but fails most of the above
The point is there are various protocols designed especially for transferring files, and they are (or at least should be, I'll admit FTP has a lot of things wrong with it) better at it than http which seems to be pretty much a general-purpose protocol these days.
Nope, brought the parts and put it together myself.
and even if you did upgrade the RAM, since I assume this is a 32-bit machine we're talking about, having more than two slots would be pointless.
Again, no, well, it is at the moment for reasons I won't go into, but it was brought as a 64-bit machine.
You could put two 2 GB DIMMs in each, and then you'd have 4 GB of RAM, the maximum that a 32-bit machine can address.
There are ways to get them to address more.
You can expect motherboards sold separately (and thus targeted at do-it-yourselfers) and 64-bit machines to come with more slots than that, however.
Well, mine was both of those, and it doesn't.
It should be how it's set up, though I appreciate it may not be.
They may be "fringe cases," but there are valid uses for transmitting files over HTTP.
Of course there are - there are always cases where you don't have any other choice. Being able to transfer more than 2gb over http is a nice option to have for emergencies, sure - but it shouldn't be something you ever plan on having to use.
Another possibility where it may be desired is transmitting confidential data over HTTPS. While I admit that 2GB is a lot of data and there are probably more efficient was to transmit that much data securely (such as a good old-fashioned courier) that doesn't mean people won't try it :).
Why not use sftp, which is specifically designed for doing just that?
Mine always used to, but when I went to buy my latest machine I could not find a "desktop"-oriented one with more than 2 slots. I'm not happy about it, but it was that or nothing.
Are you saying that because we (probably) won't need 64-bit processors on the desktop for a few short years, we shouldn't bother preparing for them now? That's just plain short-sighted. Take a look at the history of computers and you'll see that every time somebody has made a claim like that, it's been a mistake.
By all means prepare for them. But to say we need to move to 64 bits is at least premature.
Can you not use PORT to change it if it's unsuitable?
So even passive FTP is not guarenteed to work in a NAT/Firewalled environment if outgoing traffic is port filtered (which isn't uncommon).
Point, yes, if you're filtering outgoing stuff you need to track FTP connections. But that's just a question of enabling one option in every decent firewall I've seen.
I use it every day and have never needed to transfer a file bigger than a few hundred k. Heck, I think I have a space limit of 250mb. And I'd use sftp instead if I wanted to transfer a file bigger than one or two meg.
True, but it's a bit lazy for the program to want to just map all the files into memory. We solved that problem in text editors back in the day. Sure, more memory is always nice, but I don't think there's a real need for that much.
I understood that the encryption used a key, and the break consisted of finding a way to decrypt it without the key (but requiring a bit more cpu power). With a well designed encryption algorithm this would of course be impossible, but that is not a description which applies to CSS.
No, I don't have time to.
Good admining takes time, effort and cost.
exposure to risk,
Nope. Dead wrong there. Using something for what it isn't designed for will always give you more risk overall.
When was the last time you downloaded a file from a DNS server?
When the story about how to transfer files over DNS hit this site. It's somewhat cool, but not really a good idea.
Sure, RAM. 3D work, CAD, video. What are you saying, 4gb should be enough for anyone? :)
I almost am. I'll certainly say that normal desktops don't seem likely to come anywhere near breaking 4gb for at least a few years - most motherboards sold today only have 2 or even 1 memory slot, and I've yet to see even a 2gb dimm, yet alone more. There are certainly areas where you need 64-bit, but I don't think we need it on the desktop, at least for a few years.
Yes, it's reasonably efficient, but it's far better to use a protocol designed for doing stuff like that, such as FTP as he mentioned. Use the right tool for the right job.
There's no reason to be doing that outside a large (corporate or similar) network setting, and in that case you should know what you're doing.
I see you've never configured a firewall then.
It'll be one extra line/tickbox at most in any firewall worth its salt.
He gave some perfectly valid reasons for wanting LFS - WebDAV for one. You ignored them, probably because you didn't understand them. And then you called him an idiot.
I made no special reference to webdav because it changes nothing. Using webdav to transfer files that big is just as idiotic, for just the same reasons.
AIUI the encryption was broken because it's quite simple, but the breaking process still requires effort, and takes more CPU than decrypting the dvd the "corect" way.
The point is not that you don't need to do it, it's that if you're using http to do it you're an idiot. Claiming that http servers need to support over 2gb is like claiming that DNS servers need to. And show me a real reason to go for 64-bit on the desktop.
HTTP works where FTP has problems when dealing with complex networks (firewalls/NAT etc etc).
No it doesn't unless you try and run a server from behind a firewall. Just use passive mode and it will just work just as well as http.
More money for registrars. That's the sole motivating factor.
Welcome to slashdot.
Assuming it is not, are you able to point to a single place anywhere on /. where someone suggested a firefox extension to fix a security hold where it was received as 'all well and good?'
Yes I am.
It's possible to have a machine slow enough that you're forced to rip dvds to play them under linux (because of the overhead involved in breaking the encryption).
The per-domain javascript whitelisting one quite frequently is. There was a real patch released as soon at the exploit I'm thinking of became known, but people were getting +5s for saying "that's why I use this extension, I'm not vulnerable at all".
Presumably they'll offer that service cheaper. If you don't think they're giving you what you pay for, you can go somewhere else. They know this.
And yet when someone suggests a firefox extension as a fix for something, that's all well and good.
I think there are projects which require you to give them a BSD-style license to it rather than complete copyright assignment.
Indeed, and any graphical gpg shell will have the same. But given that the OP is saying you can't use encryption without having a degree in IT, he presumably thinks that even this is too difficult for the average user.