I hear this argument often.  A certain type of user goes to a forum, posts a problem and claims that "it worked perfectly on Linux distro xyz".  It really doesn't prove anything.  You can't isolate the fault to one particular component unless you have actually found the solution to the problem with that particular Linux distributrion - just removing it and installing a completely different distribution with a different kernel release doesn't really prove anything.  The many more things they don't have in common could be the source of your problems.

This does show that you have little understanding of the Linux kms/drm driver stack and X.org.  The "lightweight" tag applies to the window manager or desktop environment in the case of these Ubuntu respins (I believe the L is for LXDE), the base system is usually the same - as I recall it was possible to install/remove the other full blown desktops by installing/removing the meta packages - may no longer be the case for all I know.  None of this should have any bearing on the X.org implementation - that should be the same.  The X server dropping to a tty also has no bearing on this.  If the display is configured or detected incorrectly (again nothing to do with systemd), then the result can be what you posted.  I would have to guess, but perhaps your "hardware" (virtualised in your case) wasn't supported and X.org tried to initialise a frame buffer device.  (In glorious 8 bit colour).  If you'd examined the log files for X.org you might have found out why or at least found something to point you in the right direction.  As you've not stated what VM you're using nor the emulated architecture or how it's configured (e.g. if vt-x or amd-v are enabled), there's no way of knowing.

The X server renders graphics - your low res and low colour depth, distproportioned image can only originate from the X server (which I can assure you is in no way "integrated" into systemd).  It's an easy conclusion to come to.  But if you can provide factual evidence that systemd is in fact responsible I'll accept it's my error.

You could also ask the Virtualbox, LXDE developers or maybe the X.org or drm/kms developers on their mailing lists.  The answer will probably be that they haven't integrated their projects with systemd.

What?

And of course the only difference between the releases was systemd...?  Not ~ three years of development, in the kernel and video driver stack to name just a few...?

Setting aside what I might think of systemd, this kind of thread only fuels the argument that many systemd opponents are just ill-informed fanboi types.  I'm not sure what Linux KMS/DRM video driver stack and X.org server have got to do with systemd.  This looks more like a driver bug (or a configuration error)?

Despite the claims, *buntu family have always used "bleeding edge" technology from Debian testing/unstable/upstream rather than basing off the stable release.  It's not unusual for their to be a regression or several in a particular release's kernel.

As we don't know what kind of virtualisation was used in this case, nor how it was set up, it's hard to say what cause might be.

And that's before we even get onto the subject of "testing in VMs"...

Firefox and Seamonkey are based on XUL and don't depend on GTK+ directly, as far as I know, it uses (emulates) the themes.

If you want finer grained control over dependencies, you'll have to build from source.  Upstream packagers whether Mozilla or the various distributions will not feel obliged to exclude certain software...

Building modern browsers from source can be time consuming however and rebuilding every time there's an update will be tedious.

You can download from the pre-built binaries mozilla.org: https://ftp.mozilla.org/pub/firefox/releases/56.0.1/

Dot files usually store state information, user customisations and other data such as e.g. shell history or a web browser's cache.  They're not installed from a package, but created by the user.
Deleting the lot would usually be a bad idea.

Deleting seemingly redundant ones may also be a futile exercise as the programme will simply regenerate them when it starts up again.

I prefer the phrase "what a load of old bollocks" for such occasions...

I "hand built" most of my x86 based systems from the various intel/AMD i686 based machines in the mid 90s to the present date.  It didn't make them any quicker than an off the shelf OEM system, but it did make them cheaper (back then it was) and more flexible in terms of hardware.

Sadly these bloated masses of C++ (or "rust") are what most people need to access the web.  If you've ever built firefox or worse still chromium from source, you'll know what I mean.  Yes I can use a basic browser with no javascript support to access a few forums, I can even use elinks or lynx or whatever, but can you pay your bills, shop online or do your online banking...?

It's neither "consumerist" not "propaganda"...  Linux itself has also become "consumerist" - you essentially have free software, released under free copyleft licences - but all financed and coordinated by fortune 500 companies...  the webkit and blink layout engines also happen to be corporate sponsored.  But not being of "Cupertino" or "Redmond" origin no doubt that doesn't count...

