Technically, GOG is completely correct. Their native Linux builds don't officially support Arch Linux or the new SteamOS, which is a derivative of that distribution. They support Ubuntu. They can't guarantee support for an OS they've never tested their games for.

Whether this PR spokesperson understands this or not, I couldn't say. Clearly the diplomatic response would have been, "these games have been tested for Ubuntu officially, but they may work on the Steam Deck. We don't know; we haven't tried it."

View this comment - View article - View full comments

Quoting: fenglengshun

Quoting: pleasereadthemanualA number of things have to get a lot better before visual novels on Linux are a good experience, let alone the Steam Deck. I wish it were better.

...that's interesting, but I kinda just don't really care? If I can get a game on Steam, I'll buy it there, assuming it's uncensored or there's a restoration patch. If there aren't, then I just go to the high seas. Though it is interesting that you don't mention Johren/Shiravune (which is a spin-off of DMM/Kadokawa), the old timer MangaGamer, Denpasoft, Kagura Games, Fakku, DLSite, JAST, and Nutaku.

I did mention Johren briefly. I don't have any experience with Johren aside from the horror stories I've heard about their DRM. I don't imagine it will work on GNU/Linux, but who can say?

I also mention that DLSite is the only good site that Japanese players can get Japanese VNs from because the DRM actually works on GNU/Linux.

