Skip to main content

What's that one feature you liked so much while distrohopping that you want it by default in all distros?

I have always been discovering new things about Linux distros while distro hopping. And when I get something I really like, I just copy the package name and make sure I install it in every distro I use in the future.

Let me start:
1. Clipboard manager (Gpaste)
2. KDE connect

don't like this

in reply to Jerald

eshep
eshep
•
Having #vim and #tmux in liveOS should be standard practice.
#vim #tmux

Linux reshared this.

in reply to eshep

Jerald
Jerald
• •
I didn't know about tmux. I haven't heard much about it. What's it's purpose and what use would it have for a general user?

Linux reshared this.

in reply to Jerald

eshep
eshep
•
It's a terminal multiplexer. If you've heard of screen, it's very similar. Maybe not so useful for a "general user", but I find it indispensably useful on those occasions where I need a live disc.
in reply to eshep

Jerald
Jerald
• •
@eshep@social.trom.tf @normalmode@mastodon.social Thanks guys, I will be trying to learn Bash soon, I am gonna install tmux. As for vim, obv, I have it installed :')
in reply to Jerald

Normal Mode
Normal Mode
• •

It has 2 basic functions:

1. It allows you to add (effectively) tab pages to your shell, and split each page into multiple windows. Yes your terminal can likely do this, but this is running inside your shell, so it works the same way if you’re logged in locally or running over SSH.

1/2

in reply to Normal Mode

Normal Mode
Normal Mode
• •

2. Your tmux session runs in a server process, so if you close the enclosing terminal or disconnect from your SSH session, everything in your tmux session keeps running and you can reconnect to it later on.

You can also have a bunch of tmux sessions running in a single tmux server, and switch between them with a couple of keystrokes.

Once you start using tmux (or screen) it’s very hard to imagine going back to life without it!

2/2

This entry was edited (1 year ago)

Linux reshared this.

in reply to Normal Mode

eshep
eshep
•
I'm perty sure I'd go mad if I had no way of installin one of em. πŸ˜…

Linux reshared this.

in reply to Jerald

Jason
Jason
• •
tmux and Vim are the 2 things I return to every couple of years. I commit to using them everywhere so everything gets stuck in muscle memory and it all becomes second nature. And then I get sick of it and say screw that (for a year or two).

Linux reshared this.

in reply to Jerald

russjr08
russjr08
• •

I'd probably say the vast amount of packages that can be installed via the AUR, but since the rising popularity of Flatpak, we're getting incredibly close to this.

My next want would be having the ability to make your system declarative (at least, the initial config) in a fashion that NixOS and Guix do.


Nix & NixOS | Reproducible builds and deployments

Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems.
nixos.org

federico3 doesn't like this.

in reply to russjr08

eshep
eshep
•
Things usually have a .deb or .rpm available which almost always unpack and run with no issue regardless of distro.

Linux reshared this.

in reply to eshep

russjr08
russjr08
• •
Oh for sure (and a lot of AUR packages are exactly just that), but nothing beats the simplicity and speed of running a quick sudo pacman -S package_name and then being up and running :)

Linux reshared this.

in reply to russjr08

π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
• •

I have really come to depend on rolling-release systems. I have a few alliances that run Ubuntu, because of a dependency on vendor packages and insufficient interest in fighting with software+hardware issues, and I hate when I have to deal with them. The paupacy of software, the frequent breakage on release upgrades; I don't know how people who prefer these systems justify how bad they are in comparison to Arch (or Nix, or any other rolling release-based distro).

