Real example, I recorded the world series using an ATSC antenna, and I re-encoded a 90 second sample using a bunch of different settings on a 32-thread znver5:

  # Codec        Flags                     Size         Speed
  - -----        -----                     ----         -----
    Original     (Raw ATSC mpeg2video)     77MB (100%)  N/A
  1 libx265      -preset slower -crf 24    37MB  (48%)  0.245x
  2 libsvtav1    -preset 3 -crf 44         36MB  (25%)  1.87x
  3 libsvtav1    -preset 1 -crf 35         19MB  (25%)  0.556x

(1) and (2) are completely indistinguishable from the original unless I go frame by frame looking for transient motion artifacts. (3) is only distinguishable in one shot where a dark background was washed out. Not only does AV1 produce results just as good as H265, it encodes quite a bit faster for the same size/quality.

That said, I've watched so much h264-encoded video over the past decade I think I've been trained to perceive the subtle visual "snow noise" as a sign of a high quality video: I find how AV1 blends backgrounds more visually objectionable than the dithering in H265, even though I think it's objectively higher fidelity. Similar to how I find high frame rate video "fake" after having watched NTSC TV for the first half of my life.

These were the CRFs necessary to get the same visual quality with libx265 at faster presets and the resulting sizes:

  hevc-slower-24          37MB (used above)
  hevc-slow-21            56MB
  hevc-medium-20          57MB
  hevc-faster-19          52MB
  hevc-veryfast-18        60MB

  Location: Bay Area, CA, USA
  Remote: Yes
  Willing to relocate: No
  Technologies: C, C++, Linux, drivers, embedded, HPC, networking, video, radio, yocto
  Résumé/CV: https://github.com/jcalvinowens/misc/blob/main/resume/resume.pdf
  Email: calvin@wbinvd.org

I'm not considering full time roles at this time, only contract work. Thanks.

  Location: Bay Area, CA, USA
  Remote: Yes
  Willing to relocate: No
  Technologies: C, C++, Linux, drivers, embedded, HPC, networking, video, radio, yocto
  Résumé/CV: https://github.com/jcalvinowens/misc/blob/main/resume/resume.pdf
  Email: calvin@wbinvd.org

I currently have 20 hours/week available. I'm not considering full time roles at this time, only contract work. Thanks.

GCC has historically been a bit of a pig about -Os, my favorite example is on x86 where it will emit a runtime divide for a division by a compile time constant power of two because it saves a byte of text!

  int fn(int n)
  {
    return n / 8;
  }

  0000000000000000 :
   0:   89 f8                   mov    %edi,%eax
   2:   b9 08 00 00 00          mov    $0x8,%ecx
   7:   99                      cltd
   8:   f7 f9                   idiv   %ecx
   a:   c3                      ret

  0000000000000000 :
   0:   8d 47 07                lea    0x7(%rdi),%eax
   3:   85 ff                   test   %edi,%edi
   5:   0f 49 c7                cmovns %edi,%eax
   8:   c1 f8 03                sar    $0x3,%eax
   b:   c3                      ret

DDR5 on-die ECC detects and corrects one-bit errors. It cannot detect two-bit errors, so it will miscorrect some of them into three-bit errors. My understanding is that the on-die error correction scheme is specifically specially designed such that the resulting three-bit errors are mathematically guaranteed to be detected as uncorrectable two-bit errors by a standard full system-level ECC running on top of the on-die ECC. But I've never found a real authoritative reference that directly says that.

If a NAS has a 1G or even 2.5G NIC, improving the filesystem performance is a waste of time... the network is the bottleneck. My N100 two-disk btrfs-raid1 NAS hits line rate on a 2.5G NIC, that's all that matters to me.

  {0}[calvinow@sousa ~/git/linux] git describe
  v7.1
  {0}[calvinow@sousa ~/git/linux] git clean -dffxq
  {0}[calvinow@sousa ~/git/linux] zcat /proc/config.gz > .config
  {0}[calvinow@sousa ~/git/linux] time make -skj32 tar-pkg
  './System.map' -> 'tar-install/boot/System.map-7.1.0'
  '.config' -> 'tar-install/boot/config-7.1.0'
  './vmlinux' -> 'tar-install/boot/vmlinux-7.1.0'
  'arch/x86/boot/bzImage' -> 'tar-install/boot/vmlinuz-7.1.0'
  
  real    0m56.539s
  user    18m41.863s
  sys     2m8.754s

If you don't actually need all the drivers, you can use "make localmodconfig" to substantially reduce that. My local kernels build in 90 seconds on a 32-thread desktop machine :)

The kernel is a lot more stable than people think: I run the daily linux-next on my Debian stable gaming PC to look for bugs, and I don't find very many.

Based on comments in the kernel source, it seems like the userspace fsck for JFS and F2FS will also sometimes create /lost+found. There might be more that do.

Yes, it's copy on write... but there is a linear relationship between the size of the process and the number of page table entries required to represent it.

A 2x32GB DDR5 kit I paid $150 for 11 months ago costs $910 today from the same retailer. A 2x16GB DRR4 kit that was $105 last year is now $230.

The RAM alone in my newest machine would sell for over double what I paid for the entire machine one year ago.