[Tutor] OT: Recommendations for a Linux distribution to dual-boot with Win7-64 bit
Steven D'Aprano
steve at pearwood.info
Tue Jun 28 12:10:12 EDT 2016
Following up from my earlier post...
On Mon, Jun 27, 2016 at 09:52:50PM -0500, boB Stepp wrote:
> 4) It would be nice if the most recent development tools were part of
> the most recent OS version, such as the latest stable Python 3, gVim,
> Git, etc.
Generally, the major distros have something very close to the most
recent version of the various tools, applications, OS, etc.
For those who like to live on the bleeding edge, you can install
something like Debian unstable, and what fun that is, but generally it's
better to use the stable versions instead.
> One of the commonly recurring questions I see on this list
> (and the main one)is that the pre-installed Python from the OS is a
> few iterations behind the current release, how can I get the latest
> and make two (or more) Python versions work together without getting
> confused as to which I'm using, etc.
My usual advice is:
- Don't touch the system Python. Consider it a black box and leave it
alone. To be more precise, it's okay to *use it* to run software, it's
even okay to use your system's package management tools to install new
libraries for it (but they're unlikely to be the latest version), but
anything that requires you to manually touch it, don't do it!
- Instead, install a second (or as many as you want) seperate Pythons
and use them. I always install from source, so if I can do it, anyone
can :-)
The instructions in the README file are pretty good, but if you need
help, feel free to ask. That will be on-topic :-)
Basically, I download whichever versions I want. Really old versions,
like Python 1.5 and older, may be hard to compile. Moderately old ones,
like 2.1 or 2.2, are hard to get support for readline and other goodies.
But unless you're a geek like me, why are you worried about ancient
versions of Python? So if you concentrate on Python 3, they should be
more-or-less easy to compile.
Now you have the system Python, which you run using "python", and the
one you installed, which you run using "python3". Easy.
If you have multiple versions of Python, say 3.5 and 3.6, you can just
specify the version: "python3.5". Or you can provide the full path. Or
you can set up a shell alias, for interactive use. In my .bashrc file I
have a bunch of aliases and commands for making Python easier to use:
# my system Python is Python 2.4
alias python='python2.7'
# set some extra directories to look for Python modules
export PYTHONPATH="..."
# run the Python startup file on interactive startup
export PYTHONSTARTUP=/home/steve/python/utilities/startup.py
# but not in Python 1.5, because that's too old
alias python1.5='env -u PYTHONSTARTUP python1.5'
Because these commands only apply to me, when I type "python" at the
shell prompt, I get Python 2.7, but when a vendor script runs "python",
it gets the version it expects, namely 2.4.
[...]
> 7) It should be easy to install existing software packages without
> having to compile everything from source. It would be nice if (to me)
> hidden dependencies are made clear, though I realize that part of the
> *nix learning curve is figuring out how to handle these sorts of
> issues.
As I mentioned before, that's the whole point of the package management
system. Coming from Windows, you really don't know what you're missing.
> 8) How troublesome is malware for Linux? I realize that it is not
> the normal target of crackers, but is it common enough that I need to
> install whatever the Linux equivalent is of anti-malware/virus
> software?
Technically, there is malware for Linux. The company I work for was once
even hired to remove a Linux virus from a system. Back in 1998 or
thereabouts.
"Drive by downloads", viruses, spyware etc. that you're familiar with
from Windows is practically non-existent in the Linux world. There's
probably some malware that might attack your browser, but I've never
heard of it, and if you run NoScript in Firefox, and block untrusted
sites, you should be fine.
However, if your Linux machine is visible from the Internet, you
should expect to be constantly under attack from remote bots trying to
log in. I have two firewalls between me and the Internet:
- my router runs a firewall;
- my Linux server runs a firewall.
Make sure your Linux system is running a firewall. iptables or ipchains
are the standard firewalls for Linux, although I daresay by now Ubuntu
has invented its own...
If you allow remote access to your Linux machine via ssh, make sure you
disable root logins over ssh. I also prefer to run Fail2Ban, which bans
(temporarily, or permanently) logins from IP addresses if they have too
many failed attempts.
> 9) Despite having an i7 quad-core 3.6 GHz CPU with 32 GB RAM, it
> seems that Windows with all of the constant security updating, etc.,
> tends to make my PC sluggish and I am tired of sifting through
> everything periodically to clear out the cruft and startup junk that
> loads. I *really* would like to have a snappy OS where everything
> *stays* snappy with minimal effort on my part.
That will be Linux, with a couple of provisos:
(a) If you have slow hard drives, AND you a disk I/O intensive process
running, then things may go a bit sluggish until it has finished.
Traditionally, Linux runs a bunch of jobs at 3 or 4am, such as updating
the "locate" database, and scanning and RAID disks to ensure they are
healthy. Being a night-owl, I'm often still up when they run, and for
five or ten minutes things run a bit slower for me.
(b) GUI web browsers eat performance. I gave up using Chrome because it
performs like a three-legged dog dragging a Grand Piano through a swamp.
Oh, it's okay if you run two or three or maybe even a dozen tabs, and
regularly quit and restart, but if you're like me and you have two or
three hundred tabs open and you don't restart for days or weeks at a
time, Chrome is *poison* to your system.
Firefox is better. I can easily run 300+ tabs in Firefox, for days at a
time. That's mostly thanks to NoScript: it blocks unnecessary
Javascript, which mostly means ads. On rare occasions where I find it
necessary to unblock ad providers, Firefox performance plummets, and I
invariably end up quiting it and restarting. (Sometimes closing the
offending tab alone is not enough to kill the running Javascript.)
Depending on just how much CPU and memory the thrice-damned ads are
using, you may see other applications impacted. But Linux is designed to
run *hundreds* of users on quite low end equipment, so even if Firefox
is struggling, other applications with lower requirements may continue
merrily.
> 10) I have a hard drive that has mostly text-based stuff, like Python
> programs, which is formatted NTFS. Can I share this with both Win7
> and Linux? What about the differences in line endings? Am I going to
> have to be constantly converting back and forth?
First, the easy part: line endings.
No, you won't. Most Linux editors can easily deal with Windows line
endings, and should detect them and automatically use them as needed. If
they don't, you should be able to set a preference to use Windows line
endings always.
Now, the hard part...
I've never tried to share an internal partition between Linux and
Windows on a dual-boot system. I'm not sure how well it will work. I
think you would have to set up your Windows system to use two distinct
drives:
C drive for the OS and maybe your personal home directory;
D drive for the shared area.
Being Windows, that will need to be NTFS. Anything else is too
difficult.
Then, in Linux, you would have to get it to mount at least the shared D
area, and I'm not sure how that will work. I've never tried it.
(Speaking of partitions, there's a fashion these days amount Linux
distros to use a single partition for the entire system. I'm old-school
and think that's a bad idea. At the very least, make /home a separate
partition from the rest of / so that when you eventually upgrade, you
can keep your home directory and blow away the old OS before installing
a new one. Also, if you ever have to do disk recovery, it's much easier
with multiple partitions.)
--
Steve
More information about the Tutor
mailing list