Blaster M

It does, as DDR5 comes with rudimentary ECC protection builtin.

My problem is this is an AM4 system using DDR4 memory… already outdated.

“But daaad, I wanna be a three phase”

Well it definitely isn’t Chicago

Yeah, it’s quite the Poison to experience.

DHCP, when set up properly, makes for less work. Reservations will have the DHCP server hand out the same IP to the same hardware (MAC address) when it asks. If you have a device that is from the dinosaur age that doesn’t play nice with DHCP, then make sure you give it an address that is outside the DHCP range on the same subnet. ex: Some home routers use 192.168.1.100 to 192.168.1.200 as the dhcp range. Setting anything from 192.168.1.1 (or 2 if the router is on 1) to 192.168.1.99 is fine, as is 192.168.1.201-192.168.1.254 (or 253 if the router is on 254). However, by setting static ips, you have to remember those ips specifically to interconnect devices on the lan, whereas reserving via dhcp allows you to use local dns resolution to connect to devices via their hostname instead. In additon, you run the risk of ip conflicts from forgetting which device has what ip in an increasingly complex system, and if you change internet providers or routers, you have a lot of extra work to do to fix the network settings to get those static ips to connect.

Alternately, just use the link-local ipv6 address to interconnect on the lan. That doesn’t change on most devices, as it is based on the MAC address, and is always reachable on the lan.

But then the other image format would have to be prounounced JPEJ

Meanwhile in Fedora KDE, I have the opposite problem… The system straight up ignores my monitor sleep settings, and something as quick as grabbing a water and coming back to everything in sleep mode on a desktop is kinda a problem when I am relying on the system not going sleep due to a running task.

Here’s the deal. If your server is close to using up all its RAM, then yes, more RAM better.

However, if your server is close to being full on storage, you need to address that with a bigger storage drive.

Yeah no, I’ve used Slackware back in the day… there is no getting back the whole weekends lost chasing dependencies and build dep reqs.

Looks like I need to consider flipping back to Debian again… it’s always beeen a Stable relationship…

Everywhere except in the USA’s Republican states. It’s an unforgiveable sin to be seen with a mask on there for stupid reasons.

I would that too

Pretty much… as long as you didn’t do any custom kernel stuff or driver blacklisting or any other underhood voodoo with the boot system.

That only matters if there’s anything to optimize by source compilation. If the program doesn’t have optimization features in the source, it’s wated time and energy.

LCARS interface… that is something I haven’t seen in a loooooooong time

Ah, yes, Linux around the turn of the century. Let’s see…

GPU acceleration? In your dreams. Only some cards had drivers, and there were more than 2 GPU manufacturers back then, too… We had ATi, nVidia, 3dfx, Cirrus, Matrox, Via, Intel… and almost everyone held their driver source cards close to their chest.

Modems? Not if they were “winmodems”, which had no hardware controller, the CPU and the Windows driver (which was always super proprietary) did all the hard work.

Sound? AC’97 software audio was out of the question. See above. You had to find a sound blaster card if you wanted to get audio to work right.

So, you know how modern linux has software packages? Well, back then, we had Slackware, and it compiled everything gentoo style back then. In addition, everyone had a hardon for " compiling from source is better"… so your single core Pentium II had to take its time compiling on a UDMA66-connected hard drive, constrained with 32 or 64 MB RAM. Updating was an overnight procedure.

RedHat and Debian were godsends for people who didn’t want to waste their time compiling… which unfortinately was more common even so, because a lot of software was source only.

Oh, and then MP3 support was ripped out of RedHat in Version 9 iirc, the last version before they split it into RHEL and Fedora. RIP music.

As for Linux on a Mac, there was Yellowdog, which supported the PPC iMacs and such. It was decently good, but I had to write my own x11 monitor settings file (which I still have on a server somewhere, shockingly, I should throw it on github or somewhere) to get the screen to line up and work right.

Basically, be glad Linux has gone from the “spend a considerable amount of time and have programming / underhood linux knowledge to get it working” to “insert stick, install os, start using it” we have now.

flatpaks are designed for gui apps, and due to packaging dependencies, they are extra heavy in disk space. flatpaks are also most often installed on the user, not systemwide, so no root permissions needed to install.

apt installs systemwide exclusively, but can have a much smaller download size if the dependencies are already installed. Apps sharing dependencies means much less disk space. cli is supported.

It’s an “immutable” Fedora, that is, the system comes as a read only image, kind of like how android works. Anything you do is “layered” on top of that image. This means you have to actually try to break it, because you can undo anything you did to break it by simply not booting with the extra layer(s).

You’re encouraged to install in userspace flatpaks instead of system-wide rpms where possible, as system-wide rpms means adding a layer on top if the image as it is.