Hacker News Reader

Comment by peterangular | Hacker News Reader

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.

View on HN

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

Ed is the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.html

Surely you can set EDITOR on any machine you are doing real work on, which isn't going to be a fresh default installation.

OK, so the default should be vi, and damn the newbies... and the emacs users?

Reply on news.ycombinator.com