I haven't yet done it, but Arch is so reliable I'm tempted to create a daily -Syu cron job (or, more precisely, a systemd timer job, because I'm only yet running Artix on a couple of systems). The only thing that gives me pause are the kernel updates, which are frequency and necessitate system reboots.

Those kernel updates really make me wish Linus had focused on a microkernel architecture.

in reply to Jerald

Ephera
Ephera
• •
BTRFS snapshots like openSUSE and now also Fedora has it. I don't want to use a distro without them anymore. Unfortunately, configuring them yourself is a bit more involved than just installing a package...

federico3 doesn't like this.

in reply to Ephera

Secunergy 🐧
Secunergy 🐧
• •
Do you a good source for a tutorial how to configure snapshots? (on OpenSUSE)
in reply to Secunergy 🐧

Ephera
Ephera
• •

Oh, on openSUSE, you don't need to configure anything. Just install with the default partition setup and it will automatically take snapshots of your operating system (/home/ is excluded) whenever there are changes.

It uses incremental snapshots, so they won't take up infinite space...

in reply to Ephera

Secunergy 🐧
Secunergy 🐧
• •
Thanks, I noticed that my system does take snapshots automatically (I am new to openSUSE) but thought maybe there is still something to optimize πŸ‘πŸΌ
in reply to Secunergy 🐧

jumanjimanju
jumanjimanju
• •
Look on the the arch wiki, you can tweak snapshot/cleanup frequencies, which is nice
in reply to Jerald

lhotze
lhotze
• •

don't like this

in reply to lhotze

Jerald
Jerald
• •

undefined> Your configuration is written in code, it is therefore persistent. Do you know that annoying feeling of β€œoh shit, how did I configure x program that I want to install on this other machine”? Never again.

This is sick! thank you!

federico3 doesn't like this.

in reply to lhotze

Zach777
Zach777
• •
This singlehandedly makes me want to switch off Ubuntu.

federico3 doesn't like this.

in reply to lhotze

dotCaffe
dotCaffe
• •

Nix has been on my mind for a while, but I've been hesitant to go all in. Unfortunately, messing around a bit with VMs I still don't feel like I have a good handle on how it all works.

One question I'd ask you is how much upfront work it is to get, say, a stable setup for a laptop where all of the little things are working (opening/closing the lid, connecting to external screen, switching audio outputs, media keys. Laptop stuff!)

As context, a long time ago I ran Gentoo and later Arch, so I'm not technically clueless, but eventually decided to switch to easier distros that came with a reasonable system defaults that works out of the box. I'm super interested in NixOS for all the reasons you mentioned, but worried about how time I'll end up spending just getting that config file to where I want it!

in reply to dotCaffe

lhotze
lhotze
• •
The stable setup on the laptop you can get by using a DE like Gnome that comes with batteries included. If you go for more minimal setups like a window manager it will take quite a bit longer.
NixOS as a distribution is pretty easy to get running, if you are familiar with the desktop environment that you install in your system getting it setup is much much simpler than doing so in other distros like Arch, since it usually consists of adding a line like desktopEnvironment.gnome.enable = true to your config and the system takes care of almost everything. I even think that gnome gets installed by default on the first run.
in reply to lhotze

dotCaffe
dotCaffe
• •

Thanks! I ended up messing with Nixos a bunch in the past few weeks. My impression is generally positive, though while many of the things it does are very elegant (like the gnome example you mentioned), a lot of it also seems a bit hacky. Ultimately, figuring out how to declaratively configure specific things seems to take so much more time than my current approach of a written document detailing the steps of setting up my system.

I'm going to keep tinkering in a VM though, and maybe I'll have a breakthrough. Keeping configs working across two computers especially is tempting (read: an excuse to get a second computer).

One last question - one of the things I worked on was Firefox with home manager. How did you get it set up so bookmarks were included in the config?

in reply to dotCaffe

lhotze
lhotze
• •
When you set a FF profile there is a key called bookmarks. You can set them there:
programs.firefox = {
  enable = true;
  extensions = [
    pkgs.nur.repos.rycee.firefox-addons.vimium
    ...
  ];
  profiles = {
    my-profile = {
      name = "yourname";
      settings = {};
      bookmarks = [
         {
           name = "This is a folder";
           toolbar = true;
           bookmarks = [
             {
               name = "You can nest folders";
               bookmarks = [
                 {
                   name = "This is a lemmy bookmark";
                   keyword = "lemmy";
                   url = "https://lemmy.ml/";
                 }
            ...
        ];
      ];
    };
  };
};

You can always look at the home manager reference, I usually look here.
in reply to lhotze

Tiuku
Tiuku
• •
It's quite reasonable to switch to Guix, as it too is "a functional distro".
in reply to Tiuku

Laser
Laser
• •

I recently tried NixOS and was considering Guix as well, however what made me decide on NixOS was the fact that it doesn't restrict you to free packages by the distro default choice.

Does Guix have an equivalent to flakes or does it even need one? I never looked closer into the design.

in reply to Jerald

π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
• •

For KDE Connect, there's a headless program called mconnect with no Qt (or KDE) dependencies. I use it with the KDE Connect Android app, and it works well. All of the commands on the Linux end are CLI, and many of the functions are supported.

Supported functions

Edit: link to source

GitHub - bboozzoo/mconnect: mconnect - KDE Connect protocol implementation in Vala/C

mconnect - KDE Connect protocol implementation in Vala/C - GitHub - bboozzoo/mconnect: mconnect - KDE Connect protocol implementation in Vala/C
GitHub
This entry was edited (1 year ago)

federico3 doesn't like this.

in reply to π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–

Jerald
Jerald
• •

really sorry, I don't understand the point of this app. I mean, KDE connect works well, so why change?

Are you talking about a situation where it's not possible to install those Qt or KDE dependencies (then it might be useful to me)

Thank you for your output either way!

in reply to Jerald

π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
π•½π–šπ–†π–Žπ–‰π–π–—π–Žπ–Œπ–
• •
Yes, that's exactly the situation I mean. People who'd rather run Gnome, or those of us who'd rather run a lightweight windowing system, can get all of tye benefits of KDE Connect without running all of the KDE cruft.
in reply to Jerald

tοΏ½m
tοΏ½m
• •
  • Flatpak
  • podman
  • ansible

don't like this

in reply to Jerald

Pantherina
Pantherina
• •

Kde has Klipper and everything else? Maybe I miss stability, because currently its a buggy mess sometimes.

MXLinux's Conky manager... havent got it to run normally again.

in reply to Jerald

Vorthas
Vorthas
• •
I would say AUR access with either Xfce or MATE as a default and first-class option for DEs. It's hard to go to a distro without AUR access for a lot of what I use, doable, but hard.
⇧