MX Linux Forum

Posted: **Fri May 23, 2025 10:00 am**

I've been putting together an older Toshiba with an AMD e-300 apu, a pathetic apu from the day it was manufactured. Going to Dreamer's LXQT respin helped a lot, and I thought I finally had a decent system working.

Then this morning I fired it up for a final check, to find that performance was on the edge of not acceptable. I pondered why this was, and then finally I remember a change I had made late the night before. I went into MX Boot Options and specced Systemd.

So I rebooted, this time with sysvinit, and I was back to my working system again. I would guess the performance was 35-50% better on average.

I did a little research, and it seems this is a problem on some, not all, older hardware, Something to be aware of.

Posted: **Fri May 23, 2025 10:16 am**

It's generally known that there is at least a slight performance hit when using MX with SystemD on any system regardless of age or complexity.

Posted: **Fri May 23, 2025 10:51 am**

j2mcgreg wrote: Fri May 23, 2025 10:16 am It's generally known that there is at least a slight performance hit when using MX with SystemD on any system regardless of age or complexity.

Hmm. In my work, I'm extremely performance conscious, and I didn't notice anything when switching to mainlining systemd some months ago. Granted, I'm not exactly running MX, but a specialized version of it with some quite different innards, and running threaded interrupt handlers, and so on. Nevertheless, this is intriguing and makes me pretty curious if there's some benchmark data available? "Regardless of age or complexity", hmm.. What areas of operation suffer a performance hit in stock MX when running systemd, and how? As in, what is the context of the "performance hit" in this case? (General processing / FPU calculation resources? General system responsiveness / latency? I/O, startup/shutdown, some specific tools like some particular known applications or the MX tools suite or other? Can the cause be pinpointed and has it been measured?)

Posted: **Fri May 23, 2025 10:55 am**

> What areas of operation suffer a performance hit in stock MX when running systemd, and how?

In my case it was all manner of sluggishness, from playing a video from YT at constant 95%+ CPU to clicking on a program close button and waiting 20+ seconds for it to disappear. The machine was borderline unusable.

Posted: **Fri May 23, 2025 10:56 am**

paul1149 wrote: Fri May 23, 2025 10:55 am In my case it was all manner of sluggishness, from playing a video from YT at constant 95%+ CPU to clicking on a program close button and waiting 20+ seconds for it to disappear. The machine was borderline unusable.

