sudotstar

I can see the use case for someone who wants a single OS install on the Steam Deck that does gaming just about as well as SteamOS does, but has a more fleshed out desktop experience (or even just a different one). The linked article goes into detail on various desktop-focused developments within Bazzite that wouldn’t really make sense for Valve to prioritize in SteamOS itself.

deleted by creator

Only thing I can think of is that it hides from your friends if you’ve played the game an extreme amount of time immediately after purchasing it, though if you exit the 10 day period with close to 240 hours in the game that’s gonna show that off anyways.

In this case it’s referring to the fact that the OS is built upon the same containerization technology used on cloud platforms such as Kubernetes. As a marketing tool it’s a bit buzzwordy, but it’s not about running the core OS components outside of the physical machine here.

Even if the performance is only mediocre, the gameplay will hold up. The game uses a fresh new combat system that merges action combat with turn-based gameplay, the likes of which I haven’t really seen in any other game including past Trails entries, and it’s absolutely a great time.

For the original PS4 release, Falcom released a fairly comprehensive demo that allowed you to play through the entire first chapter of the game, and carry over your save to the full release. They’ve also done something similar with Ys X which released on Switch day 1, so hopefully the Switch version gets a similar demo for both the Japanese and Western releases so you can try-before-you-buy.

I’m interested to see how the game performs on Switch. I played the Japanese PS4 version which was rough at launch but improved with post-release patches. I expect there are going to be some necessary cutbacks (no 60FPS, lowered render resolution, reduced visual effects, the standard fare) but that shouldn’t impact the quality of the game experience at all, it’s a wonderful entry and a great starting point for newcomers in a long-running series that rarely ever has those great starting points.

If I’m not literally touching the content I’m trying to scroll, I’ll stick to the default orientation (scrolling down moves content down). Wayland touchscreen input handling seems to handle this just fine and not couple touchscreen scroll direction to trackpad/mousewheel scroll direction.

I think this game definitely has the hardest shinespark “puzzles”, but the actual execution of shinespark is much easier than in previous games which balances it out. Super Metroid had items where figuring out what shinespark maneuver to do was easy, but actually executing it was difficult, while Zero Mission and Fusion had easier-to-pull-off shinesparks with harder puzzles.

With Dread, the challenge is almost entirely in figuring out what to do, once you know exactly where/when to shinespark the actual execution is very intuitive and feels amazing when you land a complex sequence of shinesparks/speed booster runs/wall jumps.

I haven’t adopted this kind of setup, mainly because Proton just does such a good job I have almost zero need for Windows, but my plan for eventually doing something like this was to also maintain a passthrough Linux VM for any GPU-intensive work on that side.

When I realized that the practical end-state of my system would mean I’d just be running things from within the Linux VM 98% of the time (games that can run on Linux) I kind of dropped the idea.

For me it’s always been after I tried to resize a partition.

I recommend using whatever is the “least hands-on” option for your boot drive, a.k.a your distro default (ext4 for Debian). In my admittedly incompetent experience, the most likely cause for filesystem corruption is trying to mess with things, like resizing partitions. If you use your distro installer to set up your boot drive and then don’t mess with it, I think you’ll be fine with whatever the default is. You should still take backups through whatever medium(s) and format(s) make sense for your use case, as random mishaps are still a thing no matter what filesystem you use.

Are you planning on dualbooting Windows for games? I use https://github.com/maharmstone/btrfs to mount a shared BTRFS drive that contains my Proton-based Steam library in case I need to run one of those games on Windows for whatever reason. I’ve personally experienced BTRFS corruption a few times due to the aforementioned incompetence, but I try to avoid keeping anything important on my games drive to limit the fallout when that does occur. Additionally if you’re looking to keep non-game content on the storage drive (likely if you’re doing 3D modeling work) this may not be as safe.

I have played the original, and will be playing the remaster, though not on Switch, I already own the Japanese version on Steam which will be patched with the localization upon release in the West.

It’s quite a fun, fast-paced game, as Falcom action RPGs tend to be. Being a PSP title originally, I think the game format works well for shorter, pick-up-and-play sessions, making it ideal on devices like the Switch and Steam Deck. No context or experience with the wider Trails series necessary, all connections to the mainline series are just simple references and the game has a standalone story (unless you’re deep in the rabbit hole of lore crack theories).

Not to be too dismissive, but I agree that it should be taken with a grain of salt. I also would expect that somebody who’s supposedly a part of Nintendo R&D specifically will be more likely to be walking around with many attempts at proof-of-concept hardware ideas that aren’t (yet) intended to ship in a final product, and only an incredibly tiny portion of such ideas will ever make it far enough to even be in consideration for a new device.

The ideal end state is “why not both?”, I think. Have an immutable “base” system, and utilize mutable overlays on top for any necessary tinkering or involved activities.

Casual users need not interface with the overlays at all (or do so through very controlled mechanisms, like how Flatpak/Snap, Steam game containers, etc work today), while developers, tinkerers, and those that are curious can create throwaway environments that they can mess with to their heart’s content.

WSL on Windows has its warts, but it shows how such an ecosystem is possible (if you treat Windows itself as a Black Box That Must Not Be Modified). I think the immutable distro ecosystem is on the right track, with technologies like Toolbox/Distrobox to bridge the gap, it will just take time for the tooling, practices, and ecosystem around them to mature and not be as much of a hassle as they are today.

Today, I am running both immutable and non-immutable setups on various machines. My work computer (development) and gaming rig are on a traditional setup, as my specific development needs are not 100% compatible with a toolbox environment, and gaming-adjacent applications like Discord are slow to adapt to the needs of Flatpak containerization. I have a laptop that’s 100% just used for media consumption and shitposting, which is a good use case for immutable distros today and is running Fedora Kinoite.

This is, IMO, the biggest yet least obvious advantage of immutable systems. A traditional Linux environment is “just as safe” as the immutable setups, if only the user/administrator is perfect, never makes a mistake, and always makes the right decisions for now and the future.

Given reality tends to differ from the above, having a system that, at a bare minimum, provides you the “oh shit go back” button to system-level changes, and at best provides a clear, reproducible, trail of actions, is a huge advantage for long-term stability for all users, experienced or not. I’ve been through the school of hard knocks far too many times maintaining everything from server setups to gaming desktops the traditional way, and have committed to “early adopting” immutable distros for pretty much everything except the gaming setup (given the whole suite of proprietary and out-of-date/out-of-touch applications that are basically necessary in that space and not-fully-compatible with the sandboxes and abstraction layers necessary).