Is Steam off Flathub that complicated on Slackware?
- Download Slackbuild helper (similar to yay for the Arch User Repository)
- Install it
- Read dependency info for Flatpak Slackbuild (you can also do
sqg -afor the entire repository) - Install it
- Add Flathub repo
- Install Steam Flatpak
It’s not that complicated.
A young broke me once spent 3 weeks after school each day in 1994 downloading slackware floppy images from my Dad’s AOL account via modem so I could try it on my 386.
With dial-up that probably cost more than buying Slackware.
I had a very similar memory. I had an IBM Aptiva 386SX with Windows 3.1 on it. I wanted to try this new thing called Linux and remember wiping everything without know what I was doing.
Plesse, no flatpak TwT
I tried the Slackbuilds version of Steam first, but it didn’t launch Skyrim, so my PC was completely useless.
loved the 90’s slackware era “oops i forgot to burn this with network drivers… and it was my only machine.”
do u remember when they warned you if you got the dot pitch setting wrong for your CRT it could destroy it? I was like wtf?
Are you sure it was dot pitch and not dot clock?
Dot pitch on a crt might make the image look bad (trying to draw onto the shadow mask) but I doubt it would damage it.
Setting an invalid dot clock could damage some crts. But most of the modern (read from mid 90s on) would just go to the power save mode when they got a clock they couldn’t use. The warning did still remain on the xfree86 configuration guides though.
Showing my age perhaps.
That was a plot point in Cryptonomicon. And yeah the XFree86 docs mentioned it too…
I had to hoof it to a friends house with floppies a few times after breaking my system. Good times.
Services.steam.enable = true;
Works easily on Nixos. It’s true that I haven’t yet gotten a game to PLAY on Nixos other than Minecraft, but that’s beside the point.
You forgot
nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [ "steam" "steam-original" "steam-unwrapped" "steam-run" ];and here I thought running Slackware was a waste of time…
I’m not using unfreePredicate so I didn’t think that was necessary.
Maybe I should try it anyway. Games start but even the menus are so slow that I never get to actual play.
You can also use this lil guy, but by default you can’t install unfree software (not sure if that is different if you use flakes):
nixpkgs.config.allowUnfree = true;
Average Linux user: “we could just use the Windows totally-not-an-emulator!”.
(They’re this close to getting the point while saying it.)
I’m far away. What is the point?
The point is: If “just simulate a Windows environment” is the best thing you could come up with, chances are that Windows is what you should use anyway.
I’d rather simulate some Windows function calls on a system I control than install Windows and give up all control over my system to a foreign corporation.
This. I don’t want windows. I want to use Linux and hope more developers make a native Linux version of their game when they see it growing in the Steam user stats.
You give up all control over your system to other US corporations though, like Red Hat (who are - and should be held, IMO - responsible for systemd) and Microsoft (who contribute quite some code to the kernel). The only system you control is a system you write, I’m afraid.
Red Hat: Hi here’s some tools we made, you can see how every single one of them works in full detail and you can modify them as you see fit, and distribute modified copies.
Microsoft: Hi we peddle proprietary spyware and we aren’t even secretive about it.
Basically the same thing?
Also systemd rocks, and the kernel is widely audited OSS, Microsoft will have a very hard time sneaking in anything malicious.
systemd rocks
I disagree.
the kernel is widely audited OSS
Minus the proprietary blobs, that is.
“Everyone can see the code” does not mean that everyone understands what’s going on, by the way. The X server had had a security hole for 23 years just a while ago. Could it be that “it’s OSS” and “many people read and understand what’s going on” are not the same thing?
The fact that software contains vulnerabilities is not the same as the fact that the software has been specifically designed to monitor your activities. I don’t understand what your point is, seems like you’re trying to say that the difference in the surveillance performed by Microsoft and the one performed by Linux is irrelevant.
TIL letting my teacher make suggestions on my draft means they control the entire contents of the final paper
It’s not just that your comparison is so far fetched it already disconnected, what you say is also plain wrong. You don’t give up anything in this constellation.
Setting aside the fact that that is not even remotely true, do you think Linux = Red Hat? What about almost every other distro being run by volunteeers?
I’ve only ever seen redhat used by government and some corporations. As far as the broader community goes (especially the foss community), they are a pretty minor player.
It’s honestly insane that you can sit there and shill for Microsoft these days. They’ve always been pretty evil, but now they’ve gone so far off the deep end they’re even driving away people who have been all-in on Microsoft their whole lives. Even non-tech people are getting simply fed up with all of the spying and intrusive, AI-infested bullshit. Linux marketshare has been steadily increasing over the last couple of years, and it doesn’t look like it’s slowing down anytime soon. And all of it is, ultimately, because Windows is forcing people away.
Please stop feeding the troll, for crying out loud.
What about almost every other distro being run by volunteeers?
You misunderstood: Red Hat The Linux Distribution (not quite relevant for Linux development) is not Red Hat The Commercial Entity (quite relevant for Linux development). However, volunteers repackaging (“distributing”) Red Hat software still don’t change the nature of the software, but that’s a different discussion.
It’s honestly insane that you can sit there and shill for Microsoft these days.
I do not do that. What I actually wrote is: By moving from Windows to Linux (assuming you use Linux-libre), you gain a certain level of freedom, but that freedom still relies on commercial entities and their own ideas that are contributed to the kernel. Just because you can see the code, you still can’t decide about the code.
Note that I do not use Windows. You make it sound like I would.
Let’s leave it at that. We probably won’t solve this debate over Christmas, and life is too short to argue about software. :-) Have a good one.
I don’t use systemd, and Linus Torwalds controls what’s actually allowed into the kernel.
thing is, windows is shit at being windows
True, sadly.
Eh, I’m not gonna switch whole OSes to the most invasive spyware I can readily find just for the once every 3y I need to spin up PKhex, wine will do.
Maaaaaybe when Windows wasn’t actually disrespectful to its user base but now that they’ve gone full “we know what’s best for you” and are actively ruining their OS and fucking with their users to push garbage tier AI shit no one wants… Yeah, miss me with this shit man.
Linux respects the autonomy of its users and for that reason alone it has gained me as a user.
On some machines PC games actually run better under SteamOS than Windows but sure, use the inferior OS if you insist.
I use neither. Just wondering.
Wine or proton
Install slackpkg+, install multilib, enable alienbobs repos, install steam. Like, yes its not holding your hand but it also gets out of the way for everything.
Here is how I install Steam on Debian:
sudo dpkg --add-architecture i386 sudo apt update sudo apt install curl curl -s http://repo.steampowered.com/steam/archive/stable/steam.gpg | sudo tee /usr/share/keyrings/steam.gpg > /dev/null echo 'deb [arch=amd64,i386 signed-by=/usr/share/keyrings/steam.gpg] http://repo.steampowered.com/steam/ stable steam' | sudo tee /etc/apt/sources.list.d/steam.list sudo apt update sudo apt install steam -yEdit: Added a fancy block.
Most of that is setting up third-party apt repos, which I don’t believe is necessary. Steam’s in the Debian trixie repo.
https://packages.debian.org/stable/steam
EDIT: I’d guess that the following would probably work on a Debian trixie system:
If you have your system set up for only 64-bit packages, you’d need this at some point prior to the install, to let your system use 32-bit packages, since Steam’s only available as a 32-bit binary:
$ sudo dpkg --add-architecture i386I think that deciding whether to use both 64-bit and 32-bit packages or not is an option in the Debian installer, but I might be misremembering.
You can update your list of packages at this point, upgrade, all that, but that goes for any install operation; there’s nothing specific to Steam there. If you’ve just added 32-bit packages for the first time above, then you probably do want to update the list of packages, since your system won’t have a list of 32-bit packages yet.
$ sudo apt updateBut then it’s just like any other installation of software.
$ sudo apt install steamThat actually just contains, as I recall, the Steam installer — enough to pull down and install the current Steam environment for a given user, which happens next time you run the Steam binary.
$ steamEDIT2: I guess that assumes that you do have “contrib” enabled on the Debian repo, and I don’t know whether that’s enabled by default by the Debian installer or whether it’s an option during install or what. I do distinctly remember one point in time when “non-free-firmware” was not enabled by default, because I always had to turn it on to get support for <random hardware device with closed-source firmware blobs>, but I don’t know whether contrib is always enabled or not. I have main, contrib, non-free, and non-free-firmware enabled. From
/etc/apt/sources.list.d/debian.sources:Types: deb deb-src URIs: http://mirror.i3d.net/debian/ Suites: trixie Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpgUsing the official Valve repository is my preferred method because it provides a direct line to the developers, ensuring you get the latest GPG keys and installer updates immediately without waiting for them to make their way through the Debian maintainers. While the Debian repo is convenient, it requires you to enable contrib and non-free components globally across your entire system. The method I suggested adds Steam as a specific source without cluttering your main package list with other non-free software. This also makes the installation more consistent across different versions of Debian. Whether you are on Stable or Testing, you are not at the mercy of Debian’s specific package transitions or library freezes, which can occasionally break the Steam bootstrap process in the community-maintained version. I do not believe either way is better, just different for different types of users.
sudo sboinstall steamI tried installing it natively, but that requires activating multilib first, and even then, some of my games didn’t launch, complaining about missing stuff. Flatpak is just all around less hassle for Steam, but Steam is also the only thing I use it for.
some of my games didn’t launch, complaining about missing stuff.
I don’t know Slackware, but I know on arch there’s the standard steam runtime version, and then there’s the unofficial
steam-native-runtime, which uses system packages instead of steam’s own bundled runtime. And if we’re talking native Linux games, which is where the problem is, they tend to not work with steam’s runtime, presumably because they weren’t properly built to target it, and need to be launched with the native runtime (or switch to running the windows version with proton…)Never tried Flatpak… I usually avoid Flatpak altogether. Multilib is usually just three commands from here http://www.slackware.com/~alien/multilib/ Then I just install my nvidia driver manually using the .run file after a kernel update before I startx (I’ve done it this way since 2002, never had issues).
Aside from that, I’ve never once had problems with games on Steam, or with Steam itself.
Flatpak is the demiurge.
