You may be interested in reading this post about the process of packaging Steam.

tl;dr: It’s mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that’s the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.

If you hate job boards then you need to find individual company “Careers” pages and go from there.

How you go about this varies a lot by skillset and industry, but I’ll just throw out a random example: lots of Linux jobs exist in the DevOps space (think Kubernetes, Ansible, Chef, NixOps). It just so happens that lots of medium-sized software companies need DevOps people, so you can pretty easily find companies looking for DevOps hires just by browsing Y Combinator’s Startup Directory

With that being said, I get the impression from the way your post is worded that you’re looking to break into a new career without having yet established a concrete plan. My advice would be to step back and consider specific options first. Almost all jobs like these require industry-specific certifications (e.g.: CompTIA, ITIL, AWS, Azure, Cisco, etc.). You need to look at your options, pick a certification, earn it, then go job hunting. Certifications are great for securing entry level jobs and the standards body issuing these will often provide an online directory of partner companies who are currently hiring.

You’ll understand when you’re older, son

Ugh… they got Plasma everywhere!

Try Satty? It’s inspired by flameshot, Wayland native, and written in Rust.

Nice. Flagship features like these so often feel overlooked in the Linux GPU discussion. I like to think that’s because we’re all very serious pragmatists who don’t care for such frivolous addons, even if the simple truth is that vendors are indifferent towards Linux as an end-user platform.

In light of that, features like these coming in with 1st-party support is a welcome sign that things are (slowly) changing. Emphasis on “slow”; I don’t find it terribly impressive that Nvidia’s partially reversed the proprietary own-goal which they call NVAPI, especially considering the still ongoing parade of new (also proprietary!) standards which they insist on shoehorning into it… but I’ll acknowledge that they’re making progress nevertheless 😤

Yeah, I’m subscribed to notifications for the PR and have been holding out waiting for it to get merged because it’s easier to maintain a clean git history that way. If the PR’s still not merged by this evening I’ll just bite the bullet and do it the (slightly) harder way for the sake of staying current with the new seasonals

I am of two minds:

1. He’s not wrong
2. It doesn’t matter at this point

It’s a mess, but honestly so are a lot of critical FOSS projects (e.g.: OpenSSH, GNUPG, sudo). Curmudgeons gonna curmudgeon. There was a point of no return and that was years ago – now that Wayland’s finally becoming useable despite itself it’s probably time to come to terms with the fact that better alternatives would have arisen had anyone thought they could truly manage it.

Hmm… what’s the purpose of loading amdgpu at all if you’re using an NVIDIA card? Optimus?

Your best bet is probably figuring out why the graphical session isn’t working and then going from there. Since you’re on NixOS odds are all the logs you need are right there in journald.

Worst case scenario: you might need to pin your system nixpkgs to ~January 2021 until the issue sorts itself out. You can still install newer userland packages if you separately manage them as a flake (this is a common and well-supported pattern in home-manager)

EDIT: found a discussion with good configuration.nix examples for pinning the system nixpkgs. Once you find a workable pin you could also try inching it up to get a better idea of what broke (January 2021 is a good starting point because it’s the last month before 5.11 released, a newer pin is very likely possible)

I’d say that’s already becoming the case in a few places. Hyprland isn’t just “Wayland good”, it’s “You should use Wayland good”.

Yes, I know the devs behind it act like pissants. That’s bad and I’m sorry for liking their software. I use Emacs too and RMS was kind of an asshole. Hell, I use Lemmy even though one of the devs has slighted me on more than one occasion.

More importantly: did you know the “monopoly man” does not in fact wear a monocle? We live in trying times.

Exactly. Making the game WINE-compatible is not the same thing as committing to support. In reality, the only thing stopping WINE from working is Epic Anti-Cheat and the absurd thing about this is that Epic already gave EAC a WINE-compatibility mode – they’re just actively choosing not to turn it on.

What Tim’s really saying is this:

