I think this is one of the best things you can do to make the Linux CLI more accessible. I love vim for a lot of reasons but when I'm mentoring someone who's just starting out I skip straight past it for nano because I don't want the people I'm teaching to get bogged down in something that is super terse... New vim users almost always have to use a cheatsheet and I'd rather not inflict that on someone who's dipping their toes into Linux.

Once you get a bit further into the OS and what you can do I find vim to be an important tool to learn.

Changing your editor or shell is super easy to do and anyone who has a strong preference can update either within seconds.

I'm in the same boat. We use redhat jumpboxes for a lot of our tools at work. I'm kinda the department linux guy. It'd save me a lot of time if I could just tell people to modify their .ssh/config with nano instead of needing to explain how to navigate/insert/save/quit in vi.

I get what you're saying, but I think it's generally wrongheaded to tailor Linux defaults to new users. We're all beginners for only a fraction of our time on a platform after all.

I used nano until I got on my feet too and I'd love for it to be added to the standards so it's always present. But the goal of good POSIXy defaults are for transferable consistent experiences/skills. I think defaults should be things you'd want for typical real world use, not to upgrade off of.

Edit: To clarify: I think accounting for beginners is important! But I don't think using crippled defaults are the way to do that.

> "it's generally wrongheaded to tailor Linux defaults to new users"

> "I think accounting for beginners is important!"

I read this as two conflicting statements.

> But I don't think using crippled defaults are the way to do that.

I disagree that nano is a "crippled default" - nano is a highly competent text editor and I see plenty of industry professionals use it daily.

Yes, and probably more usable than vi (not talking about vim) and its features are more than enough to edit configuration files.

It has copy paste of a line or an arbitrary chunk of text (I learned that last week! But I often use the copy paste functionality of the terminal emulator anyway), syntax highlighting, undo redo, line numbers, search and replace. Access to these features is efficient.

It's also fast and lightweight. All the characteristics of a good default terminal text editor. Free us from vi! :-)

Nothing wrong with an immediately steep learning curve it's only hard until it isn't

I'd respectfully disagree with this one unless the steep learning curve is a requirement to the task at hand.

I mentor/teach with an "ability outwards" approach... ie: I want to get my students a simple capability first, and then "add tools to the toolbox" second. Typically, their first project is a small webserver with a database behind it (nginx static config first, then moving to a nginx + MariaDB + $their_preferred_language stack; all on Ubuntu Server).

Since that's a non-trivial task I want to keep the details as simple as possible, so they can focus on things that matter. Typically I won't teach vi/vim/sed/awk etc. until after they can accomplish actual work within the OS. Although I see complex text manipulation as important, I see it as additional tooling vs. a concept they can anchor their learning experience to.

> Nothing wrong with an immediately steep learning curve it's only hard until it isn't

I read this as "throw em in the lake, they'll learn to swim" vs. being honored to help them start in one of the most powerful ecosystems I've ever been privileged to build in: Linux.

>I'd respectfully disagree with this one unless the steep learning curve is a requirement to the task at hand.

The task at hand is to learn basic linux. You shouldn't be editing server configs or performing other higher level tasks until you have at least a basic competency at using the system, and learning text editing with vi is one of the most basic and useful skills to have since it's ubiquitous.

The reason I'm so opposed to this teaching philosophy is that "just get started developing"-first approaches instead of admin-first invariably seem to lead to sloppy and/or insecure products, and you end up with yeehaw "chmod -R 777 to make it work / SELinux is a hassle, always turn it off" developers that have to be painfully retrained once they get into the real world (or worse, are left to their own devices and you end up with horror stories like unsecured databases being exposed to the internet with PII or PCI stuff stored in it).

It is impossible to develop good quality software if you don't understand the platform you're building on top of, and the concerns of the people who'll end up using your software.

>I read this as "throw em in the lake, they'll learn to swim" vs. being honored to help them start

I see your approach the same way - skipping the basics and throwing them in at the deep end. So many projects suffer because of lack of knowledge about systems administration, basic networking, security, etc.

Effectively I'm supposed to start someone off with expert tooling and security knowledge so they don't end up blowing themselves up on ... well... Anything?

In my experience all of this knowledge happens "on a journey" vs. treating it as an ideal set of skills. Hence why we have student/intern/junior/senior/architect levels and the like. I review the heck out of junior level work and often find opportunity to help them improve.

I start people off at being able to accomplish something as I find it to be more motivating to keep them learning all of the things you mentioned.

If you're expecting me to have someone at a PCI level (which I am) as a junior you're missing the scope of what I mean when I say "honored to help them start". It took me years to be competent enough to handle PCI as a dev/admin!

Sorry I start with nano and simple web server configs =/

You can't get there from here I say thrust people into a trial by fire and convince them to choose another profession until only the hardcore remain but who's hardcore anymore in this world of where's waldos and salty emoticons