Yeah, that sounds like an extreme difference. Would be interesting to know the cause. (My very broad guess would be, the chip is so old, with only two concurrent threads to run stuff on, it can't cope with some particularly heavy hitting service parallelism. With old 1-2 thread systems like that, the way background tasks are scheduled, and what kind of background/maintenance jobs the system is set to launch and when, becomes a big deal.)

Posted: **Sat May 24, 2025 7:25 am**

I don't really notice a huge impact running systemd it has to be said on my 2009 potato, it even boots a second faster;) Also, how much/type RAM do you have? Systemd is more memory hungry, you're system may be overly depending on a swap? (cough QSI would help here) What secondary storage is it HDD or eMMC? I have found I/O is sometimes the bottleneck rather than the CPU.

Posted: **Sat May 24, 2025 7:31 am**

4GB, 7200rpm hard drive. Swappiness untouched.

Here you go.

Code: Select all

System:
  Kernel: 6.1.0-33-amd64 [6.1.133-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-33-amd64 root=UUID=<filter> ro quiet splash
    resume=UUID=<filter> resume_offset=780288
  Desktop: Xfce v: 4.20.0 tk: Gtk v: 3.24.38 info: xfce4-panel wm: xfwm v: 4.20.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.6_x64 Libretto April 13  2025 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Laptop System: TOSHIBA product: Satellite C855D v: PSCBQU-00600J
    serial: <superuser required>
  Mobo: TOSHIBA model: Portable PC v: MP serial: <superuser required> UEFI: Insyde v: 6.00
    date: 08/21/2012
Battery:
  ID-1: BAT0 charge: 44.1 Wh (100.0%) condition: 44.1/47.5 Wh (92.9%) volts: 10.8 min: 10.8
    model: PA5024U-1BRS type: Li-ion serial: <filter> status: full
CPU:
  Info: model: AMD E-300 APU with Radeon HD Graphics bits: 64 type: MCP arch: Bobcat level: v1
    built: 2011-13 process: GF 40nm family: 0x14 (20) model-id: 2 stepping: 0 microcode: 0x5000119
  Topology: cpus: 1x cores: 2 smt: <unsupported> cache: L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB
    L2: 1024 KiB desc: 2x512 KiB
  Speed (MHz): avg: 780 high: 781 min/max: 780/1300 boost: disabled scaling: driver: acpi-cpufreq
    governor: ondemand cores: 1: 781 2: 779 bogomips: 5191
  Flags: ht lm nx pae sse sse2 sse3 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines; STIBP: disabled; RSB filling; PBRSB-eIBRS: Not
    affected; BHI: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Wrestler [Radeon HD 6310] vendor: Toshiba driver: radeon v: kernel
    alternate: amdgpu arch: TeraScale-2 code: Evergreen process: TSMC 32-40nm built: 2009-15 ports:
    active: LVDS-1 empty: HDMI-A-1,VGA-1 bus-ID: 00:01.0 chip-ID: 1002:9802 class-ID: 0300
  Device-2: Importek TOSHIBA Web Camera - HD type: USB driver: uvcvideo bus-ID: 2-4:2
    chip-ID: 10f1:1a43 class-ID: 0e02
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.20.0 driver: X: loaded: radeon
    unloaded: fbdev,modesetting,vesa dri: r600 gpu: radeon display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 362x204mm (14.25x8.03") s-diag: 416mm (16.36")
  Monitor-1: LVDS-1 mapped: LVDS model: LG Display 0x033a built: 2012 res: 1366x768 hz: 60
    dpi: 101 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5") ratio: 16:9 modes:
    max: 1366x768 min: 640x480
  API: OpenGL v: 4.5 Mesa 22.3.6 renderer: AMD PALM (DRM 2.50.0 / 6.1.0-33-amd64 LLVM 15.0.6)
    direct-render: Yes
Audio:
  Device-1: AMD Wrestler HDMI Audio vendor: Toshiba driver: snd_hda_intel v: kernel bus-ID: 00:01.1
    chip-ID: 1002:1314 class-ID: 0403
  Device-2: AMD FCH Azalia vendor: Toshiba driver: snd_hda_intel v: kernel bus-ID: 00:14.2
    chip-ID: 1022:780d class-ID: 0403
  API: ALSA v: k6.1.0-33-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8188CE 802.11b/g/n WiFi Adapter driver: rtl8192ce v: kernel modules: wl
    pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 02:00.0 chip-ID: 10ec:8176
    class-ID: 0280
  IF: wlan0 state: up mac: <filter>
  Device-2: Realtek RTL810xE PCI Express Fast Ethernet vendor: Toshiba driver: r8169 v: kernel
    pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 2000 bus-ID: 06:00.0 chip-ID: 10ec:8136
    class-ID: 0200
  IF: eth0 state: down mac: <filter>
Drives:
  Local Storage: total: 232.89 GiB used: 13.63 GiB (5.9%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: Hitachi model: HTS725025A9A364 size: 232.89 GiB block-size:
    physical: 512 B logical: 512 B speed: 3.0 Gb/s type: HDD rpm: 7200 serial: <filter> rev: C72E
    scheme: GPT
Partition:
  ID-1: / raw-size: 232.63 GiB size: 227.92 GiB (97.97%) used: 13.63 GiB (6.0%) fs: ext4
    dev: /dev/sda2 maj-min: 8:2
  ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%) used: 274 KiB (0.1%) fs: vfat
    dev: /dev/sda1 maj-min: 8:1
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 5.42 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 52.1 C mobo: N/A gpu: radeon temp: 52.0 C
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 2139 libs: 1066 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/brave-browser-release.list
    1: deb [arch=amd64 signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg] https://brave-browser-apt-release.s3.brave.com/ stable main
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mirror.math.princeton.edu/pub/mxlinux/mx/repo/ bookworm main non-free
Info:
  Processes: 180 Uptime: 1h 6m wakeups: 2 Memory: 3.42 GiB used: 1.11 GiB (32.6%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

Posted: **Sat May 24, 2025 8:18 am**

OK, specs seem fine, respectable even, if you're not too snooty. I have a similar system with slightly higher clocks (e-350), It is currently running Windows 10 32bit! (though it is actually 64 bit capable) It's certainly not pretty, quite sluggish, but just about usable, as long as updates/defender isn't running in the background and I set the resolution to 1366*768. It can process fullHD video h.264 too. If it can run Win10 I'm sure it can eat MX. As bad of an early APU as it was, it actually outperformed the Intel Atoms it was designed to compete with.

Have you eliminated the possibility the CPU is throttling due to overheating issues? Thermal paste might need changing after all this time. Have you run SMART tests on your hdd?

I find it's modern web standards that are the biggest roadblock for older hardware. For instance, the newer video codecs that YT uses require a lot of CPU cycles to decompress. In fact, I use FreeTube and select legacy formats/codecs to get around this. Also the load by the sheer number of network connections that are made when accessing even a single website as it accesses resources/ads from all over the web, the other problem I have is with websites with irresponsible JavaScript workers that seem to background run even when doing nothing noticeable. Using script blockers helps here, or setting your browser to aggressively sleep inactive tabs.

I'm curious @paul1149 how does it perform when offline eg. Libreoffice, scrolling through rich pdfs etc?

Posted: **Sat May 24, 2025 8:43 am**

The temperature is fine. If it runs at high cpu for a while the keyboard is slightly warm, but not hot. The hard drive at the least passed SST, maybe more, not sure, but that's not a factor anyway, I believe, because it was the same hard drive for both sysd and sysv.

Ironically this unit had W10 home on it, and performed not catastrophically badly. But I was unwilling to go through the interminable 4.5GB windows upgrade. So I went to MX, assuming would be a cakewalk. But MX under SysD actually did worse than W10! I was perplexed until I made this discovery.

Now I'm tempted to go back, at least via usb boot, and see how xfce does without SysD on the machine.

I agree about javascript and web standards. Many tabs on the latest Vivaldi "shimmer", as they apparently never fully load. This very tab, here, right now, was fluctuating between 6 and 16% cpu on my Ryzen system. I was tempted to put NoScript on the laptop, but the guy I'm building it for probably would be lost with it. I chose firefox for the system because, surprisingly, it did better on resources than Brave or even PaleMoon. FF does hibernate tabs, but gives you no control over it. I will take a look at freetube -thanks.

The problem wasn't related to being online. All windows performed extremely poorly.

Posted: **Sat May 24, 2025 10:43 am**

paul1149 wrote: Sat May 24, 2025 8:43 am But MX under SysD actually did worse than W10! I was perplexed until I made this discovery.

I was hoping to migrate my e-350 to MX too when W10 is EoL. Bit worried now

. If you don't mind a bit of fan noise (and warm fingers), have you thought about changing the CPU governor? Those bobcat APU's are dog-slow, I won't lie, but the default 'OnDemand' governor in MX doesn't flatter it at all. If you switch to a performance profile you will notice an improvement in responsiveness at least.

Posted: **Sat May 24, 2025 11:09 am**

@retroD0d0 wrote:

I was hoping to migrate my e-350 to MX too when W10 is EoL. Bit worried now

Try booting it into a live session so you won't affect your Win 10 install. You'll know in a hurry whether it's performance is acceptable.

Posted: **Sat May 24, 2025 2:03 pm**

j2mcgreg wrote: Fri May 23, 2025 10:16 am It's generally known that there is at least a slight performance hit when using MX with SystemD on any system regardless of age or complexity.

@j2mcgreg, see my previous post about this. If it's "generally known" MX performs worse when the init system is SystemD, regardless of hardware, it would be nice if you (or someone else in the MX team) could comment on it a bit more. What does a "performance hit" mean in this context, what kind of use, and what areas of operation are effected? Are there any technical stats/info on this available, and so on.

Posted: **Sat May 24, 2025 2:49 pm**

retroD0d0 wrote: Sat May 24, 2025 10:43 am If you don't mind a bit of fan noise (and warm fingers), have you thought about changing the CPU governor?

I wasn't aware of that. Cool. It is set to on-demand. I'm loathe to push it further, at this time anyway, but I will keep this gem in mind. The cpu has three frequencies, 780khz, 1.1mhz, and 1.3mhz. It doesn't take much to send it to level 3.

Posted: **Sat May 24, 2025 3:00 pm**

@retroD0d0 , I did a little digging, and the schedutil level sounds very interesting. It sounds almost as strong as Performance, but willing to step down when unneeded.

Brave AI tells me:

Linux CPU Governor Levels

The "schedutil" governor in Linux aims to better integrate with the Linux kernel scheduler, allowing for dynamic frequency scaling based on system load It is designed to optimize CPU performance and power consumption by coordinating closely with the scheduler to determine the appropriate frequency for each CPU core This governor is increasingly becoming the default for many distributions, especially for AMD hardware

For AMD processors, the "amd_pstate" driver supports three operation modes: CPPC autonomous (active) mode, CPPC non-autonomous (passive) mode, and CPPC guided autonomous (guided) mode. The default mode is active, which can be changed with the kernel parameter `amd_pstate=active`, `amd_pstate=passive`, or `amd_pstate=guided`

In a comparison of the "schedutil" governor with the "performance" governor on a patched Linux 5.11 kernel, the performance governor was found to be just over 1% faster on average, but the difference was not significant in most workloads

To check the current CPU governor, you can use the `cpupower frequency-info` command or inspect the `/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` file in the sysfs virtual file system

* Schedutil: Aims at better integration with the Linux kernel scheduler, optimizing CPU performance and power consumption
* Performance: Provides a constant high-performance state, often slightly faster than "schedutil" but with less power efficiency

Posted: **Sun May 25, 2025 6:43 am**

paul1149 wrote: Sat May 24, 2025 2:49 pm I'm loathe to push it further, at this time anyway,

I understand, my e-350 is actually in a nettop on a cabinet connected to a TV. At that distance, noise isn't an issue and the unit has a capable fan. The APUs (e-300/350) are only 18W TDP. However, with a laptop, the increased noise and heat can distract when it's under your fingertips. Good luck experimenting!

j2mcgreg wrote: Sat May 24, 2025 11:09 am Try booting it into a live session so you won't affect your Win 10 install. You'll know in a hurry whether it's performance is acceptable.

Thx, and yes. I will of course.

Nokkaelaein wrote: Sat May 24, 2025 2:03 pm @j2mcgreg, see my previous post about this. If it's "generally known" MX performs worse when the init system is SystemD, regardless of hardware, it would be nice if you (or someone else in the MX team) could comment on it a bit more. What does a "performance hit" mean in this context, what kind of use, and what areas of operation are effected? Are there any technical stats/info on this available, and so on.

Hi, I'm guessing no formal quantative analysis has been done on the performance delta between both init systems on MX. Actually I wasn't aware it could be such an issue but it might go some way to explaining why MX is so, subjectively speaking, performant on older hardware. Maybe a thread where people post their benchmarks in both modes could be informative? How/What to benchmark I am unsure yet.

Posted: **Sun May 25, 2025 7:25 am**

retroD0d0 wrote: Sun May 25, 2025 6:43 am Hi, I'm guessing no formal quantative analysis has been done on the performance delta between both init systems on MX. Actually I wasn't aware it could be such an issue but it might go some way to explaining why MX is so, subjectively speaking, performant on older hardware. Maybe a thread where people post their benchmarks in both modes could be informative? How/What to benchmark I am unsure yet.

A benchmarking thread would be informative. My interest was piqued, I mean, if a forum staff member says it's generally known that there is some kind of performance hit in the distro on any system regardless of age or complexity, this comment must be based on some actual known data, right? So regardless of system age or complexity, in what use and in what way is there such a hit, and how can it be observed on any system. That's what I'm getting at. If it's generally known, then it can also likely be more specifically described and defined. Having used MX based systems for years, this kind of stuff is interesting to me, and if it's brought up in a general sense, a more detailed description would be nice.

Posted: **Sun May 25, 2025 8:22 am**

Nokkaelaein wrote: Sun May 25, 2025 7:25 am if a forum staff member says it's generally known that there is some kind of performance hit in the distro on any system regardless of age or complexity, this comment must be based on some actual known data, right?

I think he may have been giving his considerable experience gleaned from moderating the forums. We can't expect someone who is responsible for chaperoning community discussion to be intimately familiar with technical issues related to development. That would be something for the dev team themselves. Also, we can't assume this to be a particular priority for them either, especially given a conclusive opinion already appears to have been formed.

Yes, MX being the only distro of it's kind to offer dual init functionality offers the ideal opportunity to be a testbed for assessing init system performance impact, as in either mode, apart from the init systems, all factors remain identical (I think?) and therefore it presents a controlled environment to do fair testing.

If there is one thing I have learned using Linux, especially with a community distro, is that we can't expect this work to be done for us. We may have play our part ourselves! Hence why I suggested one of us in the community start a thread to gather some tangible data on the subject.

Posted: **Sun May 25, 2025 12:46 pm**

My $0.02. We have two init systems available with MX and while they are both exceptionally fast, one of them is going to be faster. That's just the way it is. For most people the difference will be almost imperceptible or they just won't care. For the rest, I say that there are bigger things in Linux to get busy about.

Posted: **Sun May 25, 2025 2:05 pm**

I've got to say I'm perplexed at this machine. Everything was working well. I shut it down for the night, then the next day, with no changes having been done, it was back to it messed-up self again. It was restless, at war with itself, seldom dipping below CPU 15%. The mouse pointer was jerky and imprecise. Programs took long to close, or wouldn't close on mouse click. (It did close instantly via panel menu, but unplugging the mouse changed nothing, so I don’t think it's the cause.). All this was under SysV, not SysD.

Online advice said to reinstall a certain xorg service library. I went to, and found it wasn't installed, so I installed it. I also did a full update, consisting of 5 items. The last item, I saw, was a kernel update, to 6.1.x.37. Fine, I thought, maybe it will help. But the install froze at 76%. When I tried it in MXPI, the new kernel was not to be found. (it's currently on xxx.35)

Now the machine wouldn't shut down, kept delivering me to the login screen, so I forced it down. On reboot, that problem disappeared. And so did the CPU problem. Everything was perfect. Immediate regression to 1% CPU, perfect mouse, etc. I thought the updates had solved the problem. Even took another snapshot.

On the next reboot, the problem was back. At this, I turned my attention to the hardware. But the drive checked out good on a Long test. I changed the RAM. No difference.

At this point I would have to say that the problem probably isn’t related to Systemd after all. My next move may be to try this snapshot on another unit, if it works that might indict something in this hardware.

Posted: **Sun May 25, 2025 2:25 pm**

With that old of a hard drive ( 13 years - or more.. unless you have replaced it or seen a different date ) , I think you are seeing the beginning of hard drive issues.

My experience with Hitachi drives is that they do not show any indication of failure... until they fail. They *may* start having trouble finding / loading files, before they go, and this sounds kind of like that. (ie loading one time good, another time badly.etc)

I would try a small, fast ssd in that machine and see if it acts better.

Posted: **Sun May 25, 2025 2:33 pm**

That's a good idea. I have an ssd that I can use.

The only thing I noticed was that all Short and Long tests on the HDD did not register the hours-age (around 4400 hrs, IIRC) of the drive, only zero.

Posted: **Sun May 25, 2025 2:45 pm**

Ya, but I cannot tell you how many drives I have had "pass" testing and then when I swapped them out the issues I was having went away.

Posted: **Mon May 26, 2025 8:32 am**

Ok, here's what I did. I found a 5400rpm HD with only 234 hours on it, so I used that. Installation was very slow, maybe 40 minutes. Once up everything was great. FF played video at about 75% CPU, FreeTube played it at 55%, which is excellent for this machine.

I did the updates, and the 6.1.x.37 linux-headers again appeared, this time they installed fine. The machine is not fast due to the HDD, but it is smooth.

And so this morning I booted again, it defaulted to the .37 kernel, but this time I chose SystemD. Absolute disaster. Jerky mouse, CPU never resting, performance terrible.

Booted back to .37/SysV, and it's smooth as glass again. Idling at 1-3%.

So, tentatively, it seems I had a compound problem – a hard drive on the way out, and systemd incompatibility with this machine - and that made it tricky to square root. I will have to put it through a few more cycles to be sure. The hard drive problem was well-concealed, because I had been through three of them trying to get this machine to work, and I thought surely all three couldn't be bad, right? Wrong.

I still may throw an SSD in there, just to see what the machine wants to be. But the guy I'm donating it to is not able to spring for an SSD at this time.

Posted: **Mon May 26, 2025 10:37 am**

paul1149 wrote: Mon May 26, 2025 8:32 am compound problem – a hard drive on the way out, and systemd incompatibility with this machine
I still may throw an SSD in there, just to see what the machine wants to be. But the guy I'm donating it to is not able to spring for an SSD at this time.

Compound problems are second only to Intermittent faults when it comes to infuriating issues in general.

Glad you have a usable machine at least. I should mention that, on my E-350 system, I did install an SSD; which goes a long way to improving loading/booting times and general responsiveness.

Posted: **Mon May 26, 2025 10:47 am**

Sounds like your making great progress! Great job there!

You can pick up quality, smaller SSD's for under $20 at amazon. I usually pick up one of the following if I am donating machines and dont have any spare / used SSD's.

https://www.amazon.com/Lexar-NS100-128G ... B07TKGGJ1T
https://www.amazon.com/Western-Digital- ... B076XWDN6V
https://www.amazon.com/PNY-CS900-250GB- ... B07XZLW68F

Posted: **Mon May 26, 2025 8:34 pm**

@CharlesV Thanks!

I think I can confirm now, after several boots, that the problem is solved. It's running just about perfectly. It really would be sweet with an SSD, but that's out of my hands for now.

Thanks to all for the insight and guidance. And @retroD0d0, FreeTube is a winner. Newbies can even use it to download YT.

Posted: **Tue May 27, 2025 1:07 am**

paul1149 wrote: Mon May 26, 2025 8:34 pm @CharlesV Thanks!
FreeTube is a winner. Newbies can even use it to download YT.

Bear in mind it doesn't use the YT API like Official app and SMtube, it scrapes the website. You can't sign in and like and subscribe. comment etc, The 'subscribe' option is actually more of a bookmark.

@paul1149
It was an interesting to hear how much impact you remarked switching to systemd. Out of interest, have you tried running MX service manager in both modes and compared the number of total background services? It's eye-opening.

@Nokkaelaein has a good point, it is an area worth researching because if we know the specific bottlenecks we may be able to optimise for older hardware with minimal loss of functionality.

For me. running on old hardware, I have felt three things makes mine so lean, snappy and usable, sysV, antiX kernel and XFCE.

MX Linux Forum

Systemd on (some) older hardware

Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware

Re: Systemd on (some) older hardware