I don’t want our flagship game to be used as a way to highlight Steam’s better Linux support, so the game won’t come to Linux until EGS on Linux is at parity. Unfortunately, it doesn’t make sense for us to bother doing that right now because the Linux usershare is too small to matter.

Wayland is Wayland. If you use a Wayland compositor, you’re getting a lot of security by virtue of design alone. Things like keyloggers and screenrecorders will not be able to intrude on your session barring vulnerability exploits. I’m not going to touch on the relative vulnerability risk of each environment since a) they’re all relatively new & b) I’ve never implemented Wayland myself

With that being said, here’s what’s not protected by Wayland regardless of the chosen compositor: microphones, webcams, keyrings, and files.

For microphones & webcams, any distro which rolls Pipewire in combination with Wayland will be sufficient to secure these. Pretty much all Wayland environments roll Pipewire so this is only important to consider if you’re running your own customized environment (be sure to disable any pre-existing PulseAudio daemon after setting up Pipewire to close this security hole)

For keyrings, these are handled by your environment’s polkit implementation. Much like Wayland, there are several implementations of polkit and they’re all just about equally secure barring any potential vulnerabilities… Just make sure that you’re using an encrypted database (usually on by default) and that you have it configured to always relock & properly prompt for the unlock key.

For file access, this is actually a core probelm with Linux as a whole – any unsandboxed application you run will be able to read any file that you can read. The solution is to use sandboxed applications whenever possible. The easiest way to achieve this is through using flathub/flatpak applications, since they will always list out and enforce their required permissions on a per-application basis. For non-flatkpak applications, you’ll need to use “jail” environments (e.g.: bubblejail, firejail) in order to artificially restrict application permissions by hand.

I assume you’re referring to the steamlink package and not Steam Remote Play?

If it’s the former, then I can’t really offer much advice beyond what the official support article already recommends.

If it’s the latter, I’m able to verify that Steam Remote Play works just fine on my Wayland Linux desktop when I connect via my Steam Deck.

What an incredible postdiction

In the Steam Link app, you have the option to select “Start Streaming” without picking a specific game. This will stream the screen as it is without binding to a specific window.

The main caveats here are as follows:

• Requires a working pipewire & desktop portal configuration
• Depending on desktop portal & settings, you may need to manually click through the screensharing request modal on your desktop at the start of each connection
• The Steam client must be installed and running on your Linux machine in order to receive connections

Honest answer? Steam RemotePlay

What I’ve done instead is configured a desktop hotkey that toggles the system-level microphone mute. Two birds with one stone: foolproof PTT and on the same hotkey regardless of Zoom/Meet/Teams/Slack/Discord (consulting is fun)

Prior art is instructive: Orca.

To sum it up. Screenreaders are the main assistive interface required by blind users to interact with system applications. Linux screenreaders such as Orca interface with the AT-SPI (Assistive Technology Service Provider Interface) to provide two core functionalities:

1. Structured navigation of GUI elements via a keyboard interface
2. Navigation feedback via a Braille monitor or TTS

So that’s the core. At a minimum, the desktop environment needs to ship with a bundled screenreader and AT-SPI coverage across all GUI system components. Fortunately this desktop environment already exists – it’s called Gnome.

Beyond just… shipping Gnome, the rest of the job would involve curating a list of accessible applications to be included in the out-of-box install, including blind-friendly default configurations. Ideally, there should be multiple configurations to choose from driven by a community wiki plus supporting configuration manager on the OS-side.

As for the underlying base distro – I don’t really think it matters. Immutable distros only provide declarative management for system components and most of what this project would need to cover are userland. It makes sense to borrow many of the children of such distros when building a configuration manager (e.g.: toolbox, home-manager), though these will conveniently work anywhere you want to bring them and thus won’t constain the field of available options. With that being said, the ideal base distro would have the following characteristics:

• Well known, well maintained, well documented
• Official support for Gnome as an out-of-box, first-class desktop environment
• Strong package repository game including current versions of all major assistive software
• Very strong track record of stable releases that consistently boot all the way up to the display server