Why not start by enabling some logging and doing at least basic troubleshooting yourself? All I see here is "it stopped working".
Use of log files is in the daemon manual, and the very least, try the same command you're using in xinitrc manually and see if it's throwing any errors on stdout/stderr.

Nobody is psychic, and that debian bug report is so devoid of information as to be practically useless. Are you really running sid/experimental? If so, you should be prepared for random borkage and prepared to do some digging... That's why it's called "experimental".

And no, no I'm not going to look into this hose any of my systems by enabling the sid or experimental repos. If you want an install that doesn't regularly break after package updates, run stable (and backport things you want from sid yourself).

Pretty much all of the above are questions specific to your particular machine, unless someone here has that exact model the best you will get is generic guesswork.

The ICH7 (best guess at the IO controller in this machine without one to play with) datasheet suggests SATA2 @ 300MB/s.
To determine current negotiated SATA link speed, boot linux and look in dmesg.
Even if the chipset is only SATA1, you'd still benefit from going to an SSD. Few mechanical laptop drives can really sustain 150MB/s, and none can beat an SSD when it comes to seek time. Any modern SATA drive should be backwards compatible with whatever the chipset supports.

AFAIK the only real limitation that applied in 2006 was 2TB. Most BIOS implementations from the time will actually work with larger drives, you just won't be able to address the rest of the space.

DDR2 SODIMMs are cheap and widely compatible. Your best bet is to just buy some and try them.

There's usually no need to go after "branded" modules or those specifically mentioned in the manual, you just need supported technology, voltage, and (rarely an issue with desktop/laptop modules) buffering and number of ranks. Faster is always better, assuming 667MT modules aren't rare and at a premium price.

Considering the item value, no ebay seller is going to know, care about, or make any effort to investigate compatibility with some random laptop from 2006.

At the least, it'll cause drive auto-detection to run and probably trigger an ESCD update. As for why it hangs on first-boot... Laptop BIOSes are weird and often buggy. Always have been, probably always will be.
Be thankful you don't have to deal with "system configuration changed, insert reference diskette" any more

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.