Recently I was building an AMD-based PC system for a client. I started with 32 GB of DDR5 and there was some kind of systemic lag occurring while I was making changes in this PC's mobo UEFI BIOS settings. My USB mouse was lagging inexplicably. I eventually recalled that the usual A-B-A-B method for assigning dissimilar memory still applies. When I inserted my memory in the correct order everything seemed fine.

Undaunted, I got this system with its two SSD's each separately running Ubuntu Budgie and Windows 11 to boot, however my boot time is now on the order of 12 to 15 seconds start time. This seems an extra long time from my viewpoint. In the past — a similar setup would take 5 to 7 seconds, tops.

Slashdot: please stop sharing links to the sites that disseminate X links. Does Boris use Mastodon? X CEO Elmo Musk is a little fascist and a Trump ally who really wants to paywall the entire Internet through his own profit motives. To hell with Musk.

Incidentally, the pre "pre-alpha" releases of KDELinux are available only in raw (not ISO) format, and so one has to use an AppImage program called KDE ISO Image Writer on another Linux machine or your other Windows machine to burn the *.raw KDELinux installation image to your USB thumb drive.

I was unable to find Python 2.7 after running updates via flatpak, so I'm using Homebrew on my "pre pre-alpha" KDE Linux.

One difference is that KDE Linux uses flatpak. It can take a bit of getting used to! I'm already learning how to use flatpak in place of apt.

Saw this on KDE Linux's webpage: "Lots of internal Plasma-aligned apps haven't been Flatpak'd yet (Icon Explorer, Emoji Picker, Info Center, etc) and should be."

This could mean that the installer is itself a Plasma-aligned app. Maybe that's why I encountered a fatal install error. I don't think it's my GPU because the system launches into desktop mode quickly.

I'm just a software progressive -- I don't work directly with KDE Linux's developers. I also won't tell -- or really push the envelope in any way. I'm now aware in a sense that some of our global competitors would rather not see these people succeed.

I'm going to check out the pre-alpha release! I was having just one install problem:

My attempt at installing KDE Linux several days ago complained about a /system/@flatpak configuration that went awry. The read-only filesystem KDE Linux uses creates an interesting problem for the user if something internal is not working correctly during the Linux installation. I didn't know or couldn't understand how to take out entries that were using flatpak IN THE INSTALLER itself (likely due to the read-only filesystem). I was only able to somehow modify a *.conf file and doing this did nothing to fix the broken installer.

"You can only install sandboxed apps that go in their own corner of the OS, and here the plan is that users will install Flatpak (and possibly Snap, "if it's not too hard and the UX is OK") packages using the KDE Discover app"

No, it won't be anything of the sort. Because bureaucracy never dies and that goes for all of Europe, too.

^ That is a major "no shit" statement right there. It really took me a while to learn this.

I don't think Wi-Fi drivers for RPi 4 or RPi 5 will ever be supported by AARCH64 FreeBSD. Every time I look into this I get a NIMBY vibe from the FreeBSD devs. They just don't care about something that small.

What's astonishing to me is that FreeBSD, after all of this time, still does not have an additional part included in their installer to install and test Xorg and say, XFCE or GNOME desktop environments. That right there just seems to be "in error" and does not sit well with me. Sure, I could use Ghost BSD or something else. It does beg the question: why does FreeBSD do this to their whole base? Do they enjoy making the non-server crowds who run FreeBSD on their PC's and laptops miserable?

A few years ago I tried to use an older version of FreeBSD on a RPi 4 but the OS didn't have Wi-Fi support for Pi boards. Has the status for this changed with AArch64/ARM64?

In other words, would you know if they got it working and this page is now out of date, or is Wi-Fi still unsupported?

https://wiki.freebsd.org/arm/R...

ok thanks for clarifying that. That makes more sense now.

This is dumb. Where are our clean, safe cores? Why are there always compromises with chip and software security? Why can't Intel stay ahead of the curve?

He was also working with 98 year old Henry Kissinger on that AI book. Schmidt learned a few tricks from the conniving Kissinger.