Guide to myth environment and editors

Written by Julie Zelenski

Here are some common questions asked by students when configuring their myth environment and choosing an editor.

What environment/tools we will use in CS107?

Our home base is the myth cluster. The myth systems are running Linux (Ubuntu 14) and have various open source tools installed that we will use (gcc, gdb, make, Valgrind, mercurial). These systems are networked and use a common set of accounts (your SUNet id/password) and have a shared AFS filesystem. There are 30 or so machines in the cluster, individually named myth1, myth2, and so on. No matter which myth you log into, you'll have access to the same installed software, your home directory, and all your files.

How do I access the myth machines?

You can log on to a myth console by going to Gates B08/B21/B02 where the physical machines are located. More conveniently, you can use a terminal program on your local machine to access a myth remotely via a network. Whether logged into the console or remotely, you will be able to access files and run programs.

Which editor should I use?

There are a variety of text editors available on myth: emacs, vim, gedit, nano, pico, and more. Each has their intended audience and makes tradeoffs between ease of learning, usability, customization, extensibility, and so on. Zealots might insist that "all real programmers use my-favorite-editor-here" but there is no "best" choice. Our staff is split between users of vim and users of emacs, so that where our particular expertise is concentrated (see our emacs and vim guides) but tutorials and features for other editors are only a Google search away. Don't obsess over which editor, choose one and get practicing so that you can be happy and productive using it.

Should I use a terminal editor or a windowing editor?

A terminal-based editor is text-only, without windows/menus, and controlled only by key sequences. The feel is pretty "retro". A GUI editor is more like the word processing programs you've used with windows, menus, buttons, mouse input, and so on. A terminal editor is typically very low bandwidth (advantageous if your network connection isn't so speedy) but can be a bit cryptic to get used to operating with just keyboard commands. The windowing version will be more familiar to operate, but requires that you set up a terminal program with windowing capability (mild hassle) and requires a higher bandwidth network connection to function well. Some editors can operate in either mode, so you can learn just one editor yet switch between terminal and windowing as circumstances dictate.

Can I use a local editor to edit remote files?

You may have a preferred text editor (XCode, TextPad, Sublime, etc.) on your local machine and you'd like use it to also edit myth files. Although there are ways to make this work, it involves hassles and risks that shouldn't be taken lightly. We also don't recommend relying on it as your first and only plan. Everyone should invest in learning a unix-based editor and practice until reasonably comfortable. These skills will serve you well now and in the future, as a local editor setup won't always be available or appropriate.

But I really really really want to use my local editor. Julie does it, why can't I?

We cannot in good conscience recommend this at your primary strategy. When it's working, it is quite convenient, but there are many things that can go wrong, and the potential instability, system hangs, and data loss can be mildly irritating to downright devastating. You must make your own informed decision about whether it's right for you and if so, pursue at your own (considerable) risk. The course staff will not answer questions about these tools, nor will we configure or debug your installation. You should practice good revision control as a preventive measure against catastrophic events. We've seen students lose an entire file in the blink of an eye, so keep your commits free-flowing to provide safe harbor.

Your myth files are stored on a networked filesystem called AFS and you must get those files to your local computer to use your local editor. Below are some options. Each has certain installation hassle, workflow disruptions, and exposure to risk.

  1. You can access your AFS files via web browser at afs.stanford.edu and copy files between AFS and your local computer . One (painful!) workflow would be to use a web browser to download a file from AFS to your computer, edit using your local editor, and then upload the saved file back to AFS.

  2. Alternatively, using a file-transfer program (e.g. scp, sftp, SecureFX, Fetch) to copy the file between AFS and your computer is a mild improvement over the clunky web interface.

    Both 1 and 2 require a manual copy after every edit which introduces a lot of friction in your development process, not to mention the risk of copying the files in the wrong direction and losing work.

  3. Some editors (Sublime, Coda, NotePad++, and others) build in SFTP capability, where a local save is automatically translated into a transfer operation to AFS. When working, this is pretty seamless and convenient, but on a glitchy network it can result in missed updates, weird synchronization issues, and dangerous data loss.

  4. An even-more-invasive approach is to install OpenAFS (available from Stanford IT Services), mount the entire AFS filesystem, and directly access files. This has been my strategy, and for my rashness I've endured all manner of kernel panics, system hangs, and lost edits. Over time I have learned where to tread lightly and how to play it safe so that it works out to a net-positive tradeoff for me, but remember this is a "professional driver on a closed course" and your mileage may vary. :-)

The simple and safe approach is to choose a unix editor and stick with it. There is a bit of a learning curve initially, but once at a comfortable place, you may find you are working even more productively than previously and won't miss your local editor after all!