Although that link exists, that's not what is being used by default. [[ is a shell builtin in ash/busybox, so that takes precedence.
On Alpine:
❯ which [[
/usr/bin/[[
❯ command -V [[
[[ is a shell builtin
jntesteves
joined 1 year ago
gog galaxy through wine is not an option...
That's the primary way I install and play GOG games. It's easy to set up using Bottles. Galaxy used to run horribly on Wine, but it has improved recently. I help maintain the Galaxy installer in Bottles, and earlier this year we increased its grade from silver to gold, meaning all functions work with minimal glitches now.
It isn't perfect yet, it lags for about a minute right after launch, and I'd recommend going into settings and disabling the "Cloud saves" and "Overlay" features as these can cause crashes sometimes. Other than that, everything works well and performance is good.
If you have read it, you might have noticed that the theme of the article is a company called Chainguard. Enterprises can pay them and get a secure software supply chain all the way down to the container image. More than that, their container distro is actually free and open-source, anyone can use it for free, it's a one line change in your build script to go from Alpine to Wolfi. Enterprises can also buy a secure OS for bare-metal from Red Hat, SUSE, etc...
This article lacks focus and mixes unrelated security concepts in questionable ways. It ends like just an ad for Wolfi. Don't get me wrong, Wolfi is neat, it's probably deserving of being talked up. But it doesn't solve the supply-chain issues pointed out by the article (it doesn't even try). Supply-chain attacks are currently not a major issue in Linux distributions, and enterprises are already tackling the issue of provenance elsewhere, and the article itself notes that. Dependency management for enterprise software is NOT the responsibility of Linux distros. So what is the point of the article? To me, this article is security mumble jumbo.
I believe the platform power profiles are standard nowadays and coded in the bios, so Linux should have access to them just like Windows does. You can use the powerprofilesctl command to list and change power profiles. Gnome also has a Power Mode switcher on the top menu, it's the same thing.
I can talk of my experience with the 2021 Asus ROG Strix G15, I have 3 power profiles:
- performance: Power limits to max; Aggressive fan curve with speed limit to max. Generally loud fans. I need this to play demanding games in the summer.
- balanced: Power limits to max; Moderate fan curve with a medium limit. Great perf (under sane ambient temp), while not too loud.
- power-saver: Lowered power limits; Quiet fans.
Those seem to correlate exactly with the power profiles in Armoury Crate: Turbo, Balanced and Silent respectively. I don't think there's any performance being left on the table.
Gaming laptops with AMD CPU + AMD dGPU are a great suit for Linux gaming.
Also, AMD GPUs benefit a lot from undervolting, which is safe to do. It's free performance. I've made a simple systemd service to keep the undervolt always active: https://codeberg.org/jntesteves/amdgpu-tune
Thanks for the report. This issue was supposed to have been fixed in the Flatpak package, but you just brought to my attention that part of the fix was accidentally reverted. I'm sending a new PR right now to try to fix the issue again.
Here's the update, I've got the USB-C/HDMI adapter today. Connected it to the port that connects directly to the dGPU and even during boot Plymouth was already outputting video to the TV. I also tested hot-plugging and it just works as expected.
Now for the problems, I ran benchmarks and the performance was as expected, but frame delivery didn't look as good as when using the HDMI port on this device. It doesn't show on the performance metrics, but looking at the screen, the frametimes looked off, stuttering. I'm still figuring out where the issue might be to report it to upstream. EDIT: For people reading this in the future, I've found the issue to be in GNOME's compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/3070#note_1865351
Itch has its own launcher which has a native Linux version, you can find it on Flathub: https://flathub.org/apps/io.itch.itch
Although it doesn't get many updates anymore, feels like it's on maintenance mode. It supports installing both Linux and Windows versions of games and even launching the Windows version with Wine, although without any DXVK/VKD3D options, it's kinda bare-bones, but for the generally simple indie games on the platform it usually works fine.
I hear you, I have a Legion laptop with a GTX 1060 mobile and I keep the dGPU as primary all the time because I just can't be bothered by NVIDIA optimus anymore. That's the reason I decided to upgrade to AMD, even though the performance of the 1060 was still appropriate for me and I wouldn't have upgraded yet otherwise.
I don't have any issues with the Strix G15 on Fedora Silverblue. Talking to other owners of the same model and also other Asus AMD laptops on Reddit, I didn't hear any complaints about that.
The G15 has the HDMI port connected to the iGPU, and the USB-C (DisplayPort Alt Mode) connected directly to the dGPU. I've only used HDMI to connect to a TV, I haven't tested the USB-C output because I don't have a monitor with DisplayPort. So I can't really answer your question.
Tell you what, I've just ordered a USB-C to HDMI adapter, as soon as it arrives I'll test the output that's connected directly to the dGPU and update you on that. I'd bet on it being plug-and-play, but we'll see. 😉
You shouldn't generalize your bad experience with NVIDIA's proprietary driver to Mesa. Graphics device switching just works on Mesa, hence laptops with an AMD dGPU are great on Linux.
Typing this from a 2021 Asus ROG Strix G15 Advantage Edition
I've created a tool for similar of use-cases: https://codeberg.org/contr/contr
You could run your workload inside, say, an alpine container:
cd path/to/evil/dir
contr alpine
❯ # inside container, run dangerous program
❯ ./dangerous_program
If the program needs extra dependencies, you'll have to write a Containerfile and build an image with the dependencies installed – there's an example in the repository. Just installing the dependencies at runtime inside the container is also an option, but all changes inside the container are lost on exit.
SELinux in Podman works pretty much the same way it works on Docker, so if you are having problems with Podman, you should also be having problems with Docker, so I don't see how that's impeding your migration. You need to be more specific about the issues you're having to get a good answer.
The post by Chris Smart you linked on your comment below is a good start, but everything there also applies to Docker, so if you still didn't know those basics, you shouldn't be able to use Docker on Fedora either.
About your question of how to set it up, use-case is an important consideration, there is no generic answer that covers all use-cases. I've even found out that for some use-cases (like ad-hoc containers), disabling SELinux within the container (with
--security-opt=label=disable) seems to be the most secure option. That's what I've done in contr (see this commit message). I've been meaning to blog about that, but never did because I'm in the process of migrating my blog but too lazy to finish it.I've put a lot of links about SELinux in containers in this issue.