First of all, learning the command line, git, vim, and Python is a bit too much for a beginner to handle all at once. IMHO, vim alone will scare off a lot of people.
Second, being exposed to a lot of different programming languages is very beneficial for a beginner.
I agree with this. I find that a lot of enthusiasts get caught up in learning to use tools, instead of understanding fundamentals.
Vim, git and Linux are great, but they are tools for getting a job done. Once the fundamentals of computer science are learned, these tools can be picked up rather quickly.
I'm all for this approach, as I'm a huge Linux/vim/git fan, but all of this must come after the fundamentals are in place. It's very easy to overwhelm someone with too much information about tools and terms.
Now if you're the next Linus Torvalds, then this is an excellent approach. Us mere mortals shall marvel at your talents from afar.
I think vim is OK if it is explained as ":i to modify, ESC :wq to save and exit".
Keeping the first explanation to this two use cases keeps it short and easy to remember, and not much more difficult than the other command line editors. pico or nano have the command in plain sight but I find them worse to type for beginners, and there is not much of a learning path from there.
You'd also want to map something more convenient to ESC. Like jk.
That way you won't have people immediately cursing this system that requires them to find the ESC key every time they finish editing a piece of text. Something more convenient can be mapped to :wq as well.
Actually....I think I'm with vukmir on the beginner in education being somewhat overwhelmed and I'm confused as to why Linux Server skill is being conflated with programming.
"consider Levinux a stepping stone for newbs, because it gives you a taste of Linux Server and sets you on your way to being able to do SOMETHING within minutes......Push your code up from Levinux and pull it down from whatever other system you end up using in the future."
"Code for life" is a big part of my philosophy. Over the years, I've found that one of the biggest obstacles was code-loss due to various causes, not the least of which is just losing interest and forgetting where everything is.
The only defense against this seems to be the two-fold approach of getting your code into more than one place, and being able to rapidly reproduce your code execution environment. For getting it into more than one place, I take many lines of defense: making Levinux so small that it's easy to copy, partitioning the hard drives so that syncing an entire virtual machine over Dropbox is still fast and efficient... and finally, distributed version control.
I've found in my work with git and Mercurial, workflow is totally transformed always for the better. And while neither git or vim are technically part of the code execution stack, they are both fundamental to what I'm trying to teach. I'm taking some creative license in how I define a stack :-)