I think that English VN players are better off buying VNs directly from localization companies like MangaGamer and JAST, which I alluded to by saying that "Steam is not a great platform for VNs." and saying that players are better off "buying it on another store in the first place." In my opinion, JAST and MangaGamer (as well as other localization companies' stores) are much better stores than Steam because all games are DRM-Free, the prices are better, and you don't have to patch in the Adult Patches yourself...on a handheld.

It seems that you didn't read part of my response.

My point was that for Japanese players, their only good options are to either to install Windows, only buy physical/from DLSite, or, as you say, torrent the games. That's not a great experience. I don't encourage downloading games from file sharing services—particularly in an industry where a lot of the participants are from Doujin circles. If I can't play it...I'll wait until they release it unencumbered or not at all. Fortunately, most publishers do so with the physical release, so I don't feel like I'm missing out on much. The other obvious reason is that downloading executables is inherently dangerous, no matter how much you trust the release group, because unless you're a good reverse engineer, you have no way to tell what has been done to it.

QuoteI don't see it as fundamentally that different than the usual case of buying VNs as an English players, especially with Wine/Proton 7.0 seems like it's fixing codec issues now (which took the bulk of the old setup instruction.

I can open VNs games just fine with a double-click with Wine most of the time, maybe set `LC_ALL=ja_JP.UTF-8` and `TZ=Asia/Tokyo` variables which is easy with Lutris (the flatpak version works fine for Wine games) and Bottles (also has flatpak version) or just with Steam's Add Non-Steam Games functions. Textractor seems to work just fine so long as you run them in the same winepfx as the game (much like running CheatEngine, which works just fine aside for the speedhack function).

I don't think this is particularly difficult myself, but I wouldn't call it a great experience on a handheld, having to type in a series of global environment variables, thumbing through your file system to find your game and link it up to Lutris, and again to find the cover art. And if you want it to show up in your app launcher, you need to create a .desktop file and edit it to manually link up the app icon by typing it in so that it's not a blank icon.

Steam's "Add Non-Steam Games" function doesn't work unless you already have a .desktop icon for the game—it can't find it. To do this, the easiest way I've found is setting it up in Lutris first and then generating the aforementioned .desktop file.

Most non-Linux users are not going to know how to do this, and are probably not going to want to do this when the alternative on Windows is "double click the .exe and click through a wizard."

I regularly link to that guide; it's the best setup guide of them all. I'd also rank it as the best overall Japanese guide.

QuoteMaybe for the Japanese people who want to buy JP games legitimately, but for that market it's only recently announced that they're going to open pre-order there. Though even then, last time I tried DMM to play Princess Connect, it managed to install just fine, with the only issue being the hand-off between starting the game on DMM to the PriCone.exe running which I wouldn't discount being fixed by Wine 8.0 since they seems to be tackling a lot of old issues this year (like WoW64, which is the other bulk of that old VN setup instruction). Besides, those market are currently mostly covered by Switch (aside for eroge, ofc).

I've purchased 4 games on DMM, and none of them work. They all use Soft-Denchi. I'd be grateful if you could confirm what DRM the game used, because that might mean that some games from DMM do work on Linux. Additionally, it is very unlikely that any DRM schemes have been fixed in the newest WINE release. I contacted Codeweavers support directly and they expressed no interest in working on Soft-Denchi compatibility, not to mention that DRM support in WINE is the hardest and most thankless work there is. An excerpt from this link:

QuoteIn an effort to make copy protection more effective (i.e. resistant to cracks), the methods used by many copy protection products have become complex, difficult to understand (obfuscated), and hard to debug. In some cases Wine would need to be altered to allow for almost rootkit-like functionality of programs to get some of these copy protection schemes to work. To support copy protection Wine developers have to contend with undocumented interfaces, code obfuscation, and maintaining compatibility with *nix security models.

If 88% of people not buying the releases for one company is any indication of how few people actually buy VNs, maybe this won't be an issue for Japanese players after all. Only the people who actually buy the games.

QuoteSo, yeah, that's some neat things to know, but a lot of that aren't particularly relevant to me, and most of the issues seems like it'll be solved or has a fairly simple workaround.

I mention the simplest workaround of them all in my response: use Windows. The Steam Deck would be fine on Windows, even for Japanese users. The issues that arise are purely due to the Steam Deck running Linux, and (by extension) the majority of the games from the VN genre not being on Steam. These games not being on Steam on a Windows version of the deck isn't an issue because these DRM schemes were built to work on Windows, as are VNs in general.

View this comment - View article - View full comments

Quoting: fenglengshunA lot of people in the visual novel community was interested in Steam Deck as a VN machine, and those people can pay a lot of money to import stuff from Japan and just want people to accept their money to get something officially. They're also already pre-disposed to like handheld like Switch and Vita, even though most VNs are on PCs. So they might be a good customer in the future if codec is really 100% working now.

I can't speak for the average reader, but I will say that Steam is not a great platform for visual novels (even if it seems convenient at first). Comparatively few are released there, and there's been outcry about removing adult content from releases due to Steam's rules about not exploiting minors. The vast majority of publishers on Steam are localization companies like Sekai Project and Mangagamer, not actual Japanese publishers.

Take the release of Wonderful Everyday Down the Rabbit-Hole on Steam. The first ~5% of the game is available on Steam for purchase, but you have to download the other 95% which includes some R18+ content from the publisher's site and move it into the game folder. This is not a great experience on PC, and it's even worse for a handheld. This type of release is not particularly unique. Publishers like JAST will release part of the game on Steam and offer Adult patches on their website, which completely defeats the convenience factor. Other publishers, like Moenovel, will gut that content from the game completely while serving customers a mediocre localization that clearly hasn't been proofread very well.

Japanese publishers don't use Steam to get their games to a Japanese audience; they use DMM. DMM doesn't have any of the same draconian temperament toward R18+ content in visual novels as Steam does, and it's HUGE. There are thousands of visual novels on DMM. And DMM games don't work on GNU/Linux, full stop. They are shipped with either the Soft-Denchi DRM (doesn't work), DMM Game Player (always-online DRM that many find annoying and almost certainly doesn't work on GNU/Linux either), Buddy (doesn't work), or something else that doesn't work. I have yet to find any DRM-free releases. Yes, you can buy your porn games on DMM, as long as you're a Windows user.

Like it or not, there's a reason that "eroge" is the term many in the community use to refer to these games. A lot of them include various detailed sex scenes. The objective of many of them is romancing a "capture target" to get to that payoff. Steam does not like visual novels that include adult content and bans games quickly and harshly, usually without opening a channel for communication with the publisher at all. It's often hard to tell whether the game will end up being banned by Steam or not, especially as it can come months after the initial release. Not to mention the pushback you get from a certain segment of readers even when you do manage to get an All-Ages release past Steam's gatekeepers.

I don't particularly care about sex scenes in eroge, but they sure can cause a ruckus, huh?

Then, there are the Japanese readers. Many releases on Steam do not come with a Japanese language option, especially the ones with adult content. These readers can't get games from DMM as mentioned before, but they can get some of them from DLSite. PlayDRM does work on GNU/Linux, but you have to be careful about which games you purchase because some can include the incompatible Soft-Denchi DRM (they do tell you on the site if it does). There's also Johren for both English audiences and (I believe) Japanese audiences, but many don't like them because of the always-on DRM with only 3 activation codes, which they probably won't give you any more of. It also probably doesn't work on GNU/Linux.

Their best bet is actually physical releases, because they tend to come with no DRM at all, but it's often hard to know whether a game will work until you try it. Dies Irae, for example, will not work because of the DRM. Aiyoku no Eustia's AlphaROM DRM doesn't work either, but you can get a file from AlphaROM's SETTEC site that you place in the same directory as the game to bypass the check (apparently it's flaky even on Windows). But the majority don't seem to include DRM at all.

Even with all the trouble you go to, you still end up managing WINE prefixes instead of just launching it with Proton because there are so few visual novels available on Steam in Japanese, the original language they were published in. I can't imagine that being particularly fun or convenient. And, of course, for those learning Japanese, setting up Textractor doesn't seem fun on a handheld either (and Textractor rarely works with VNs on Steam), but this is a niche within a niche.

I don't see the Steam Deck being a particularly good VN machine unless it has Windows on it, or the user is willing to circumvent DRM (which is only legal for this purpose in a handful of countries). I don't think Steam is a great platform for Visual Novels either, even if we take the operating system out of the equation. The moderation has been shown to be repeatedly hostile to these games, with publishers often spending months stripping the VN of content that might trip the alarms, and then having to either deal with complaints from their readers about not including content that was in the original release or offer the content separately as a patch (assuming they don't just ban your game altogether), and at that point, why not just buy it on another store in the first place?

A number of things have to get a lot better before visual novels on Linux are a good experience, let alone the Steam Deck. I wish it were better.

View this comment - View article - View full comments

All of the studios that are enabling support for Proton with BattlEye and EAC are going to realize that Epic shipped a fundamentally broken anti-cheat system that will work for "some games", as long as you don't care about cheaters.

View this comment - View article - View full comments

To make your competitive game available for Linux distributions, you need to suffer more cheaters. Who is going to take a proposition like that?

Well, it was fun while it lasted. There's no crossing this roadblock unless developers/publishers intentionally handicap themselves for potential profit while the rest of the playerbase complains because of the significant increase in cheaters.

Tim Sweeney's argument about the profile of the game doesn't make sense in the context of EAC. Cheaters will be attempting to bypass EAC, not the game itself, so their strategy will work for all EAC games that work on Linux.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>
or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.

The package I was trying to build from source was yt-dlp about half a year ago. I spent about an hour looking around, but there didn't seem to be a clear-cut way to do it, so I inevitably just gave up and built it from source "the normal way". I'm not sure about the other reasons for building from source, but I'm so used to using Pacman to manage packages that I build with `makepkg` because it's an easy way to keep track of packages and cleanly uninstall them.

I made the mistake of using pip to install protonvpn a year ago...never again. Using pip is a surefire way to create an unmanageable mess of packages that Pacman inevitably gets confused with.

The documentation is really a goldmine. I always find myself there, learning new things about software that often the upstream developers haven't bothered to document. I've heard about FreeBSD, but haven't had the occasion to look into it.

View this comment - View article - View full comments

As long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

View this comment - View article - View full comments

While checking to see if Flatpak supports musl-based distributions like Alpine (it does), I found the antithesis to this article: Flatpak is Not the Future. Well-reasoned and includes points that I simply didn't know about.

View this comment - View article - View full comments

Quoting: CyborgZeta

Quoting: pleasereadthemanual

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR. Flatpak is way too much complexity for me.

I'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

I look at it this way. The less dependencies on my root filesystem, the less chance of breakage I have when updating the OS or programs. I have encountered dependency hell issues on Ubuntu + Debian before; so that's one reason I like using Steam as a Flatpak, because I'm not introducing a bunch of 32-bit binaries to my filesystem.

This is the primary reason I avoid the AUR. It has nothing to do with trust. I did my research before switching to an Arch-based system, and most of the people I talked to told me that the majority of stability issues they'd run into with Arch involved programs installed from the AUR. I don't use the AUR because I don't want anything from outside the official repositories on my computer. Flatpak at least has the courtesy to not touch my filesystem and update independently of the core OS. Perhaps your experience running Arch is different, but I've been doing things this way for over a month now since installing EndeavourOS and have had zero issues with the OS itself.

As for Firefox, well I only have few extensions installed myself, uBlock included. I just like the sandbox because the way I see it, if my browser is somehow compromised then at least it's separate from the root filesystem. Also, I've noticed that using the Flatpak gives me a less identifiable fingerprint when checking https://www.deviceinfo.me/

From a stability perspective, sure, I can see the virtues of Flatpak. And it might be a good way to go for newbies in the future—but only if it's more reliable than ordinary binaries. I've seen people having more issues with Flatpak packages (including Steam; I've heard people say they couldn't get Proton to work through the Flatpak version, etc.). So while the stability of the system overall is improved, Flatpak packages themselves may not be reliable—this is one reason I always go to the AUR first, because I know things will generally "just work". Flatpak packages by their nature are far more complex and prone to issues you won't find in ordinary binaries. I hope this is improving over time, but I wouldn't have a clue.

It's good that you don't avoid the AUR out of trust issues. The trust level should be exponentially higher than installing a PPA binary that somebody has compiled for you versus a short bash script that you can examine closely for issues. AUR packages can certainly be less reliable, that's true, but it depends on the package. AUR packages are exactly the same as ordinary Arch packages; the only difference is that they aren't in the official repositories. They are all built with PKGBUILDs. The differentiating factor is the quality of packaging.

Take Anki as one example: it was dropped from the official repositories, but seems to still be maintained by developers/packagers for Arch. The quality of this package should be high. AUR packages are also compiled inside of a fakeroot and don't touch the root filesystem until after they've been compiled, and then most only enter the root filesystem (with your permission) to add the package to the PATH and maybe add some documentation. I personally haven't faced any stability issues with the packages I've used, as you speculate.

I'm not saying that you should use the AUR if you don't want to and you're doing something that's already working for you, but that it's certainly a valuable place to find software.

Perhaps it's separate from the root filesystem, but your most important information tends to be in your home directory, which software don't need any permissions to access. The best way to protect against malware and exploits, unfortunately, is to not get hit in the first place. Relevant xkcd.

View this comment - View article - View full comments

Quoting: Eike

Quoting: pleasereadthemanualI still don't really get what the audience for the Steam Deck is. I kind of want to buy one, but then I remember I have no use for it. I can play games in bed with my laptop. I have 4 GNU/Linux computers already. If I'm outside, I don't want to play games, otherwise I wouldn't have gone outside.

I guess I don't really understand the portable gaming idea to begin with. I did play Pokemon a lot as a kid, but those days are long gone. I played a lot of mobile games when I was younger, too, but that was mostly the novelty of it rather than them being any good. I don't think that phase lasted very long.

I guess it doesn't help that a lot of the games I play involve using Textractor, copying text to the clipboard, looking it up in a J-J dictionary, and creating an Anki card. Not really the type of gaming suited for a small, portable device without a keyboard.

I just have no idea what to think, because I am clearly not the target audience for this.

Well, there's obviously a target audience for mobile gaming. The target audience for Steam Deck is mainly the intersection of these with the Steam users. They already own (often lots of) games running on Steam Deck, and they can play games bought for mobile on their PC as well.

The appeal of mobile gaming? Well, I'm not into it either, but I can understand that a laptop is too big for bed for many. And back in the days, before Covid, I was using public transports for a 3/4 hour to work and a 3/4 hour back. Time for gaming, maybe?

I would guess also that a lot of people don't own laptops. It's not hard to see why. They're harder to maintain, upgrade, or replace parts (or at least more expensive).

Half of my computers are old Dell laptops (fantastic to repair while still in warranty). In the past 6 months, the USB hub in one of them appears to have shorted out or something and can only push enough power to storage devices and nothing else, the NIC in another laptop died and I had to buy a USB NIC (which meant several hours trying to get the out-of-tree realtek driver work on a new Arch install, but I learned a few new tricks), and the battery in my other Dell laptop no longer charges (thankfully it has an extra bettery).

Oh yeah, and with the ASUS laptop I bought exactly 2 years ago, the cord for the power brick, as it's called, stopped working and I needed to replace it with one of the cords I kept from somewhere or other. This led me to look up finding a replacement charger for this laptop—not easy, ASUS lists it but doesn't sell it. There's an Ebay listing, and that's about it.

All this to say...yeah, I get the appeal behind a smaller, easier-to-maintain device where the vendor actually sells replacement parts and is happy to let you repair your own device or find a willing third party to. I don't even know what I'm going to do when the power brick for my ASUS laptop dies...go to Ebay, I suppose.

I have half a mind to blame GNU/Linux for breaking all of these laptops (as I only installed it on them in the past year or so), but realistically, they've probably just seeing a lot more use than before.

I had a friend who got into XCloud or something similar while commuting, but me, I just don't really care for playing games in public or out and about; I'd rather read a book, personally.

Now, if only Worm came out in paperback...

View this comment - View article - View full comments