2

Starting point:

  • I currently do development for Dynamics Ax, Android and an occasional dabble with Wordpress and Python.
  • Soon, I'll start a project involving setting up WP on Google Apps Engine.
  • Everything is, and should continue to, run from the same PC (running Linux Mint).

Issue:

I'm afraid of botching/bogging down my setup due to tinkering/installing multiple runtimes/IDE's/SDK's/Services, so I was thinking of using multiple users, each purposed to handle the task at hand (web, Android etc) and making each user as inert as possible to one another.

What I need to know is the following:

  • Is this a good/feasible practice? The second closest thing to this using remote desktops connections, either to computers or to VM's, which I'd rather avoid.
  • What about switching users? Can it be made seamless?
  • Anything else I should know?

Update and clarification regarding VM's and whatnot:

The reason I wish to avoid resorting to VM's is that I dislike the performance impact and sluggishness associated with it.
I also suspect it might add a layer of complexity I wish to avoid.

This answer by Wyatt is interesting but I think it's only partly suited for requirements (web development for example). Also, in reference to the point made about system wide installs, there is a level compromise I should accept as experessed by this for example.

This option suggested by 9000 is also enticing (more than VM's actually) and by no means do I intend to "Juggle" JVMs and whatnot, partly due to the reason mentioned before.

Regarding complexity, I agree and would consider what was said, only from my experience I tend to pollute my work environment with SDKs and runtimes I tried and discarded, which would occasionally leave leftovers which cause issues throught the session.

What I really want is a set of well defined, non virtualized sessions from which I can choose at my leisure and be mostly (to a reasonable extent) safe from affecting each session from the other. And what I'm really asking is if and how can this be done using user accounts.

1
  • 3
    Why do you need to avoid VM's?
    – JeffO
    Commented Jun 26, 2013 at 12:18

2 Answers 2

1

Think about containers: lxc, docker.io. These look like VMs but are lighter weight than VMs, and provide enough isolation.

With Python, you have virtualenv and friends. I only use these, one (or more) per project, and never install development stuff into my system Python.

With some sleight of hand, you can install multiple Java runtimes / JDKs, but this is usually not really necessary. It is highly improbable that an Android IDE would conflict with any other locally installed (as opposed to system-installed) Java software, since they all carry their jars with them.

WRT having multiple users: I'd avoid that. You'll have to duplicate much of the setup for each user (in which .bashrc have you made that convenient change?). OTOH you can try and see; just take two toy projects, like editing two separate text files, one per user. Work for a hour on one, then switch to another.

I usually didn't have problems working with a wild mix of projects you describe, even without containers or VMs. Do not complicate things unless you see that conflicts really crop up: usually they don't.

0

The challenge is many of these things are more machine-level installs rather than user level installs. Except for stuff that already has some sort of virtual environment ability such as python which eliminates the needs for another account entirely.

What you might want to look into is Vagrant, a tool for easily spinning up and managing virtual machines. That will let you handle complex scenarios without risky software installs. Yes it does install VMs but it avoids most of the downsides, such as the "magic vm" trap many folks run into as it forces you to that the configuration as code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.