I don't think "reviews" of this kind, what I'd term "tech press" reviews, are worth a lot (In fact it's arguable if distrowatch has any real value...).  The reviewer talks about what he can install, how easy things are, the environment, applications, etc - all from the perspective of a consumer...

Surely when discussing a so called "lightweight" Linux derivative distribution, it's necessary to look at why it claims to be "lightweight" and to see if the claims have an basis at all?

When it comes to Debian and so called derivatives, it's usually down to sticking one's own customised desktop experience on a livecd - the earliest derivatives, such as Ubuntu, started out as this kind of thing.

"Lightweight" then usually means, much the same thing with a window manager and "less" installed".  The overall memory footprint, kernel, resource usage, etc is is never examined in any real depth in these kind of reviews.  In fact once the end user installs the packages they need, "light" is pretty much over and done with at that point.  Firefox, for example consumes huge amounts of memory and CPU.  You could install any lightweight Linux distribution with a basic window manager and still find your creaking hardware is not up to the job of running a modern browser.

And as the comments pointed out, the reviewer doesn't even test on old hardware or discuss performance...

And then it comes back to  - just how useful is very old hardware anyway?  The answer is: not very.  If you have something with around a 2GHz clock and a few GB of RAM you have usable "old" hardware.  At this point what Linux distribution you install doesn't really matter so long as you don't expect the latest KDE or gnome to perform (at all).

The ~ 1GHz and 1GB of RAM era hardware and older, is sadly just not up to the job.

For an old PC from this era you could try installing something like NetBSD or OpenBSD and using as a router, access point, firewall, etc...

I don't think looking for the grep'ing for the string "systemd" is going to to yield anything useful.

/etc/systemd, /lib/systemd and /var/lib/systemd are directories.

Anything in /usr/share/man/ is irrelevant as are the lintian files

/lib/systemd/system/* seems like files (services?) relating systemd/udev?

None of the above are binary as far as I know.

The only binary is libsystemd0, which is essentially useless cruft without systemd installed.

I suppose it's the same with any package, you get cruft which relates to software you don 't use and don't install.

udev is, of course, part of the systemd source.

That's often the case with assumptions.  Qt, as with many so called "open Source" projects, has corporate entanglement and allows commercial licensing.  However...

It's important to understand how dependency resolving package managers work.  Debian's in particular is a complex mass of dependency chains, with fragmented packages (usually one source package builds many smaller packages, rather than one big binary package), meta packages, dummy packages, etc.  It's designed to pull in and resolve all dependencies for all use cases, it's not designed to make ideological decisions, for example it's not going to cater to people who don't like gnome or don't like software from a certain developer - and as you're mixing repositories it's not surprising that things don't work as intended.  And as Debian is to all intents and purposes a systemd (+gnome) distribution, it's no surprise at all that it pull in systemd.

It's the second one - a Debian (or distribution specific) issue.  The dependency chain will "link back" to, mostly freedesktop.org, userland components which will link to systemd userland components, which in turn pull in systemd itself.  This is because packages were built with systemd flags enabled and so in order to produce a working system for everyone, those systemd depencencies have to be listed in the package's control file.

The Debian approach to leaving out systemd is to run it with systemd-shim as far as I know?  This means it's acceptable to install systemd in all cases, but not run it as the init daemon ("PID 1") if the user has installed a different init system (this is probably what equates to 'init choice' for some).  This is why your mixture of Devuan and Debian unstable, while it works for now, will ultimately fail.  You will - at some point - hit a nasty broken dependency, where the only solution is some in depth 'package management foo'.

Rather than installing stuff from Debian's unstable branch, I suggest that you might be better off porting the newer upstream releases of your top favourite software over to Devuan (building from source and packaging them).  This allows better control over dependencies - especially with respect to systemd - installing binary packages from another distribution gives you no control at all.

Of course.

Well generally, one would:

# apt-get build-dep tint2

Make a "build" directory in your /home/your_user

$ apt-get source tint2

Then build the deb package from the source in the usual way (dpkg-buildpackage in a fakeroot environment).

Once the package is built, the build dependencies (dev packages) can be removed.

gNewSense is an FSF sponsored project which predates systemd and has very specific goals and is very much driven by ideology.  It's easy to see why the Devuan people didn't decide on just "joining" that one.

Also gNewSense (or indeed FSF/Stallman) doesn't seem to have any specific goals or opinions regarding systemd.  It's not a given that future releases of that Linux distro won't just include systemd once it becomes the expedient choice.  (the focus there is more on removing device firmware from the Linux kernel so as to make hardware, which should run out of the box, unusable).