thingsiplay

@thingsiplay@beehaw.org

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Run Flatpak apps by search filter or through fuzzy finder menu (gist.github.com)

I wrote a simple script in order to help someone in a recent reply from me, to make running Flatpak applications from terminal easier. After that I worked a little bit on it further and now ended up with 2 completely different approaches....

thingsiplay, (edited )

I thought about additional echo for confirmation too! I will add it too (give me 2 minutes), but it will output to stderr, so it’s not part of regular output.

Edit: So I added


<span style="color:#62a35c;">echo </span><span style="color:#183691;">"flatpak run" "${</span><span style="color:#323232;">app</span><span style="color:#183691;">}" "${</span><span style="color:#323232;">@</span><span style="color:#183691;">}" </span><span style="font-weight:bold;color:#a71d5d;">>&</span><span style="color:#323232;">amp</span><span style="font-weight:bold;color:#a71d5d;">;</span><span style="color:#323232;">2
</span>

, which as said will output to stderr instead. And I also decided to add flatpak run and the arguments too, but that’s just an “aesthetic” choice.

thingsiplay,

The only reason why EA Play is interesting to me is, because its offered on Steam and Game Pass is not. EA Play is even part of Game Pass, if I am not mistaken. But I don’t now the details, so anyone who wants to clue me in, is welcome.

thingsiplay,

But it got a 10/10 on the scoring system by Github.

The issue isn’t actually too much related to the Rust core language itself, but rather how they handle scripts on Windows platform. So if you don’t have a Windows program that runs Batch scripts, then it doesn’t matter to you. I wonder how common it is to run Batch scripts in Rust?

thingsiplay,
thingsiplay,

Why not? I mean they are right. Adopting memory safe languages is a good step forward, because it would eliminate bunch of mistakes before they happen. And the White House does not recommend Rust only, but a memory-safe language, something like Rust or something different. I wish my government would do the same.

thingsiplay,

You could use a clipboard tool to copy something to the clipboard and then paste it in one command. There is such a common tool for Wayland: github.com/YaLTeR/wl-clipboard-rs . It’s at least in the official repository in Archlinux. The command could be something like this:

wl-copy “|>” ; wl-paste

Off course you would lose the current clipboard content this way. But I guess a script could easily be written to backup and restore clipboard, but not entirely sure how safe it is.

thingsiplay, (edited )

This is extremely simple to fix with scripts that can be automatically created on install time. Here is a quick script I just wrote. It will search for first matching app and run it. Just save the script as flatrun, give it executable bit and put it into $PATH. Run it as like this: flatrun freetube


<span style="color:#323232;">#!/usr/bin/env bash
</span><span style="color:#323232;">
</span><span style="color:#323232;"># flatrun e
</span><span style="color:#323232;"># flatrun freetube
</span><span style="color:#323232;">
</span><span style="color:#323232;">if [ "${#}" -eq 0 ]; then
</span><span style="color:#323232;">	flatpak list --app --columns=name,application
</span><span style="color:#323232;">else
</span><span style="color:#323232;">	app="$(
</span><span style="color:#323232;">		flatpak list --app --columns=name,application |
</span><span style="color:#323232;">			grep -i -F "${@}" |
</span><span style="color:#323232;">			awk -F't' '{print $2}'
</span><span style="color:#323232;">	)"
</span><span style="color:#323232;">
</span><span style="color:#323232;">	if [ -z "${app}" ]; then
</span><span style="color:#323232;">		flatpak list --app --columns=name,application
</span><span style="color:#323232;">	elif [[ "$(echo "${app}" | wc -l)" -gt 1 ]]; then
</span><span style="color:#323232;">		echo "${app}"
</span><span style="color:#323232;">	else
</span><span style="color:#323232;">		flatpak run "${app}"
</span><span style="color:#323232;">	fi
</span><span style="color:#323232;">fi
</span>

Edit: Just updated the script to output the list of matching apps, if it matches more than one.

thingsiplay,

I personally don’t think that creating a script is a bad solution. The entire Linux eco system is based around composable components (especially when we talk about terminal commands). Most of the Flatpak applications are available through GUI menus (.desktop files) and that’s the focus of Flatpak. And I think it’s a design decision not to expose every application as a separate program in the $PATH by default. This way there is less of a chance to collide with anything random on the system, if they have the same name.

Having said this, I still agree it would be beneficial for most users if there was a way to automatically create scripts in a special bin folder, that is available in the $PATH. The problem is, what application name should it have? What about different versions of the same program? The entire Flatpak concept was not designed for this, so creating a script for your personal use is not a bad solution.

thingsiplay,

Please read my reply before you repeat. How should the different versions of an application be handled? What if the shortname is already taken? There will be collisions, which the longname tries to solve. Flatpak is not a repository where all names can be checked against, this is the job of a repository like Flathub. What about different versions of an application?

