canadaduane

This is the case for me as well. I tried NixOS this weekend, and even though it has more adoption than Guix, it still does not have 100% coverage of all software I wanted. That said, the packages I did install were pretty up-to-date. I guess NixOS is as close to "critical mass" as we've got when it comes to this type of OS. But if I were a wizard devops type person with more time, I'd probably enjoy Guix more.

Given encouragement to try tmux, here is what I've come up with as a "one-liner" (script) that does what I was originally looking for:

#!/bin/sh

tmux new-session -d -s split_screen_grep \; \
  send-keys "/bin/sh -c '$1' | tee /tmp/split_screen_grep.txt" C-m \; \
  split-window -h \; \
  select-pane -t 1 \; \
  send-keys "tail -f /tmp/split_screen_grep.txt | grep '$2'" C-m \;

tmux attach-session -t split_screen_grep

I use it as follows, first arg is a command, second arg is a pattern to search for:

$ ./split-grep "cat big_file.txt" "tmux"

Thanks! I'm curious if there is a way to do this as a one-liner?

Elegant and flexible, thank you!

ChatGPT suggests the following:

1. Run tmux
2. rsync -naP --exclude-from=rsync-homedir-local.txt /home/$USER/ $BACKUPDIR/ | tee /tmp/rsync_output.txt
3. Ctrl+B % # splits screen vertically
4. Ctrl+B right-arrow-key # moves to right split
5. tail -f /tmp/rsync_output.txt | grep denied

Not quite a one-liner, but I can see how tmux is a big help here.

Interesting, I'll check it out, thanks!

Keep an eye on Pop COSMIC. It isn't ready yet, but I'd give it 4 months and I think it would be a great match for something like rpi.

Is it possible to get this to work with OBS studio? I see the author mentions OBS as an "Alternative Project" but it seems ideal to have these pieces work together.

This is really cool in concept, but it is SO SLOW. OMG.

I've started playing with Chimera Linux. Super interesting hybrid between BSD-like systems (ports, BSD-derived userland tools) and the Linux kernel, with neat design choices like LLVM compiler instead of gcc and musl C instead of glibc. I think of it as a next-gen Void Linux.

The short answer is "yes, but only as much as it needs to". Flatpak had to make a decision between "do we guarantee the app will work, even with system upgrades" or "do we minimize space" and they chose the former. The minimum necessary dependencies will be installed (and shared) amongst flatpaks.

Have you had the unfortunate experience of a utility or program losing its packaged status? It's happened to me before--for example fslint. I don't think this can happen with flatpak.

It's funny, I do almost the exact opposite--whenever there is a flatpak version, I prefer it over a built-in apt package. The flatpak is almost always more up-to-date and often has the features and bug fixes I need.

Examples:

• Vorta (0.8.12 flatpak; 0.8.3 apt)
• Pinta (2.1.1 flatpak; 1.6 apt)
• Minder (1.15.6 flatpak; 1.13.1 apt)
• Xournal++ (1.2.1 flatpak; 1.1.1 apt)

.

I don't think it's fair to expect the distro maintainers to be up to date with every software out there--the universe of software has grown and grown, and we just can't expect them to wrap/manage/test every new release and version bump.