Scholars_Mate

• What steps did you take to rollback your root subvolume?
• Can you log into the emergency shell and share any logs?
• Is your root partition mounted in the emergency shell, or is the initramfs still mounted in the emergency shell?

I pre-ordered the 128GB SKU in the second wave. Soldered RAM doesn't matter to me if I am already maxing out what the platform is capable of. If I can dynamically configure the memory allocation between the CPU and GPU, this will be an extremely potent little AI workstation. I'll be able to cancel the pre-order of things aren't what I expect, and it isn't much of a loss for me ($100 refundable deposit).

I do agree that this branching away from Framework's roots, but I am still very happy that they are doing interesting things. I've always thought that what Minisforum has been doing with their SFF workstations has awesome, so I'm glad to see other companies wading into the same space.

Apparently Framework did try to get AMD to use LPCAMM, but it just didn't work from a signal integrity standpoint at the kind of speeds they need to run the memory at.

What filesystem are you using on the external drive? If it is NTFS or FAT, they won't store permissions on the filesystem, which would explain why the owner/group changes are not persistent. To fix that, you can set the uid/gid on mount in your fstab.

/dev/mapper/YOUR_DRIVE /path/to/mnt <fstype> rw,uid=<jellyfin_uid>,gid=<jellyfin_gid>,dmask=0002,fmask=0113

Are you using the default bridge? I have a similar setup (with Traefik instead of NPM), and for each compose file am using separate networks for the internet, proxy, and backend services.

services:
  some_service:
    ...
    networks:
      - frontend_network
      - proxy_network
      - backend_network
  backend_service:
    ...
    networks:
      - backend_network
networks:
  frontend_network:
    driver: "bridge"
  proxy_network:
    driver: "bridge"
    internal: true
  backend_network:
    driver: "bridge"
    internal: true

All video codecs are lossy, meaning you will lose some quality. AV1 and H.265 are modern video codecs with the best quality to bitrate ratios, meaning you can get better quality for the same bitrate, or the same quality with a lower bitrate. The downside the these codecs is that they are very complex and computational expensive to do in software. You'll want to make sure your GPU supports hardware encoding for the codecs you intend to record with. The reason most people will recommend AV1 over H.265 is that AV1 is royalty free. With H.265, companies have to pay a royalty to use H.265. Because of this, most companies (Netflix, YouTube, Facebook, Twitch, etc.) want to use AV1 going forward, meaning in the near future, it will probably be the dominant codec.

Then which Apple phone are you talking about? The iPhone 15 is pretty much the same size as the Pixel 8. The iPhone SE is the only small phone Apple seems to make, and from what I can tell from a quick search, they aren't selling a lot of them.

The iPhone 15 is 147.6 height x 71.6 width x 7.8 depth (mm).
The Pixel 8 is 150.5 height x 70.8 width x 8.9 depth (mm)

I would call that pretty much the same size.

No they don't? The iPhone 12 mini and iPhone 13 mini were the worst performing phones out of their lineup. Small phones are dead because hardly anyone buys them.

Texas does have anti-SLAPP laws passed and they are among the strongest in the nation. Unfortunately, the courts have ruled that they cannot be used in federal courts.

Then Linus responded pretty poorly (and ended up stepping down as CEO and is now a chief creative something or other iirc)

Linus didn't step down in response to this. I don't remember the exact timelines, but he either stepped down before this, or was in already in the process of transitioning to the new CEO when this happened.

No. Modern SSDs are quite sophisticated in how they handle wear leveling and are, for the most part, black boxes.

SSDs maintain a mapping of logical blocks (what your OS sees) to physical blocks (where the data is physically stored on the flash chips). For instance, when your computer writes to the logical block address 100, the SSD might map that to a physical block address of 200 (this is a very simplified). If you overwrite logical block address 100 again, the SSD might write to physical block address 300 and remap it, while not touching the data at physical block address 200. This let's you avoid wearing out a particular part of the flash memory and instead spread the load out. It also means that someone could potentially rip the flash chips off the SSD, read them directly, and see data you thought was overwritten.

You can't just overwrite the entire SSD either because most SSDs overprovision, e.g. physically have more storage than they report. This is for wear leveling and increased life span of the SSD. If you overwrite the entire SSD, there may be physical flash that was not being overwritten. You can try overwriting the drive multiple times, but because SSDs are black boxes, you can't be 100% sure how it handles wear leveling and that all the data was actually overwritten.