you mean, run non-steam games on steam deck, using your existing files?

if so, you’ll need to transfer them and duplicate what the installer does, in a Wine environment like proton, and that’s prone to error and subtle necessities, like this or that software / windows component not being present. it’s honestly not worth it. you can’t (or usually can’t) do this windows->windows, and it’s even harder to go windows->Linux (wine).

if you mean, transfer the steam games from windows to deck, then just enable local sharing.

The Gnome overview is simple enough to use that people think there’s nothing to it.

I’ve never had a better tool for interacting with apps, and I’ve worked with a lot of tools / DEs. There are some that are arguably more fun, or that clearly give better customization options.

…but just being a clean tool that works, provides what you need, looks good doing so, and gets out of your way? Gnome, hands down.

thanks! You’ve satisfied my curiosity, and piqued my interest in MX Linux.

I wasn’t asking for “proof”, I was asking for curiosity.

distro?

if you have an extra drive around, you could try a fresh installation on that drive, then do the things on that that cause crackle.

yep. tha’s them.

this was my thought, too.

solid

The universality or lack thereof don’t really matter to me as much as the accuracy and viability of an opinion.

…but to the point…

The OS has access to everything on the OS, and that means whoever made the OS does (technically) as well. That is true. But it does not make it pointless to use encryption. It means that you have a vulnerability, and anyone who is in the position to exercise that vulnerability can do so. …but:

• anyone who is not in the position to exercise that vulnerability obviously can’t, but they could read plaintext by sniffing your connection - unless you use e2ee.
• The ones who are in a position to exercise that vulnerability must either know you are a target of interest or create a massive monitoring program, monitor everyone, and find you via that method. Both of those circumstances have constraints, and while you are in a safe space due to those constraints, it’s still worthwhile to use e2ee, as that may keep you out of the areas where a bad actor’s affect on you is not constrained.

Security is cat and mouse. If you’re actually caught up in that you the point where you are a real target or task potential target, get Graphene, and be mindful how you use it, or avoid smart phones altogether.

If not - assume that you’re not on their radar until there’s a realistic indicator that you are. …and use best practices, like e2ee, wherever you can.

KDE connect and/or Synching/Syncthing-fork.

I don’t think you’re ready for self-hosting, but getting these installed and sorted out will help you move along that path, plus it will meet your needs in the mean time.

Bit, as others have suggested, get familiar with networking a bit.

You might want to get a raspberry pi or cheap SBC with a good amount of memory and disk space, and fuck around for a bit, trying some things.

This is just bad advice.

i also hit 4 a few times to give more columns to the cpu usage meters.

was gonna suggest similar.

yeah, really lets you lay down sick code like a mad hacker. I love it.

Succinctness, mainly. but honestly, that succinctness call can also be mostly acquired using sh.py, which is what I normally use if I’m using python as a sort of shell scripting - mostly because sh.py is a very minimal requirement, whereas Xonsh has quite a few dependencies.

addendum: I’d say, if you’re already using Xonsh, and aren’t really looking to share your script with anyone other than Xonsh users or your own systems, you’d probably like to use .xsh scripts. But if you’re looking to share your script, use sh.py.

Yeah, I think if I wasn’t familiar with Python, it’d be nushell all the way.

thanks, good thread.

It’s a superset of python, so valid python should run fine. Imports into your shell are doable, too – for example, I import path.Path in my xonshrc, so it’s always available when I hit the shell. I don’t often have to use Path, because regular shell commands are often more straightforward. But when I do, it’s nice to have it already loaded. Granted, that could get kooky, depending on what you import and execute.

You can associate/shebang Xonsh with .xsh files, or run “xonsh foo.xsh” - and that works like “bash foo.sh” would, except using xonsh syntax, of course.

It’s not Bash compatible - copypasta of scripts may not work out. But it’s a good shell with some typical shell semantics.

there are some great plugins, too - like autovox, which allows you to create python venvs associated with specific subfolders. so, cd myproject does the equivalent of cd myproject; . path/to/venv/bin/activate.

overall, there definitely is some jank, but it’s a great tool and I love it.

I like nushell, but I love xonsh. Xonsh is the bastard love child of Python and Bash.

it can be thought of as:

• try this statement in Python
• if there’s an exception, try it in bash.

Now, that’s not a very accurate description, because the reality is more nuanced, but it allows for things like:

for file in !(find | grep -i '[.]mp3^'):
    file = Path(file.strip())
    if file != Path('.') and file != file.with_suffix('.mp3'):
    mv @(file) @(file.with_suffix('.mp3'))

Now, there are things in there I wouldn’t bother with normally - like, rather than using mv, I’d just use file.rename(), but the snippet shows a couple of the tools for interaction between xonsh and sh.

• !(foo) - if writing python, execute foo, and return lines
• @(foo) - if writing sh, substitute with the value of the foo variable.

But, either a line is treated in a pyhony way, or in a shelly way - and if a line is shelly, you can reference Python variables or expressions via @(), and if it’s Pythony, you can execute shell code with !() or $(), returning the lines or the exact value, respectively.

Granted, I love python and like shell well enough, and chimeras are my jam, so go figure.