This is not a simple case of forcing to specify shortnames.

thingsiplay,

Wow I was not aware of that folder! Thanks.

thingsiplay,

I think like with any other standalone emulator compared to RetroArch, the main benefit would be the user interface and the entire configuration setup. Ares is a more traditional application with less functionality and narrow focus. That makes it simpler and more native to use on your operating system. Also you don’t need to learn and understand how RetroArch is setup, with all its configuration, because how many features it supports and how generic it is.

Note: I’m a huge RetroArch fan, its not dunking on it or anything like that.

Also some people don’t like that RetroArch itself does not have emulator cores, but rather use other cores (which is the entire point of it and why I’m loving it). Ares is completely its own thing (but a fork of higan, which was based on Bsnes, RIP Near). And because its much simpler, people might be understanding its source code better.

Also I don’t use and don’t know what Ares actually supports and can do. In example I have a separate and standalone Mesen, just because of its excellent debugging features (when I experimented with romhacking).

Is xz 5.6.1-3+ still dangerous?

When the xz backdoor was discovered, I quickly uninstalled my Arch based setup with an infected version of the software and switched to a distro that shipped an older version (5.5 or 5.4 or something). I found an article which said that in 5.6.1-3 the backdoor was “fixed” by just not letting the malware part communicating...

thingsiplay,

I see what you did there.

thingsiplay,

Oh, I thought the “You can use Arch btw again.” is a play on the “I use Arch, BTW.”-meme. :D It’s even better, because this was not intentional I guess.

thingsiplay,

I see. But yours was a little bit more sneaky. And I loved it.

thingsiplay,

I think this is useful if you have multiple GPUs (like iGPU from the CPU and a dedicated installed graphics card, possibly even another one). Then I imagine you access the dedicated “full” graphics card for gaming in the guest VM and your host OS can use the integrated graphics.

Even if you only had one GPU, i’m not sure why this would mess anything on other applications. It’s the operating systems and graphics drivers job to not mess things up, by only accessing stuff it is supposed to. I mean you can even run multiple games at the same time on your host machine. So from that perspective, the VM becomes just another “game”.

Disclaimer: I’m not an expert, just curious as you. And this is what I think. Not even sure if it explains anything at all.

How do we know if there aren't a bunch of more undetected backdoors?

I have been thinking about self-hosting my personal photos on my linux server. After the recent backdoor was detected I’m more hesitant to do so especially because i’m no security expert and don’t have the time and knowledge to audit my server. All I’ve done so far is disabling password logins and changing the ssh port....

thingsiplay,

We can’t know. If we would know, those weren’t undetected backdoors at all. It’s not possible to know something you don’t know. So the question in itself is a paradox. :D The question is not if there are backdoors, but if the most critical software is infected? At least what I ask myself.

Do you backups man, do not install too many stuff, do not trust everyone, use multiple mail accounts and passwords and 2 factor authentication. We can only try to minimize the effects of when something horrible happens. Maybe support the projects you like, so that more people can help and have more eyes on it. Governments and corporations with money could do that as well, if they care.

thingsiplay,

I just tested this and the reported sizes with eza -l --total-size are wrong for me. I compare it to du --human-readable --apparent-size --all --max-depth 1 and with opening properties in my Dolphin filemanager. Some are way off. In example du and Dolphin report for a certain projects folder of mine “149M”, while eza reports “184M”.

thingsiplay,

No, the difference is way too high to explain it like this, there is no way that 1024 vs 1000 base could explain an increase of approx. “35M” for a “149M” directory. Other folders are much closer like “20K” and “20K” or =or “44M” vs “45M”. Also as said Dolphin filemanager reports the same output as du. I even tested du with –si option, which power of 1000 instead 1024 (I’m pretty sure eza does it correctly with 1024, so this is not necessary option to compare anyway).

thingsiplay,

He is wrong, as I explained it multiple times that this is not the issue here. Install eza and compare to du and possibly some other application that reports the directory size. The difference in filesize cannot be explained by 1000 vs 1024 base. Do the math if you don’t believe me.

eza is reporting false directory size for me, unless there is an explanation.