It is a complete lack of empathy to ignore the fact that people learn at different paces, and in different ways. Where I struggle, others succeed and vice versa. The last thing I want to do is have an attitude of "ONLY THE HARDCORE SURVIVE" (read in a voice of an early-2000's wrestler). When we act like this we turn people off to the world of computing... But, we disagree on this - you actively want that.

We have real problems of inclusion in our industry and as someone who's been "part of the problem", I don't want to be part of the problem. "Keep the barriers high" only accomplishes isolation.

You also clearly see yourself as "hardcore". It's OK to feel confident in your respective knowledge, but I would remind you that no one knows everything. This will turn people off to you as an engineer, a colleague, etc. We should all keep our minds open by assuming the role of an everlasting learner in a field that is constantly changing and evolving - I urge everyone to stay humble.

I am sorry you feel this way, and hope you reconsider your stance.

No way -- you're still standing so you must be one of us

Do it!

I disagree with everything you said.

I've been using vi (and vim and neovim) for 20 years and it's a fantastic editor but not for people new to the command line. There's no reason that nano shouldn't be the default. It's available on many systems by default anyway and it's much more beginner friendly than any vi spinoff. If the only reason for sticking to a thing is "tradition" then it's right to re-evaluate it.

There's a reason that "how to exit vi(m)" is the most read question on StackOverflow.

> Once you learn how to exit vim you only need to look it up a few more times before you begin to get it > > I've also struggled to exit nano from the keyboard with ^X or whatever

And in nano it's displayed right there at the bottom of the screen at all times whereas with vi/vim/neovim you have nothing to go by unless you're lucky enough that you happened to open it up on an empty buffer in which case the "splash" screen will tell you to consult with :help or quit with :q. StackOverflow is a testament to how slim your chances of randomly guessing that is.

> Appreciating all sides of an argument helps one understand the delicate balance that exists rather than the constant polarizing of opinion that agreement and disagreement evoke

I would agree with that if the comment I was replying to actually put up some good-faith arguments rather than just making unsupported statements about Unix/Linux and vi(m), or if we were arguing something wildly subjective here but the argument I was making was that nano is easier for newcomers than vim, and there's plenty of empirical data in the form of questions in forums and the like to back that up.

You're leaning too heavily on rationalism whereas computer science is both an art and a science and its definitely not for everyone hence the preference for sheer barriers to entry

> [...] its definitely not for everyone hence the preference for sheer barriers to entry

So, keeping in mind that you said you'd had your issues with exiting nano (despite the instructions being on-screen at all times), is CS for you?

Besides, people have other reasons to be messing around with Linux/Unix than studying CS.

I'm sorry, but you're presenting exactly 0 arguments for gatekeeping except gatekeeping itself, and that just seems rather silly to me.

I started on an apple][ where anything you typed simply said SYNTAX ERROR and there was no stack overflow

That's cool, but do you have any arguments for gatekeeping except for "for the sake of gatekeeping"?

Yes because it's hard until it isn't whereas the other way around it's a bunch of green neophytes all thumbs

Yeah, God forbid that we actually improve on things and make them more accessible. Hell, we should all start out with punch cards and only be allowed to use a keyboard once we've punched our way through making a functioning driver for it.

That CS macho thing you're trying to get going is both silly, unproductive and meaningless.

We do not all agree that vi is poorly conceived and awful to use. Its a great tool if you know how to use it. Furthermore, in today's world its entirely possible to be an extremely proficient systems administrator without being proficient at Vi. My co-worker is a senior DevOps engineer and uses nano and VS Code exclusively, no vi or vim at all. I will concede that Vi is extremely beginner unfriendly though.

> Undoubtedly, we can all agree that vi, like all other UNIX tools, is poorly conceived and awful to use.

I disagree with everything in this sentence.

(neo)vim + Unix tools make the best IDE in existence. Nothing else to date can hold a candle to that combination (except, perhaps, Plan 9 or Inferno OS).

> (neo)vim + Unix tools make the best IDE in existence. Nothing else to date can hold a candle to that combination (except, perhaps, Plan 9 or Inferno OS).

Don't forget about the Dvorak keyboard. It doesn't work without Dvorak.

I should really make a list of things I would change if we could adopt better standards free of legacy. Dvorak would be included; the only reason I haven't learned left-handed Programmer's Dvorak is because most devices don't make it trivial to change the keyboard layout.

Emacs is also worthy of a mention here. Like Vim it takes a little getting used to, but it's incredibly powerful. Emacs works fantastically as an IDE (as does Vim), among many other things.

With evil-mode, emacs becomes the best vi-style text editor in town.

I've been using UNIX systems for literally decades now without ever bothering to learn any more of vi than how to quit. I just switch the default editor to nano and get on with life.

sacrilege.

As a Vim user, this is a good idea.

As a vim user, I too agree. Vim is my favorite editor, but the learning curve being a barrier to adoption is an undeniable fact.

Just would hate to have vi dropped entirely, like it is in NixOS / GuixSD.

Also, I can't recommend vimtutor enough to anyone new to it who doesn't have nano at their disposal.

Would prefer if something like nano but non-GPL was available for the BSDs.