This whole thing feels like a celebrity ad.

Maybe they left it running for a while. The current Steam Client is basically an Electron App.
I miss the old Steam Client that was made entirely in Valve’s own GUI Framework which was written in C++.

Hey, I’m posting this via lem.el! I’ve been using it for a few months now.
Could still use some work, but far better than using a Web Browser.

You can use the lsof utility though to list all currently open file handles.

I rather deal with that than any Micro$oft® Garbage®.

It’s crazy how many people are just OK with running completely proprietary code that monitors everything that happens on the machine and phones home all the time, all with the promise to “catch cheaters”.

Fortunately every game I’ve seen so far with such malware is just a generic competitive multiplayer dopamine farm that targets the Streamer crowd.

“But all my friends are playing it!” - Is it really worth it to run omnipresent malware on your machine just to play the currently trending game for a few weeks until you move on to the next?

Eclipse 15 years ago was OK. Decent Debugger, useful Plugins (like WindowBuilder). It had issues, but instead of focusing on those they over time just kept piling crap on top of it.

Does anyone out there still use a 32-Bit Computer as their daily driver? The most recent 32-Bit hardware I’ve used as a Desktop was an RPi3 and running a modern web browser on that thing would almost cook the chip.

I pretty much share the same experience. I avoid using docker or any other containerizing thing due to the amount of bloat and complexity that this shit brings. I always get out of my way to get Software running w/o docker, even if there is no documented way. If that fails then the Software just sucks.

Coding directly in assembly is rare.

I used to think that, but when you’re dealing with a lot of low-level stuff you’ll eventually realize that Compilers are pretty bad at generating fast and reliable Assembly where it’s needed. Also, some Architectures have specific machine instructions that Compilers just don’t take advantage of, no matter what flags you enable.

You could spend your limited time and energy setting up an emulator of the powerPC architecture, or you could buy it at pretty absurd prices — I checked ebay, and it was $2000 for 8 GB of ram…

You’re acting as if setting up a ppc64 VM requires insane amounts of effort, when in reality it’s really trivial. It took me like a weekend to figure out how to set up a PowerPC QEMU VM and install FreeBSD in it, and I’m not at all an expert when it comes to VMs or QEMU or PowerPC. I still use it to test software for big endian machines:

#!/usr/bin/env sh

if [ "$(id -u)" -ne 0 ]; then
    printf "Must be run as root.\n"
    exit 1
fi

# Note: The "-netdev" parameter forwards the guest's port 22 to port 10022 on the host. 
# This allows you to access the VM by SSHing the host on port 10022.
qemu-system-ppc64 \
    -cpu power9 \
    -smp 8 \
    -m 3G \
    -device e1000,netdev=net0 \
    -netdev user,id=net0,hostfwd=tcp::10022-:22 \
    -nographic \
    -hda /path/to/disk_image.img \
#    -cdrom /path/to/installation_image.iso -boot d

Also you don’t usually compile stuff inside VMs (unless there is no other way). You use cross-compilation toolchains which are just as fast as native toolchains, except they spit out machine code for the architecture that you’re compiling for. Testing on real hardware is only really necessary if you’re like developing a device driver, or the hardware has certain quirks to it that are just not there in VMs.

Exactly. All modern CPUs are so standardized that there is little reason to store all the data in ASCII text. It’s so much faster and less complicated to just keep the raw binary on disk.

That’s only been my experience with software that depends on many different libraries. And it’s extra painful when you find out that it needs hyper specific versions of libraries that are older than the ones you have already installed. Rust is only painless because it just downloads all the right dependencies.

Some old software does use 8-Bit ASCII for special/locale specific characters. Also there is this Unicode hack where the last bit is used to determine if the byte is part of a multi-byte sequence.

This reads like it was written by some LLM.

Enable journaling only if needed:
tune2fs -O has_journal /dev/sdX

Don’t ever disable journaling if you value your data.

Disk Scheduler Optimization
Change the I/O scheduler for SSDs:
echo noop > /sys/block/sda/queue/scheduler
For HDDs:
echo cfq > /sys/block/sda/queue/scheduler

Neither of these schedulers exist anymore unless you’re running a really ancient Kernel. The “modern” equivalents are none and bfq. Also this doesn’t even touch on the many tunables that bfq brings.

Also changing them like they suggest isn’t permanent. You’re supposed to set them via udev rules or some init script.

SSD Optimization Enable TRIM:
fstrim -v /
Optimize mount settings:
mount -o discard,defaults /dev/sdX /mnt

None of this changes any settings like they imply.

Optimized PostgreSQL shared_buffers and work_mem.
Switched to SSDs, improving query times by 60%.

No shit. Who would’ve thought that throwing more/better hardware at stuff will make things faster.

EDIT: More bullshit that I noticed:

Use ulimit to prevent resource exhaustion:
ulimit -n 100000

Again this doesn’t permanently change the maximum number of open files. This only raises the limit for the user who runs that command. What you’re actually supposed to do is edit /etc/security/limits.conf and then relog the affected user(s) (or reboot) to apply the new limits.

Use compressed swap with zswap or zram:
modprobe zram echo 1 > /sys/block/zram0/reset

This doesn’t even make any sense.

Interesting feature, I had no idea. I just verified this with gcc and indeed the return register is always set to 0 before returning unless otherwise specified.

int main(void)
{
    int foo = 10;
}

push   %rbp
mov    %rsp,%rbp
movl   $0xa,-0x4(%rbp) # Move 10 to stack variable
mov    $0x0,%eax       # Return 0
pop    %rbp
ret

int main(void)
{
    int foo = 10;
    return foo;
}

push   %rbp
mov    %rsp,%rbp
movl   $0xa,-0x4(%rbp) # Move 10 to stack variable
mov    -0x4(%rbp),%eax # Return foo
pop    %rbp
ret

What a load of bloat. NetBSD has a whole guide on diskless booting various machines, none of this shit is new.

Unless your machine has error correcting memory. Then it will take literally forever.

Your CPU has big registers, so why not use them!

#include <x86intrin.h>
#include <stdio.h>

static int increment_one(int input)
{
    int __attribute__((aligned(32))) result[8]; 
    __m256i v = _mm256_set_epi32(0, 0, 0, 0, 0, 0, 1, input);
    v = (__m256i)_mm256_hadd_ps((__m256)v, (__m256)v);
    _mm256_store_si256((__m256i *)result, v);
    return *result;
}

int main(void)
{
    int input = 19;
    printf("Input: %d, Incremented output: %d\n", input, increment_one(input));
    return 0;
}

It doesn’t help that they keep deprecating and changing standard stuff every other version. It’s like they can’t make up their mind and everything may be subject to change. Updating to the most recent release can suddenly cause 10s or 100s of compiler warnings/errors and things may no longer behave the same. Then you look up the new documentation and realize that you have to refactor a large part of the codebase because the “new way” is for whatever reason vastly different.