deleted by creator

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;
}

Imagine defending this guy. I will never understand people who like influencers.

I ran into the same issue a few weeks ago. In my case I didn’t need real-time updates but I still needed to bulk insert data, which Postgres is terrible at (especially when dealing with tens of millions of rows). I just ended up using MariaDB (since that was my first exposure to SQL and I don’t remember having issues with it) and turns out it can handle bulk inserts a lot better without slowing down much. I wish PostgreSQL was better.

That’s literally what I’m saying; It’s fine as long as there wasn’t any unwritten data in the cache when the machine crashes/suddenly loses power. RAID controllers have a battery backed write cache for this reason, because traditional RAID5/6 has the same issue.

How’s the performance compared to other filesystems? Last benchmark I’ve seen it performed pretty poorly compared to btrfs.

I had a drive where data would get silently corrupted after some time no matter what filesystem was on it. Machine’s RAM tested fine. Turned out the write cache on the drive was bad! I was able to “fix” it by disabling the cache via hdparm until I was able to replace that drive.

BTRFS RAID5/6 is fine as long you don’t run into a scenario where your machine crashes and there was still unwritten data in the cache. Also write performance sucks and scrubbing takes an eternity.

I agree. There is literally 0 reason to buy anything from Apple when there are much better and much cheaper options that are already well supported by GNU/Linux. I will never understand people who will go out of their way to waste money on the next big thing from Apple only to get Linux on it.

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.

On distros w/o systemd there is always syslog-ng. s6 also has its own log system.

It’s not necessary, but a good thing to have if something goes wrong and you want to debug/monitor something. It’s really up to you and your needs.

https://github.com/phkaeser/wlmaker

Gallium-Nine also tends to be buggy if used with 32-bit software in particular. All the 32-bit games I’ve tried have problems with it. They usually work fine for the first 30-60 minutes and after that the framerate becomes unstable to the point where the game becomes unplayable. It happens consistently with Gallium-nine but not at all with DXVK.