I saw a 6th grader using filezilla to update his website the other day. 99% of people didnt know what ftp was 10 years ago, that hasn't changed. Every generation loves to trash the one below it, that certainly will never change.
I think it's a lot harder to become technically competent these days.
Before, computers compelled you to have a certain level of technical competence to be a user.
Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. The resources once you are on the track to doing technical stuff are far better, but you're less likely to end up on that track-- especially at an early age.
> Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc.
I'm a fairly young person. What I've seen over the past few years is technology is finally useful and accessible to everyone. Forcing people to use the command line isn't a useful skill for 99.5% of people anymore, it's just senseless gatekeeping to make it a computer requirement. I got into computers by ripping into Windows XP internals and learning how it worked when I was a kid, no command line needed.
There will always be people who are more curious about how things work. Have faith that kids are smart enough to use the internet to learn for themselves.
Just because technology is easier does not mean it's harder to learn how to be "technically competent". Remember that the definition of technically competent moves with the times, too.
Before, a huge portion of the population was using computers and had to peek under the hood. This means you got a lot more people who got curious about how the machine worked very early on.
I am teaching STEM stuff to kids these days-- programming in Scratch and python, etc. My friends and I, back in the day, were all poking around memory, rekeying Basic programs from magazines and moving on to writing Turbo Pascal programs, etc, at a pretty early age. I don't see this with the kids I teach. There's not as good of a path/funnel there, and I'm not sure whether the stuff we do to e.g. teach programming in elementary school, etc, are analogous exercises in computational thinking.
I agree with you. I was in high school a couple years ago, and lucky enough to take cs classes. What I experienced was not good. Most of the kids just showed up, did the projects, passed tests, and got A's. But they were not good programmers. They were just going through the motions, if you gave them something slightly outside their knowledge, they would likely just give up.
I think there's something fundamentally wrong with the way cs is taught, but its hard to teach computers in a class setting. You really need to inspire that deep interest that so many of us have in computers, and it's very tough to get at that in the modern day. Because of the overload of information and media that kids are getting thrown at them these days. It's very easy to sit down 20 kids and make a game in scratch, and call it computer science.
We should have kids use technologies that professionals use in their work. Setup a flask web server, write a scraper, use apis, etc. Stop dumbing down things, expect more from the younger generation. Those coding bootcamps sure as heck don't teach scratch right?
I've also taught primary school kids (elementary) similar things, though fairly limited. Overwhelming what I've seen is most of them are fine with the tool they're shown and not much more, but those who do want to learn more aren't hampered by lack of exposure to the command line. Maybe a bit further behind, but they can figure it out quickly.
I think the trade off between this and computers being far more accessible is worth it.
The percentage of such people was, is and is going to be minuscule who care the slightest amount about peeking under the hood or truly understanding. By your logic every computer user from previous generation should know more about computers, but actually they don't.
I firmly believe that the best technology can do both. Tools should be designed firstly for the 95% of users who only need them at a surface level, but provide pathways that encourage users to explore deeper, as they become ready.
macOS kind of does this, whether intentionally or not. On the surface, it's a basic consumer machine, with a web browser, media player, and office suite. But dig a little deeper, and you'll discover Automator, a great little tool for automating menial tasks which puts you in a programmer mindset. Probe deeper still, and you may discover the Terminal icon, full of secrets to be discovered.
It could be taken further. Imagine if TextEdit had built-in syntax highlighting whenever it detected code. "Regular" users would never see the highlighting, and professional programmers would stick to real IDE's or more advanced editors. But as a hidden built-in, it could be a wonderful stepping stone.
Now compare all of this to iOS. Yes, it's true, no one really wants to program on an iPhone anyway—but what happens if you give a child an iPad instead of a laptop? There's now much less opportunity for them to grow and discover more. This isn't to say that every child with a Mac will discover the terminal and become a power user, but some will, and be thankful for the opportunity.
I encourage you to spend some time getting to know the linux command line. I had a similar path and I gained the most enlightenment (and productivity) when a got some help from a good mentor and learned how to find my way around. Menial digital tasks that most people suffer through all day turn into small puzzles with big rewards: you get your day back. Sure, maybe half of it went to figuring out a syntax error, but then the rest of the days get to benefit from that work. Moreover, you learn the most when trying to fix that little bug, and you're better for it the next time.
Stuff like renaming 200 files, or converting 200 images to a different size, or normalizing 200 audio files you recorded yesterday, or finding the right few words in 200 files all can be done with minutes of effort once you unlock those powers. I use 200 because that's about how many times people are willing to sit there and bang out something manually. Tasks larger than that people tend to give up on, or buy a tool to help. The neat thing is, the same solution for 200 items could be applied to 200 million items without changes.
I would love for the full power of the CLI to be available to everybody without training. Until that gift comes from on high, we use the tools we have, GUI or text or SMS or whatever. Today you can pick your path.
The internet does unlock all of those doors to those who want to learn. There are incredible resources for learning new things and fixing problems that others have ran into. Reading man pages and printed manuals may be fun for some, but I'd rather search for answers, and chip in some when I can.
I'm not saying the command line isn't useful, it's insanely useful to me, but I and presumably you are the 0.5% of people that do things like batch organising thousands of files. Most people will just have a basic folder structure on a cloud service somewhere and they're fine with that.
My point is that the general population doesn't need to be exposed to the command line to be able to go deeper into learning computers. Those who need it will hopefully find it.
I don't know what it is about a black, mostly blank screen, but for the first 30 years of my life it was a source of anxiety, a 'thar be dragons...' kind of feeling. I was convinced I would make one wrong keystroke and do some terribly destructive operation. Hell, there are still some directories I'm reticent to visit.
I wish there were guard rails for learners (I guess a proper permissions scheme would do) or a safe place to explore (probably lots online at this point). Agreed that for most people, storing files in Dropbox lets them get real work done without a second thought, and that in itself is A Good Thing.
It's good that computers are more accessible. But by making it easy, we're providing less opportunity for people who are curious about innards at an early age.
Of course, now we're teaching computational thinking in schools, but IMO it's a really big open question whether our attempts to teach that work, especially in elementary school.
Understanding the inner workings of computers is not a fundamental good. Solving problems and achieving one's goals are the important thing. If people can use computers to solve problems better today but they don't understand how bootloaders work then I think that is a good trade off.
Both of those may be true, but does it have anything to do with ftp going away? It's a pretty bad protocol that's rarely used, why should browsers still support it?
We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution.
Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then:
It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain.
FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now?
Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter.
Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.
FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.
As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some.
SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind.
As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare.
That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
And that’s also why SFTP is slower than FTP: because it’s a separate protocol implementing its own windowing which interferes with TCP’s, thus performance goes down the toilet when using SFTP over a high latency connection.
Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
Indeed, but your question wasn't about Chromium ftp support.
Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.