AFAIK aptitude can't install from a file, but apt/apt-get has supported this for years. It'll even resolve dependencies for local packages (but not using local packages, at least not automatically, same as dpkg).

Power-profiles-daemon is expected to be started on-demand via dbus activation... Which is obviously only going to work with systemd.
If something is trying to start it that way, you'll see errors to the effect of "nothing provides the net.hadess.PowerProfiles name on dbus" or somesuch.

On Gentoo we have an (openrc) init script to start PPD explicitly at boot, but Devuan appears to be doing the usual "just pull from Debian & don't bother to check it works properly" thing Devuan does, so the package only contains a systemd .service definition.
If you want it to work, you'll probably have to write a sysv init script for it yourself or come up with some other way to start it on demand.

As for TLP, TLP does far more than PPD, but it's more work to set up and isn't (currently) integrated into the major (GNOME, KDE) DEs.
It works fine for my needs on the one ancient laptop I have ever bothered to own though, same as it always has.

By manually copy-pasting the text and the username like it's 1999, because golinux childishly disabled the quick-quote functionality some time back on account of a few users excessive use of it annoying him.

The full quoting annoyed a few (or more accurately, one) people. Removing the quick-quote links creates extra work any time a quote is warranted, and removes such niceties as timestamps and back-linking to the quoted post.

Most (if not all) 64bit systems should still be able to boot the 32bit install media (at least in legacy/CSM mode). Even if the live kernel won't boot for some reason, you should still at least get to the boot menu.

In any capable and half-way modern board software, the post editor has a "disable BBCode" checkbox. This one apparently does not, having it as a global toggle reserved for administrators... Which you are, and so should know.

I never said anything about capability. One can be the best programmer in the world, and still behave like an asshole.

Much of Lennart's code is excellent, some of it is even a good idea... The attitude exposed by his (and various other obvious parties as well) continual attempts to force everyone to get in line and do things according to "the plan" for GNU/Linux is that of an asshole.

His comments are replete with "I know best, do as I say" sentiment, and examples of "force x to do y, because it's the my future" are not at all difficult to find.
Usually these boil down to "Gentoo is resisting again, assimilate harder", or "Let's make not doing things our way as annoying as possible", while still waving the "it's open source, change it if you want" flag.

The headline is a garden-variety example of the latter. Doubtless any upstream bug reports or patches will be closed wontfix, with the usual "it's open-source, fork it if you really care that much"... Knowing full-well that this sanctimonious "taint" message is not quite annoying enough for anyone to actually do so.

Ordinarily all this would be a simple case of "dev is a twat, ignore", but he has unfortunately sold his ideas well enough to big corporate (IBM, Microsoft, etc.) that they now see them (systemd in particular) as the leverage they have always wanted to gain control of systems-level GNU/Linux development.

Much of the current direction within systemd is toward "trusted" computing, immutable operating systems, and homogenising the GNU/Linux landscape... These things sound like they are for the benefit of the end-user, but the natural end product - the computer as a cookie-cutter "secure" (for them) appliance, controlled by the vendor - is a holy-grail for big IT.

Uhh, sure... If you've been living under a rock for the last couple of decades. systemd does just a mite more than "registry" (a title better handed to the likes of, say, gconf) these days.

A non-booting kernel or broken driver really isn't a big deal, and frankly I have no idea why people seem to get so flustered by it (see recent Debian drama WRT out-of-tree nvidia driver "completely breaking" systems).
Pretty much every distro keeps old kernels around (and generates bootloader entries for them) for exactly this scenario.

Even without that, you can just boot a livecd/usb and set root= appropriately or chroot in. Unless one is silly enough to encrypt / and not keep a record of the key OFC... Or use secure retarded-boot, but that's really a bootloader issue and only makes using live media more annoying.

FWIW, pipewire works just fine with fluidsynth (via ALSA sequencer port) here, and on every distro I've used that packages those.
Timidity OTOH, AFAICT has been pretty much a zombie project since 2004.

How is this news (or "myth", "legend", "the truth", "nightmare", other infantile hyperbole in your link), or even particularly useful (beyond embedded systems with miserably small storage)?

Yes, you can compile in all the drivers you need and boot without dynamic /dev or early module loading. That's how it was done when compiling your own kernel was normal practice and booting from a floppy disk was a thing.
It's still quite possible to go that way, assuming you know what drivers you need to mount root. Systemd might make life difficult, but that's nothing new either.

I still have a bunch of Slackware 7 boot disks on my desk, and besides needing to pick the right one for your hardware (because that's the price for no initrd and a 1.4MB kernel), there's nothing particularly fun or novel about them... They're just minimal kernel images with disk controller and filesystem drivers compiled in.
So what? I mean it's trivial to boot even modern Slackware without an initrd, why the big writeup? That "guide" makes it sound like the dude just rediscovered fire or something

Using unmaintained binaries from removed packages in scripts is the antithesis of "just forget about them". Sooner or later gksu will break (especially being GUI bloat linked against GTK), if you want reliable scripts use a supported method like pkexec.

If you must use gksu, at least port it properly (i.e. rebuild it against current libraries) rather than pulling in binary packages from an old release.

A thouroghly terrrible idea, as is using any other TUI or GUI file manager for this. Use rsync or plain cp, in archive mode or with explicit --preserve= parameters.

No kidding. Of course you need root.

Yeah, don't do that either, unless you want to completely bork permissions.

That post details using 'cp -a' to copy files, not mc.

The easiest way to fix this is almost certainly just copying the system again, this time with the right tools and options. You did make and test a backup before starting, right?
Personally I suggest using rsync from a liveCD/USB, or at least single-user mode so there aren't too many open files. Then run it again so it can verify the copy is correct.

You started this @Zapper, with your "bumbling morons" comment. If you expect to be treated with "decency", first try being decent yourself.
Your ongoing tendency to throw gratuitous insults at anyone and anything you perceive as an out-group or an "organisation" is infantile and irritating.

The developers behind Mullvad owe you nothing, and have done nothing to deserve your bile. They provide you software, gratis, and even go so far as to host repositories of debian packages. What exactly have you done for the FOSS community, besides whine?

IME most of the time this kind of thing isn't really about control, it's about liability (at least in the corporate world).
If a company contracts an external provider to handle endpoint protection, veeps who know nothing about IT get to tick their "all practicable steps to protect customer data" and "certified industry standard solution" boxes. If anything goes wrong they can just point at (and potentially sue) $external provider, with no risk of blowback.
The bigger and more widely known the provider, the harder they can lean on the "industry standard" "we're doing what everyone else is doing" angle.

This is how we end up here, not because of some grand conspiracy (not to say they're not out to get you, mind) but because big IT knows they can exploit human laziness and risk-aversion for profit, and their corporate customers often like dealing with a monopoly because of the "safety in numbers" effect.

As for "cloud" more generally, my answer (both personally and professionally) is "go away"... Unless the rep brought biscuits, in which case I'll pretend to listen while I eat them*. It simply does not and can not meet my reliability, serviceability and redundancy requirements.

I don't like surprises, and if I really do need to call somebody at 3am to figure out why a critical system isn't working, I expect the answer to be "I'll be on site, with parts, in 30 minutes" not some phone droid with "looks like $cloud whatever is down, better file a ticket".
'tis the same reason I prefer hardware solutions over inscrutable software "fixes", and local contractors over megacorps with 15 layers of bumbling bureaucracy between their technicians and reality.

*the biscuits, not the rep... Though the reverse is often tempting.