Running the same memory constraints on a 1.18 vanilla instance, most of the stack memory allocation largely comes from ramping the render distance from 12 chunks to 32 chunks. The game only uses ~0.7 GiB memory non-heap at a sane render distance in vanilla whereas ~2.0 GiB at 32 chunks. I did forget the the render distance no longer caps out in vanilla at 16 chunks. Far render distances like 32 chunks will naturally balloon the stack memory size.

For clarification, this is Vanilla, a performance mod Fabric pack, a Fabric content modpack, Forge modpack, etc. that you are launching? If it’s the modpack that you describe needing 8gb of heap memory allocated, I wouldn’t be surprised the java stack memory taking ~2.7 GiB. If it’s plain vanilla, that memory usage does seem excessive.

Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.

My recommendation: don’t allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).

In general, it’s also a good idea to setup and enable ZRAM and disable Swap if in use.

The VRR problems are specifically related to either monitors not supporting Freesync over HDMI or the user running a monitor expecting HDMI VRR to work on HDMI 2.1 specs (>4k@60hz or equivalent bandwidth negotiation requirements). I would concur a small subset of users is correct for the use-cases where this becomes a problem.

Generally, yes. It’s not nearly as bad as say 2015 but NVidia has a long standing history of being difficult to deal with, and users having to make constant compromises. For instance, NVidia hasn’t had properly working Wayland support on most environments until recently due to the awful flickering that many users experienced. Things like power saving, dual GPU handoff, general OpenGL performance, frame stability and tearing (X.Org), etc. have been either historical and/or current pain points for using NVidia GPUs vs AMD or Intel GPUs.

https://librewolf.net/

A summary from its site and known technical details:

• no telemetry by default
• includes uBlock Origin
• has sane privacy-respecting defaults
• prepackages arkenfox user.js
• relatively well-maintained fork of Firefox that keeps up with upstream
• No major controversies AFAIK

As for Windows 7, nobody should really need to install Librewolf anyway on such a device. No device running Windows 7 should have access to the internet at this point. If you are asking about compatibility intending this use case, you have bigger problems to worry about than your choice of browser. If you just need to view HTML files graphically, even Internet Explorer or an older firefox ESR will do.

For many with unstable ISP connections, http downloads can get corrupted. Torrents are superior in this regard as the file gets split into blocks that each get checksummed for integrity after completion. This helps to ensure that the large iso is actually complete and won’t just be garbage on an attempted install. Even if you checksum the iso from http download, you have to pull the entire thing again if it is damaged whereas the torrent would just repull the damaged blocks automatically.

2-2-1 still insinuates having a remote backup. I don’t see how this particular threat destroys a 2-2-1 setup.

What makes Nextcloud unreliable for your use case? I’ve used the calendar (caldav) functionality for years without issue in sync.

I’d imagine mpd with one of many frontends would work well enough. You’d just need to use a dummy music library directory with symlinks to your four music storages for mpd to pick up and catalog everything.

Tbf to cloud sync, nothing is stopping you from using your own backup/restore service with your drm-free titles compared to the other features that Galaxy offers.

GOG has DRM for many titles: see Galaxy. As I understand it, it isn’t as pervasive as Steam, but is necessary if you want multiplayer on many titles or care about extras like achievements.

On my Fedora KDE install on 40, hibernate is now an available power option. The install has been in upgrade cycles since 35 at this point. I would imagine that barring different DEs showing different power options being a possibility, it is more on detecting hardware compatibility for functional hibernation.

Based on how the script /usr/lib/kernel/install.d/99-grub-mkconfig.install (a script that runs on kernel installations) behaves, unless you are running in Xen Hypervisor or are on an architecture that doesn’t support it, Fedora by default expects to have GRUB_ENABLE_BLSCFG set to true. This script is provided by the package grub2-common, so it’s unlikely it can be removed without removing the GRUB bootloader’s management system entirely.

More than likely, most customizations will work just fine with GRUB_ENABLE_BLSCFG set to true as long as you properly run grub-mkconfig (or just update-grub) after you make those changes so that they get applied to the bootloader portion of GRUB itself.

If for some reason you do absolutely need to disable BLS in order to get the customization you want, the proper way to enforce grub-mkconfig on new kernels would be to write a script in the /usr/lib/kernel/install.d/ directory titled like 98-grub-manual-mkconfig.install that would forcibly run the proper mkconfig command after kernel installation and initramfs generation.

This seems like a terrible bandage fix rather than letting the system mechanisms do what they are supposed to.

Checking inside /usr/lib/kernel/install.d/, you can see the mechanisms in place for installing new kernel entries. Not knowing what you did to your config (did you back it up before making changes?), you should check if the entries are being populated properly in /boot/loader/entries/. If they are, you have likely toyed with the BLS config in some way that broke being able to load dynamic entries without mkconfig.

If that is indeed the case, I wouldn’t know exactly what you touched to break it, but this discussion forum might give some insight.

If this isn’t the problem, it might be helpful to post your grub config minus any sensitive details to help determine what is going wrong.

I have been utilizing BunkerWeb for some of my selfhost sites since it was bunkerized-nginx. It is indeed powerful and flexible, allowing multi-site proxying, hosting while allowing semi-flexible per-site security tweaks (some security options are forcibly global still, a limitation).

I use it on podman myself, and while it is generally great for having OWasp CRS, general traffic filtering targets and more built on top of nginx in a Docker container, the way Bunkerweb needs to be run hasn’t really remained stable between versions. Throughout several version upgrades, there have been be severe breaking changes that will require reading the setup documentation again to get the new version functional.

A few things Fedora centers itself around:

