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!

This was, without any doubt, a prophetic dream. The apocalypse will soon be upon us! Be wary of the four horsemen: Ronald, King, Wendy, and… Chihuahua

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

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.

It’s always a treat to see the wheels of open source & community funding meshing together to bring about a better internet. You and @nutomic@lemmy.ml have already done the honors of thanking the open source contributors, so I think it’s now my turn as an ordinary user to thank you both for your continued hard work and leadership – I have my quibbles, but these do not preclude the giving of a well-deserved and hearty thanks: Thank you! It continues to please me greatly to have the privilege (in both senses of the word) to contribute to the financial sustainability of the project as one of its many small recurring donators.

And, while I’m at it… since the opportunity doesn’t come up often: I also want to specifically express gratitude to dessalines for their (unrelated) work on the thumb-key project. As a long-time user of MessagEase (10+ years!), I’ve become a happy convert to your more well-maintained and open source replacement. So, thanks for that too! Please continue to suffer my past & future criticisms with the knowledge that it always originates from a place of equal parts respect & gratitude.

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

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.

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

Another reason is that “CP” got jokingly coopted by abusers in the form of various dogwhistles (e.g.: “cheese pizza”). It made more sense to adopt a new acronym rather than try to uphold any sense of decorum while sharing ownership of the term w/ edgelords & predators.

Communism with western characteristics?

Nah, dump em’ to /tmp/ and let the user figure out the rest