[-] jrgd@lemm.ee 6 points 5 days ago

The specific patent links seem to be broken. All return 403. Here are functional alternatives.

[-] jrgd@lemm.ee 1 points 6 days ago* (last edited 6 days ago)

I think the fact that RCT Classic is only worth getting on mobile because there are better options on PC doesn't help make the case that RCT Classic should be a shining example of 'mobile gaming'. RCT Classic is bit above the bare minimum for an acceptable rerelease of older games.

[-] jrgd@lemm.ee 13 points 1 week ago

It doesn't currently allow for concurrent execution of EXE files, but that's a good idea. I'll see about implementing it.

88
submitted 1 week ago by jrgd@lemm.ee to c/linux_gaming@lemmy.ml

cross-posted from: https://lemm.ee/post/38676431

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.

153
submitted 1 week ago by jrgd@lemm.ee to c/linux_gaming@lemmy.world

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.

[-] jrgd@lemm.ee 19 points 1 week ago

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.

[-] jrgd@lemm.ee 15 points 1 month ago

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.

[-] jrgd@lemm.ee 35 points 2 months ago

The heated bed is coupled to a thermistor. I'd argue controlling the temperature in order to not accidentally overheat parts of the phone is a step above a hair dryer.

[-] jrgd@lemm.ee 14 points 3 months ago* (last edited 3 months ago)

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.

[-] jrgd@lemm.ee 25 points 3 months ago

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.

[-] jrgd@lemm.ee 13 points 4 months ago

Could you elaborate on this? As someone who uses SystemD extensively on workstations and servers for spawning and managing both system-level and user-level services, I do find minimal issues overall with SystemD minus some certain functionalities such as socket spawning/respawning.

Of course some of default SystemD's housekeeping services do suck and I replace them with others. I would like to see the ability to just remove those services outright from my systems as separate packages since they do remain useless, but it isn't that big of an issue.

[-] jrgd@lemm.ee 51 points 6 months ago* (last edited 6 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.

[-] jrgd@lemm.ee 18 points 6 months ago

Not the same person, but I greatly enjoy my (now second) Pebble classic for several reasons, which I imagine some are shared between Starayo.

  • Always-on Display
  • Week-long battery life
  • High contrast display that can be read easily in low light as well as in direct sunlight
  • Simple notifications support, with quick canned replies
  • physical button navigation that make the watch easy to use without needing to look at it
  • Isn't obscenely large
  • quick launch application shortcuts from holding side buttons
  • simple media playback control that is responsive
  • Doesn't attempt to be another smartphone, but rather as a local companion to your existing smartphone (doesn't thrive on individual apps, but rather companion apps to complement smartphone usage)
  • Customizable and relatively simple to write applications and watchfaces for.

Unfortunately for me, fossil's watches do not match up. Looking at the gen 6, still uses an ill-suited AMOLED display that is bound to have poor contrast in direct sunlight unless the brightness is cranked so far that it will blow through the battery. Even then, the average battery life on the gen 6 is atrocious compared to most Pebble models as many reports say it can make it through one day. I'm sure by now, WearOS devices have worked out some of the kinks to make them easier and faster to use, though I am not sold on needing a personal assistant in order to do basic tasks (as Fossil markets their gen 6 smartwatch; I do doubt that this is necessary for general function).

Also, this might be controversial, but I personally feel that a device that has Bluetooth and is intended to communicate with a device that is often within ten feet of it really doesn't need to waste resources and probably become more of a privacy nightmare by including Wi-Fi, LTE, and other data communication methods (beside NFC). Furthermore, pretty much every WearOS device I have seen has had a struggle to keep battery life for more than a couple days, and everyone deems that devices that can should be praised for whatever reason. Seeing as my ancient smartwatch that does most of what these newer watches do yet can effortlessly hold a six day battery life at worst, I seriously question why newer watches that have so much compromise and are incredibly misguided as to what a complementary wearable should be are what are being developed. Not to mention that the Pebble classic on launch was $99 USD whereas one can easily find $400+ smartwatches that still have way too much compromise in comparison.

[-] jrgd@lemm.ee 92 points 7 months ago

VideoLabs is made up of many of the same contributors of VideoLAN, including Jean-Baptiste Kempf themself. It is arguable that this is in fact Unity banning VideoLAN's VLC bridges for media playback in Unity.

view more: next ›

jrgd

joined 7 months ago