this post was submitted on 30 Aug 2026
59 points (91.5% liked)

Technology

87649 readers
3006 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] PotatoesFall@discuss.tchncs.de 2 points 7 hours ago (1 children)

I do release a Flatpak but I'm actually working against it. It's designed for self-contained sandboxed desktop GUI applications and I'm releasing a terminal-based TUI that allows you to rampage around your machine and network. I'm passing some horrible "bad practice" flags to get it to work. Flatpak sandboxing is not a good fit.

Okay sure but is this really such an issue? Installing the app normally is equivalent to passing those flags anyway right?

[โ€“] cecilkorik@lemmy.ca 3 points 6 hours ago

It is equivalent until Flatpak adds a new (probably completely justified) limitation to its sandbox that breaks your (needs unrestricted system-wide permissions) application, sure. Nevermind if you decide to add more features that go beyond what the sandbox allows, and then you need to figure out why they're broken in your flatpak and what new flags you need to unbreak them. The problem is you're constantly swimming upstream against a very strong current. It's not a very sustainable mode of development. Like OP said, flatpak is designed for sandboxed desktop GUIs. It may be convenient at first to shoehorn your TUI application into it, but you're working against its design and intent, and that is a genuine problem, for many reasons.

npm -g is another TUI install method I loathe. pipx/uv shares most of the same issues. Like the author, I've gone through almost all of the same options they have, and come to basically the same conclusions. There really is no good option for packaging and managing userspace TUI utilities. And it's brutal. I hate that so many terminal utilities have standardized to use completely unrestricted, opaque and dangerous curl/sh copy-pastes, leaving anyone who's not both fluent in shell script and willing to invest the time to inspect what the scripts are doing out in the cold, bravely running commands that are potentially malicious with no safety net. I understand it, it's viable, it works, I do it myself for my own projects, but we have to acknowledge that it's a symptom of the lack of any better solution for TUI packaging, and it's okay to admit that it sucks, and we could do something so much better.