<span style="color:#323232;">[Desktop]$ du --human-readable --apparent-size --all --max-depth 1 ./trampoline
</span><span style="color:#323232;">518     ./trampoline/src
</span><span style="color:#323232;">148M    ./trampoline/target
</span><span style="color:#323232;">1,1M    ./trampoline/doc
</span><span style="color:#323232;">8       ./trampoline/.gitignore
</span><span style="color:#323232;">26K     ./trampoline/.git
</span><span style="color:#323232;">330     ./trampoline/Cargo.toml
</span><span style="color:#323232;">2,1K    ./trampoline/Cargo.lock
</span><span style="color:#323232;">149M    ./trampoline
</span><span style="color:#323232;">[Desktop]$ du --human-readable --apparent-size --all --max-depth 1 --si ./trampoline
</span><span style="color:#323232;">518     ./trampoline/src
</span><span style="color:#323232;">155M    ./trampoline/target
</span><span style="color:#323232;">1,2M    ./trampoline/doc
</span><span style="color:#323232;">8       ./trampoline/.gitignore
</span><span style="color:#323232;">27k     ./trampoline/.git
</span><span style="color:#323232;">330     ./trampoline/Cargo.toml
</span><span style="color:#323232;">2,2k    ./trampoline/Cargo.lock
</span><span style="color:#323232;">157M    ./trampoline
</span><span style="color:#323232;">[Desktop]$ eza -l --total-size --no-permissions --no-user ./trampoline
</span><span style="color:#323232;">2,1k 25 Feb 21:36 Cargo.lock
</span><span style="color:#323232;">330  4 Mär 09:21 Cargo.toml
</span><span style="color:#323232;">1,1M  5 Apr 12:34 doc
</span><span style="color:#323232;">518  5 Apr 12:49 src
</span><span style="color:#323232;">183M  4 Apr 20:26 target
</span>

And for reference Dolphin the filemanager of KDE Plasma reports 149,1 MiB (156.366.443) , which aligns with du without using –si option. Even the one folder “target” is at 183M with eza (which is the biggest folder in that directory anyway).

thingsiplay,

With –binary option I get size of 174Mi in eza. Experimenting with some other options didn’t help. If something is ignored (maybe gitignore), then it would be that du AND Dolphin filemanager would ignore those files, and eza would not. Which its hard to believe for me. I also deleted the .gitignore and .git files/folder to see if it makes any difference and no, it did not.

The only thing I can think of is maybe something going on with link files, but no idea how or what to test for here.

thingsiplay,

About the gitignore stuff of Rust tools: Its the opposite for my results, in that eza has bigger size. And the fact that the independent program Dolphin filemanager aligns with the output of the standard du tool (for which I don’t have a config file I think) speaks for being the more correct output.

Ok so I found it: Hardlinks


<span style="color:#323232;">$ ls -l
</span><span style="color:#323232;">total 9404
</span><span style="color:#323232;">-rwxr-xr-x 2 tuncay tuncay 4810688  5. Apr 10:47 build-script-main
</span><span style="color:#323232;">-rwxr-xr-x 2 tuncay tuncay 4810688  5. Apr 10:47 build_script_main-947fc87152b779c9
</span><span style="color:#323232;">-rw-r--r-- 1 tuncay tuncay    2298  5. Apr 10:47 build_script_main-947fc87152b779c9.d
</span><span style="color:#323232;">
</span><span style="color:#323232;">$ md5sum *
</span><span style="color:#323232;">6ce0dea7ef5570667460c6ecb47fb598  build-script-main
</span><span style="color:#323232;">6ce0dea7ef5570667460c6ecb47fb598  build_script_main-947fc87152b779c9
</span><span style="color:#323232;">68e78f30049466b4ca8fe1f4431dbe64  build_script_main-947fc87152b779c9.d
</span>

I went down into the directories and compared some outputs until I could circle it down (is it called like that?). Look at the number 2, which means those files are hardlink. Their md5 checksum are identical. So its what I was thinking all along, some kind of linking weirdness (which in itself is not weird at all). So eza is not aware of hardlinks and count them as individual files, which is simply wrong, from perspective of how much space those files occupy. The file exists once on the disk and requires only one time space.

EDIT: BTW sorry that my replies turned your news post into a troubleshooting post. :-(

thingsiplay,

BTW I actually did a bug report. :-) -> github.com/eza-community/eza/issues/923

So nothing wasted. Without your post I would not be curious to test this and who knows, maybe it gets fixed or an option to handle it.

thingsiplay,

I used lsd before switching to exa. BTW I was the one who suggested to integrated hyperlink option to lsd. :-) Not saying it wouldn’t be added otherwise, but at least it sped up the process back then.^^

On the topic of filesystem boundaries, this is something I always have in mind. Hardlinks in example cannot be on two different drives, by its nature. It’s an option I use with my own du script often: -x . It helps to keep things in check and simplifies some things, as I have a complex of multiple drives that are mounted into my home from various places, plus the symbolic links from Steam and so on. Avoiding other filesystems is part of my “workflow”, if you so will and would like to see such an option as well.

I just noticed exa has an option -H or –links to list each file’s number of hard links. So at least it is aware of hardlinks and could calculate the total size correctly.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • mdbf
  • ngwrru68w68
  • modclub
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • DreamBathrooms
  • megavids
  • GTA5RPClips
  • ethstaker
  • normalnudes
  • tester
  • osvaldo12
  • everett
  • cubers
  • tacticalgear
  • anitta
  • provamag3
  • Leos
  • cisconetworking
  • lostlight
  • All magazines