[sf-lug] Ubuntu, GPartEd, Bad Luck with Blue Collar Linux-Help! etc.

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

>     Today's News is that Distrowatch is now stocking
> /Distribution Release: Ubuntu 18.04.2 /LTS.
> 
>     Hopefully this will not be full of the problems that have
> plagued Ubuntu lately.

I haven't followed closely, but I got the impression the Ubuntistas got
hit by mostly problems that we're really their fault, recently, but were
visited upon them from upstream coders.  (Canonical doesn't originate
very much.  It's a bundler, mostly.  Same is true of most distros to
one degree or another.)

It might help to review the basic concept Ubuntu promised for its
releases (and I'm including the several *ubuntus in that).  Canonical's
core value proposition was, 'We're going to leverage Debian, except...:'


1.  We'll release for only 3 CPU platforms, not 14.  (Since then,
PowerPC has been dropped, and i386 is in the middle of joining
it.  aarch64 is coming in.)

2.  We'll concentrate on a limited set of desktop software for each
*buntu variant, instead of 22,000+ packages as Debian does.  (I've
lost count of how many packages are currently in Debian's collections.)
And those will be fairly close to the latest available for the desktop
environment in question as of the release date, something possible
because of our release cadence:

3.  We'll have preannounced release dates, about every six months, and
hit the target date without fail -- in contrast to Debian, whose 
release motto is 'when it's ready' and has been known to sometimes 
go as long as 3 years between releases.  (Debian's access to very recent
DE packages is on the testing/unstable rolling distributions, not its
behind-the-curve 'stable' release-oriented distribution.


Novices tend to be confused by rolling distributions and unable to
handle the inevitable bobbles, so Ubuntu addressed that need with
regular releases.  It addressed the dissatisfaction with old app
versions in Debian-unstable by targeting new app versions for each
release.  And ignoring all CPU platforms other than those vital for the
commodity marketplace helps stick to the rapid release schedule.

That brings us to the price, the drawback:  Shipping all recent versions
exposes the distro to upstream bugs, and having a clockwork-like release
schedule means that even if there are still serious bugs as October 2018 
comes to an end, because Ubuntu promised an 18.10 release, it had to 
go out the door no later than Halloween, significant bugs or not.

In similar circumstances, the Debian Release Manager would just say
'It's not ready yet'.  Canonical doesn't do that:  It keeps its
promises.  Which I respect, but you need to understand the price of
that.

Now, understanding that, you can also see why prudent people might give
18.10 and maybe even 18.10.1 a pass, and wait for 18.10.2.  ;->  


Anyway, long as I got you on the horn, Bobbie, I wanted to consult you
on something.  CABAL has always kept a distro library, and I've recently
been bringing it up to date again:

Liten-Datamaskin:isos rick$ ls -lh *.iso | awk '{ print $5 "  " $9 }'
952M  antix-17.3.1_amd64-full.iso
987M  antix-17.3.1_i386-full.iso
2.7G  blue-collar-linux-initial-release.iso
706M  bodhi-linux-5.0.0-amd64.iso
918M  centos-7-1810-amd64-minimal.iso
507M  centos-7-1810-amd64-netinstall.iso
3.4G  debian-gnome-unofficial-with-nonfree-firmware-9.7.0-amd64-dvd1.iso
3.5G  debian-gnome-unofficial-with-nonfree-firmware-9.7.0-i386-dvd1.iso
2.2G  debian-live-lxde+nonfree-9.7.0-amd64.iso
2.2G  debian-live-lxde+nonfree-9.7.0-i386.iso
326M  debian-unofficial-with-nonfree-firmware-9.7.0-amd64-netinst.iso
413M  debian-unofficial-with-nonfree-firmware-9.7.0-i386-netinst.iso
641M  debian-xfce-9.7.0-amd64-cd1.iso
641M  debian-xfce-9.7.0-i386-cd1.iso
647M  devuan-ascii-2.0.0-amd64-cd1.iso
298M  devuan-ascii-2.0.0-amd64-netinst.iso
2.9G  fedora-server-29-1.2-amd64-dvd.iso
593M  fedora-server-29-1.2-amd64-netinst.iso
1.8G  fedora-workstation-29-1.2-amd64-livedvd.iso
593M  fedora-workstation-29-1.2-amd64-netinst.iso
318M  gparted-live-0.33.0-1-amd64.iso
1.8G  kubuntu-18.04.2-lts-desktop-amd64.iso
1.8G  kubuntu-18.04.2-lts-desktop-i386.iso
1.8G  linuxmint-cinnamon-19.1-amd64.iso
1.8G  linuxmint-xfce-19.1-amd64.iso
1.6G  lubuntu-18.10-desktop-i386.iso
717M  lubuntu-alternate-18.04-amd64.iso
715M  lubuntu-alternate-18.04-i386.iso
1.1G  lubuntu-desktop-18.04.2-amd64.iso
1.1G  lubuntu-desktop-18.04.2-i386.iso
1.6G  lubuntu-desktop-18.10-amd64.iso
1.9G  manjaro-xfce-18.0-stable-x86_64.iso
1.7G  siduction-lxqt-18.3.0-201805132142-patience-amd64.iso
559M  systemrescuecd-5.3.2-i386.iso
888M  systemrescuecd-6.0.0-amd64.iso
1.9G  ubuntu-desktop-18.04.2-lts-amd64.iso
1.9G  ubuntu-desktop-18.10-amd64.iso
834M  ubuntu-live-server-18.04.2-amd64.iso
881M  ubuntu-live-server-18.10-amd64.iso
1.4G  xubuntu-desktop-18.04.2-amd64.iso
1.4G  xubuntu-desktop-18.04.2-i386.iso
Liten-Datamaskin:isos rick$

At times in the past, it's been a lot bigger than that, and I don't mind
grabbing things CABAL attendees might want, but am not going to grab
_everything_ on speculation someone might want it.

Way back in days of yore, I would have dutifully fired up the CD/DVD
burner, burned each to as many optical discs as required, jotted the
contents description on each with a Sharpie, made a library reference
copy, and filed that in a set of soft cases I kept around for that
purpose, filed alphabetically.

Man, that was a lot of work, and the _real_ solution was to load them on
a dedicated CABAL installfest server to serve them for network installs,
but I never quite got around to that.  But meanwhile, the world changed:
People no longer use optical disks, mostly because USB flash drives 
are on balance better for most things.  

And here's what I'd appreciate knowing, Bobbie:  How do you do physical
management of USB flash drives, in the context of your big library of ISOs?
(I'm assuming you aren't burning CDs/DVDs, as if it were 1998.)

Probably like me you have a dozen or more flash drives sitting around,
of various capacities.  Each is a tiny little thing -- ergo, no room 
for external labels.  Blessedly, each can be just overwritten if it
doesn't have what you currently need, a large number of times, in fact.
But how do you avoid having a dozen little widgets each with
uknown-to-you contents?

Pondering that problem, just now, I had an idea:  Small ziplock bags.
You can either write directly on the bag with a Sharpie, or just insert
a slip of paper saying what this drive currently contains.

A different routine would be to _not_ have distros installed on flash
drives in advance, but just plan on writing to one from your collection
of ISO files at time of needing to use one.  Could work, too.

How do _you_ handle that, Bobbie?