An example which Fedora x64 even DSN’T install bootloaders w/o GPT, but Fedora x86 should be still installed under MBR, right?
On-the-other-hand, openSuSE has cut EVERY 32bit arch and still maintains only amd64(x64), arm64, ppc64, and its UEFI-needed derivatives just DON’T install bootloaders like Fedora (see SuSE studio).
Finally any NON-rpm distro should still work fine without GPT.

openSUSE has not cut 32-bit support from Tumbleweed, which I have installed on multiple Intel CPU and chipset machines as old and older than your friend's HP. I also have multiple 64-bit Intel CPU and chipset machines as old and older than your friend's running both Tumbleweed and Leap 42.3, 42.2 and 42.1. All are installed on MBR disks and boot using Grub. None use EFI. Most of these machines have 2GB or less of RAM.

Maybe I was come to miss i?86 inside the Tumbleweed ISO repo, here my friend has required "rolling, or LTS, or nothing", obviously Fedora is not his choice, thus only 32bit spins from Tumbleweed, Debian, LMDE, Ubuntu LTS, Slackware, Arch are recommended to him.
First of all he is FRESH to Unix, making LMDE, Ubuntu, Slackware to be the first ones to be recommended to him.

There seems to be a bit of a terminology issue here....

There is BIOS and UEFI. Plus MBR and GPT filesystem/booting.

You can always MBR filesystems from BIOS.

You can boot GPT filesystems from UEFI.

With most linux distributions and hardware you can run a GPT filesystem/booting from BIOS or UEFI (even older hardware BIOS-only hardware which does not support GPT filesystem/booting with windows)

Its possible to boot MBR from UEFI with some dsitros but thats pointless to even think about in 99%+ of cases.

I'm not sure about other distros but the lastest Debian stable version, 'Jessie' or Debian 8, has the software to install and run to both BIOS/MBR or UEFI/GPT systems and will automagically install the correct version for your system.

No you are not limited to 32bit (x86) you can also run x86-64/amd64.

Rolling or LTS? those are *very* different ways of running a system....I would not suggest a rolling release for a beginner. so no LMDE.

Arch is *not* for beginners. Slackware, well, its easier for a beginner than Arch but I wouldn't install it for anybody new to linux. Help someone while they installed it maybe, but only a little and if they had major issues I'd move on to a different, more 'works out of the box' distro.

ubuntu? I have issues with canonical and how they do things so I am biased. Getting past that I suppose its meant to be easy but that interface is awful. I'd just install Debian stable, Xfce or KDE desktop, 64bit.

Here, few notable pros of a rolling distro are an permanent support and the most up to date security, but a con of unstability, but is this con REALLY SCARY to a novice?
Of course Arch is not recommended to my friends UP TO NOW, which I still have a difficulty to install it, even I already have an Unix experience for a few years.

It's not so much about scary, it's about annoying. Which is likely the real reason they left any and all "other" operating systems to give linux a try.

Scary? No. But given enough time, you will break a rolling release system. It might not happen overnight, but it will happen. Even if you check the upgrade warnings before ever upgrading, sooner or later 'bad' package will break the system. End of story.

By the way, with Debian 'Stable' gets security vulnerabilities updated before 'Testing'. 'Sid' gets them from the maintainer. Testing gets them last. So you have a choice between timely updates with Stable, running higher changes of breaking with Sid, and slowest security updates and still some risk of breakage with Testing.

Here, I was at FATALLY EXPERIMENTAL Rawhide (not rolling itself but its packages messedly upgraded) and its kernel was slain which I was occasionally upgrading system.
On the other hand, the rolling systems, like Tumbleweed and Debian testing, upgrading the whole system constantly is not likely to break the rolling system, but upgrading a few software by sole is likely to be led to dependencies compatinilities issues, here the incompatible but not fixed dependencies are risky to break your system, esp you have not afterwards upgraded the whole rolling system.
You have been said my important experience (to a practice for a rolling system) here, however is a novice prone to ignore and forget to upgrade the whole system after solely upgrading a few software?

how do you define "break"? if it means, something unforeseen happens, you can't update or some software won't work and you have to fix things, well, yes, then i agree.
but that can happen on almost any distro, even debian stable.

i've been running a rolling release (arch) on my desktop for 3 years now, and debian stable on my server.
i haven't had any serious problems on either, but i also haven't had no problems on either.
for me it's a tie.
different usage scenarios, but a rolling release distro isn't intrinsically less stable than a release distro, and a release distro isn't intrinsically more stable than a rolling release distro.
don't get me wrong, debian are doing an invaluable job, and it's for a reason i'm using it on my server.

while both sid and archlinux are rolling, i think there's a huge difference between them: archlinux does do some quality control and testing and compiles software specifically to work with archlinux. they also have a [testing] repo, which i avoid like the pest - i think that would be more comparable to sid.

for me, a stable, monitored rolling distro like archlinux is the best.

Not likely to break for any given update? Sure. But when you upgrade often, which you probably should with most rolling releases, the chance of breakage increases.

Upgrading a single package is generally not a good idea. But most of the time if I see a user trying to install/upgrade a singel package (or group of packages) its because they are trying to run some 3rd party non-repo software. Which is often outdated, and/or is wants you to /mix and match' software from different point releases or even linux distro families, and/or it wants you to use packages from an dodgy/unknown source, and/or the instructions are outdated or just wrong.

Those sort of things are why there is a 'DontBreakDebian- Advice For New Users On Not Breaking Their Debian System'

https://wiki.debian.org/DontBreakDebian

LOL, I mention ' terminology issues' and then this (BTW not a shot at you by any means ondoho, just funny the way things go)

Good question, 'break' can mean a few different things to different people.

IMO for an OS to be properly broken it should fail to boot to the desktop.

I've had it happen a few times with testing/sid mostly due to closed nvidia drivers but also from other xorg problems.

In all my time with rolling releases I haven't had a update cause a situation where I am unable to update again (though I have done via user error).

I know by 'stable' you mean 'runs without crashing'. Its one of the reasons why I've never been overly fond of Debian calling its non-rolling-release 'stable', cause by stable they mean 'not changing'.

But yeah I agree, a well tested rolling release can be....err...'less crashy' than a badly tested point release.

I think that Arch 'testing' might be more like Debian 'experimental'. Which is where Debian does some quality control before things go into Sid.

1 members found this post helpful.