• 0 Posts
  • 22 Comments
Joined 9 months ago
cake
Cake day: January 5th, 2024

help-circle
  • The flatpak documentation has a semi-relevant page on setting up a flatpak repo utilizing gitlab pages and gitlab’s CI runners on a pipeline. Obviously, you’d need to substitute Gitlab Pages for a webserver of your choice and to port the CI logic over to Gitea Actions (ensuring your Gitea instance is setup for it).

    A flatpak repo itself is little more than a web server with a related GPG key for checking the signatures of assembled packages. The docs recommend setting up the CI pipeline to run less on-commit to the package repos and more on the lines of checking for available updates on interval, though I imagine other scenarios in a fully-controlled environment such as a selfhosted one might offer some flexibility.


  • As I am teaching myself right now maintainable selfhost setups using popular apps (admittedly with Kubernetes vs something minimal in functionality like Docker Desktop), there is a lot of complexity involved in getting these services both functional and maintainable while also having to consider the security implications of various setups.

    While I agree the concept of self-host is a good thing to advocate, I think the complexity and difficulty involved not just to do it, but to do it right is going to be a straight cliff of a learning curve for those not already technically inclined in databases, networking, and filesystems/block storage.

    Honestly, taking the burden of being IT for a reasonable subscription cost for your efforts is a better way to go, especially if the setup allows for expanding your offerings to other members in a localized community.


  • jrgd@lemm.eetoLinux@lemmy.mlBest GUI VM software
    link
    fedilink
    arrow-up
    6
    ·
    1 month ago

    Alongside many others, I agree that using QEMU through GUI frontends like virt-manager or GNOME Boxes, or even server-focused solutions like Cockpit+VM plugin or Proxmox layered on top of your installation.

    I just want to note a decent point against other solutions like VirtualBox or the VMWare products that work on Linux: these solutions that don’t rely on QEMU almost certainly need the user to install out-of-tree kernel modules (that in some cases may also be proprietary). QEMU and its frontends don’t need out-of-tree modules in a majority of distros and can work out of the box with all features (given BIOS configuration of the host and hardware supports them).


  • I started dual booting Linux after an upgrade to an insider preview of Windows 10 soft-bricked my Windows 7 install. I later stopped booting into Windows and eventually reclaimed the partitions to extend whatever distro was installed at that point when the actual release of Windows 10 decided to attempt automatically upgrading my Windows 7 system, soft-bricking it a second time. 2016 onwards, I haven’t used Windows on my systems outside of occasionally booting LTSC in a VM.


  • jrgd@lemm.eetoLinux@lemmy.mlJava uses double ram.
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    2 months ago

    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.


  • jrgd@lemm.eetoLinux@lemmy.mlJava uses double ram.
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 months ago

    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.


  • jrgd@lemm.eetoLinux@lemmy.mlJava uses double ram.
    link
    fedilink
    arrow-up
    14
    ·
    2 months ago

    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.



  • 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.


  • We are well beyond the point of a majority of common hardware having built-in kernel drivers and userland software for extra stuff like RGB control that the best advice is rather avoiding Linux, to instead avoid the trash hardware (NVidia for the time being, GoXLR, Broadcom, etc.). My GPU, audio hardware, network interfaces are both popular products and have worked out of the box for years now.




  • 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):

    Blivet GUI Partitioning screen showcasing empty, EFI, boot, and root partitions

    Blivet GUI Partitioning screen showcasing boot btrfs volume with singular subvolume

    Blivet GUI Partitioning screen showcasing primary btrfs volume with root, snapshots, home, var, and var/log subvolumes

    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.

    Fedora 39 with GNOME Disks window and terminal reading out the contents of /etc/os-release

    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.


  • For the longest time reading this post, I didn’t catch that you were setting up a simple dual boot for an internal SSD and thought with using tools like Ventoy you were making a multiboot portable install.

    You are obscenely overcomplicating this. Your current approach is almost completely wrong to getting a functional multiboot system that passes secure boot and everything else.

    Quite literally, bootstrapping from windows can use Rufus or ventoy on a USB stick to dump the ISOs on. Then boot into bios from the USB EFI entry. From there, simply install Fedora (no VM necessary). You’ll get Fedora installed in a GPT/EFI configuration (if you formatted your drive for install). If doing manual partitioning to leave space or do other configurations, format the drive to GPT. If multibooting, you may want to expand your EFI partition beyond 512MiB for multiple distros.

    For other Linux OS to install alongside, you can then install them in the free space. Another comment mentioned to not install a bootloader on the secondary OS(es), which is generally a good idea.

    For Tails, it is not meant to be installed on an SSD. It is best to use it on a flash drive.

    Overall, a majority of your issues stem from the following:

    • trying to use live distro images as an actual OS install
    • using Ventoy as your bootloader
    • using legacy MBR partition tables instead of GPT without expressed need for them
    • Using virtualbox in general to provision bare metal hardware (changes need to be made in your VM software of choice to get EFI booting to work)

    I’d argue your conclusion of people not switching to Linux because you found it too hard is almost entirely not because of any issue on Linux, but the factors you wedged yourself into on a modern x86 PC due to your methods in accomplishing your goal.




  • In general, Microsoft doesn’t support many filesystem formats at all. In the same way you shouldn’t attempt to cross-run a steam library from Windows on Linux, you really shouldn’t do from Linux to Windows. It’s in part due to how permissions, execution flags, filesystem case sensitivity, file metadata, is interpreted by Windows applications vs. Unix-like applications. There will be issues going either way when using foreign filesystems in complex tasks.

    While it should be expected that the files will have the same contents where they are actually the same (i.e. a Proton game will be the same as a Windows game as it comes from the same steam depot), there is a good chance that translation of interpretation isn’t to be 1:1 on either side. Furthermore with using Steam libraries, Steam includes additional data beyond just the game files, which is likely why they are invalidated. A significant portion of visible cross-os portability issues is due to many applications like Steam using OS-specific file structures. More than likely Steam is going to intentionally make the library metadata not fully compatible between Linux and Windows Steam and force validation before launch because there is a good chance the games aren’t even compatible builds or otherwise have additional compatibility content dragged along (such as Proton WINE prefixes that are to be completely ignored when launching from actual Windows or having additional libraries, modded executable binaries that have platform-oriented patches).

    If you seriously want to run a cross-share of a Steam Library between Linux and Windows, you should really utilize Steam Cloud save. If you want to “deduplicate” your games, your best bet would be if you can open the foreign fs and have a compatible copy of the game, to simply clone the game files to the current filesystem and remove from remote rather than attempt to force a multi-os single-partition shared library. You are less likely to destroy your Steam library if you treat the actual libraries separate, but move the games like they were downloaded externally. Barring being able to do that, just don’t cross-share games. Simply reboot into the OS that has the game you want to play instead.


  • jrgd@lemm.eetoLinux@lemmy.mlCurrent state of NTFS compatibility?
    link
    fedilink
    English
    arrow-up
    51
    ·
    edit-2
    8 months ago

    One can comfortably use NTFS to read and write files on modern Linux distributions, but NTFS in general is not very suitable for running applications on or using for long-term usage between a dual-boot. Windows can and will often lock up NTFS partitions whenever it decides to hibernate rather than shutdown or sometimes suspend. NTFS while not being the greatest FS in general will also have worse performance on Linux than Windows. You can totally keep data stores on a Linux system, though you won’t be able to make use of many of the advanced features some Linux/BSD-oriented filesystems offer. You can totally keep your drives as they are now, though if you intend to make a full switch you should consider migrating your drives’ data over to more Linux-oriented filesystems (be it Btrfs, Xfs, or Ext4 is your choice depending on the features you want). In short, NTFS works but lacks a lot of features and performance that a more suitable filesystem would offer.