• Wayland-oriented Workstations
• SELinux support OOTB
• BTRFS as default filesystem
• General attitude toward using close to bleeding edge packages as defaults
• Package order of Fedora rpm repos, Fedora Flatpak -> RPMFusion, Flathub -> copr -> external installation
• Immutable variants of Fedora exist for the major desktops

Fedora generally prides itself on being a Wayland-focused and oriented workstation distro. There is still active support for desktop environments/window managers that run on Xorg, but you should consider moving toward a Wayland-supporting environment (Gnome, KDE, Sway, Hyprland).

SELinux (a Mandatory Access Control system) is enabled by default and has pretuned policies installed that should support most use cases out of the box. SEApplet is a useful utility to find active SELinux denials in case an application is getting permission denied issues for seemingly no reason.

If you intend to use BTRFS as your filesystem of choice and want to utilize it to its fullest (encrypted partitions, subvolume encryption, automatic snapshots), it is best to read up how BTRFS and subvolumes work before partitioning so that your subvolumes will be correct the first time. It can be tedious to edit subvolumes, move their contents, and remount portions of the filesystem after they have already been populated.

I’m sure you’re used to how things on Arch with bleeding edge works, and understand that on Arch you should always read patch notes before updating. Generally, updates on Fedora are fine to just push through. It is worth generally reading what is new when performing system upgrades to a new version of Fedora, I have noticed occasionally in over five years of usage the first target release of a new version of Fedora can sometimes have breakages that tend to get fixed within the next couple of weeks. There is extensive testing for system upgrades that can be openly viewed, but the testing doesn’t always catch everything before a new release.

By default, the best way to grab packages on Fedora is from the official repos or from the Fedora Flatpaks. Barring that or if you aren’t satisfied by a default package for whatever reason (some stuff in default repos doesn’t have ffmpeg support or others due to codec licensing issues), you can add the second-party RPMFusion repos or add Flathub to grab additional or alternative packages as well. If those avenues fail, you might be able to find someone maintaining the package you need or want to test on Copr, which is essentially like Ubuntu’s Launchpad PPA platform. Barring all else, you could manually install a given application externally, though obviously this typically isn’t the best solution in most cases. Some cases where you might want RPMFusion packages are for things like audacity-freeworld, which includes proper ffmpeg support for Audacity. This package comes from rpmfusion-free. Or you might want something like akmod-nvidia to install the proprietary NVidia drivers or steam to install Steam. These packages come from rpmfusion-nonfree. Also, if you are not familiar with Flatpak, it might be worth becoming familiar with how it works (Flatseal is an excellent application that lets you modify how certain Flatpaks are sandboxed).

Immutable variants of Fedora (Silverblue, Kinoite, Sway Atomic, Budgie Atomic) also exist and provide an immutable base image that won’t typically get modified across boots. Most of the custom user installation of programs is intended to be installed via Flatpaks (Fedora or Flathub) or through using toolboxes to create sandboxed environments for certain workflows. If you absolutely need to rebase the system image with extra utilities, rpm-ostree is available to modify the system package selection, though this method is not recommended to just be used to install everything (needless rebasing of the immutable image defeats the point of using an immutable distro). Obviously these spins aren’t for everyone, but are there for those who want to use them.

I just did some testing in the past hour or so and did a portable install from scratch using the Fedora Workstation 39 iso. I’m not exactly sure what your hardware detection issue would have been, but I can say that Anaconda could detect both a USB flash drive and an external hard drive I had plugged in.

Going with the USB flash drive, I did skip using the automatic partitioning and went for using blivet to do my work. I did format the drive beforehand as I have always had issues with that drive properly accepting various partitioning commands (the installer no exception as tested). I did reserve a partition for a shared storage filesystem, but didn’t actually give it a filesystem here.

In blivet, here is a sample of the kind of partition schema I was talking about (something that might be helpful to OP or anyone else that wants to try this setup):

I was able to then complete the install as normal and boot into the finished USB drive. I noted a small non-fatal complaint from grub on boot, but I imagine this is fixed with updating the system. All systemd units boot without failure and I am able to get the system working with minimal issue. The only real issue I could note is that the installation is very sluggish (due to it being on a flash drive rather than an external ssd or some other more suitable media). After booting, I then opened Disks and added the missing exfat (or NTFS) filesystem I reserved a partition for. The reason I didn’t do this in blivet during install is because the option doesn’t actually exist to make an exfat fs in the tool.

Hopefully, this comment is helpful toward getting such a setup working.

EDIT:

Something I did notice with GRUB on Fedora Workstation 39 is that by default, the menu will not show unless pressing escape on boot. There is a useful AskUbuntu post that explains in detail how to access the grub menu and how to change it to behave in a better fashion for a multiboot system.

Ah, that would put a bit of complication into things. If you want to actually accomplish this though, you should largely start with the same steps as a standard system install, using a second USB flash drive to write the distro onto the external SSD, leaving enough space to build the rest of the partitions you need. If you intend to make a Windows-shared partition (exfat, fat32, or NTFS), it is probably best to put that partition either first or just behind the EFI partition so that Windows systems won’t have a hard time finding it. Exfat or NTFS would be a better choice for this type of partition.

I would still generally recommend keeping the live distros on a separate bootable drive, but you can size and reserve dummy partitions after the rest of your normal dual-boot installs and shared data partitions for live installers to overwrite. There is likely going to be some experimentation with getting the OS bootloader (such as on GRUB provided by Fedora in this case) to pick them up and add them as boot entries. You should (depending on the live image) be able to dd write them to the ending partitions reserved for the image for as long as the partition is sized equal or larger than the ISO image’s size (it’s best to give at least a few blocks of oversize on the partition when writing ISO’s directly).

Edit: In a proper Fedora install, you should almost never need to disable selinux or set it to permissive unless you know why you don’t want it.