[conspire] (forw) [sf-lug] Dual boot (was: pair of own suggestion)

[Rick Moen]

In response to
http://linuxmafia.com/pipermail/sf-lug/2021q4/015401.html
http://linuxmafia.com/pipermail/sf-lug/2021q4/015402.html

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 12 Oct 2021 16:48:17 -0700
From: Rick Moen <rick at linuxmafia.com>
To: sf-lug at linuxmafia.com
Subject: [sf-lug] Dual boot (was: pair of own suggestion)
Organization: If you lived here, you'd be $HOME already.

Bobby wrote:

> Victor needs help with setting up a dual boot machine with a
> programming environment running in a virtual machine if I understood
> him correctly.

Aaron replied:

> As far as "setting up a dual boot machine with a programming
> environment running in a virtual machine", IMHO, Victor's best bet
> would be to first install Debian GNU/Linux as a virtualbox machine in
> whatever Windows version he's currently using.

You know what SF-LUG could do that would _really_ help people like
Victor?  Stop encouraging them to solve problems with the wrong
solutions for the wrong reasons.  

Like dual-booting.  Just because one can, doesn't mean one should.

Dual booting is just about always a bad idea that fails to satisfy the
user.  The curious Windows user ought to be told "Sure, you _think_
that's the thing to do, but mostly because it's the path of least
resistance.  You won't benefit from that as you think you will, and can
do a lot better at the cost of a bit of work on fundamentals."

Why?  I will elaborate.

> One of the main reasons for dual-booting as opposed to running Debian
> virtually is that there is host resource overhead required (e.g., RAM)
> in running a virtual machine such as Debian within a host system, and
> this host resource overhead slows down its virtual machines'
> performance.  Such is not the case when only a single OS boots and can
> load on so-to-speak "bare metal".

This is true.   _But_ reasonably modern computers have ample RAM
(the usual limiting factor) to also run a hypervisor layer and a 
Linux distro _provided_ one eschews bloatware (***COUGH*** GNOME3,
KDE Plasma, Unity, Cinnamon ***COUGH***).  

If the user made the sad earlier buy mistake of a low-spec RAM
coniguration and/or a poorly chosen hardware coniguration that makes RAM 
expansion uneconomical (e.g., system has eight DIMM slots that _could_ 
hold 1G DIMMS, but all eight have _256MB_ DIMMs because that was
"cheaper"), then that's a more-fundamental problem, and we should be
helping the Victors of this world not paint themselves into such corners
before coming to us.


When CABAL started hosting major-event installfests at LUG meetings, BSD
meetings, and Robert Austin Computer Show computer swapmeets in the
middle 1990s, we quickly figured out through observation why dual-boot
was a bad idea, and should be discouraged in the general case:

1.  Although the user assumed he/she would be switching OSes as
convenient through closing all applications and rebooting, over time
the user discovers it's so disruptive to workflow that he/she stays 
99%+ of the time in the more-familiar OS, and thus never really learns
Linux or gets benefit from its presence -- rendering the entire exercise
ultimately a waste of time.

2.  The user is _much_ more likely to accidentally clobber the
bootloader configurtion for either machine as a whole or one of the
co-resident OSes, or to clobber the other OS's filesystems both 
during repartitioning and later on.  So, the presence of the
dual-booting complications make the user's systems more fragile than
before we "help" him/her.

3.  Point #2 is particularly bad because one major reason Windows users
think the reason dual-boot is attractive is that (a) they're nervous
about their ability to reinstall Windows and their applications if
anything bad happens, and (b) are nervous about their near-universal
lack of tested, reliable backups in case anything bad happpens.
Non-destructive repartitioning and shimming in a dual-boot configuration
seems to offer the opportunity to finesse troubling problems (a) and
(b), kicking them down the road to deal with later, i.e., they seem as
close as possible to "don't touch anything" on a system dangerously 
exposed to risk of total system lossage from... practically any and 
all desktop woes:  hardware failure, owner mass-deletion blunders,
malware, security breach, etc.
 
When someone like Victor shows up, and it turns out he doesn't do
backups, doesn't have the ability or confidence or knowledge (or
installation media) to reinstall existing software, and is nervous 
and wanting to "not touch anything", the best way to help the Victors of
the world is to say "You really need to tackle problems (a) and (b) 
_first_."

Most Victors, or shall we say at least 6 or so deciVictors here in the
Bay Area, also have a spare, disused, 5-year-old computer sitting around
unused because, say, it ran WinXP but wasn't studly enough for Win7.
So, hey, here's a thought:  How about helping Victor put a Linux 
distro on the "nice but not overpowered enough for current Redmondware" 
machine currently gathering dust in the closet.  Put an ethernet cable
between the two machines, run VNC Server on the Linux box, and now the
user can do _real_ concurrent-OS computing, using both machines at the
same time from the overpowered Windows machine's console.

Or, better yet:  Once Victor has gotten a handle on problems (a) and
(b), he can with confidence blow away the preloaded Windows installation
and do a native Linux installation on the overpowered box.  Then,
install VirtualBox for Linux as a distro package.  Then, do a fresh 
Windows installation into a fresh VM.  Then, restore/reinstall Winapps
and user data, likewise inside the VM.

Unlike the path-of-least-resistance "helping" routine, this doesn't leve
a Windows preload in full charge of the machine in host mode, but 
rather confines it to guest role, abstracted from the hardware and
unable to hurt the host system.  Also, as with the previously-described
two-computer arrangement, the user can _actually have_ the benefit
of concurrent multi-OS usage.  Also, the user has a simple boot setup
that eliminates a large number of ways user shoot at their own feet.

The Linux community learned all these lessons a quarter-century ago.
It's just a bit sad to see people still making the same bad judgement
calls we learned to avoid, and learned why to avoid.



_______________________________________________
sf-lug mailing list
sf-lug at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/sf-lug
SF-LUG is at http://www.sf-lug.org/ 

----- End forwarded message -----