Hello everyone! I know that Linux GUI advanced in last few years but we still lack some good system configuration tools for advanced users or sysadmins. What utilities you miss on Linux? And is there any normal third party alternatives?

  • Eugenia@lemmy.mlEnglish
    73·
    6 days ago

    I personally would like a systemd gui. There have been several attempts in the past, but none is maintained.

    • Ephera@lemmy.mlEnglish
      71·
      6 days ago

      On openSUSE, I’ve apparently got at least this thing for looking at SystemD services:

      Allows viewing the services for the different boot targets, as well as the service files. You can also start/stop services or change their start mode (on boot vs manual).

      Well, and there’s a JournalD viewer with filtering:

      Not the most developed GUIs, but…

    • ubergeek@lemmy.todayEnglish
      31·
      6 days ago

      Its far too convoluted. A systemd gui for… DNS? Boot services? User Services? tmp file management? Everything?

      • Atemu@lemmy.ml
        11·
        6 days ago

        All of those are entirely separate components; I have no idea what you’re attempting to imply here.

        • ubergeek@lemmy.todayEnglish
          2·
          6 days ago

          Those are all things systemd manages… as well as logs, udev, etc etc.

          What kind of gui too could you even imagine would sanely present all of that?

          • Atemu@lemmy.ml
            3·
            6 days ago

            As mentioned, those are entirely separate and even independent components.

            Systemd (as in: pid1) only “manages” them insofar as that it controls their running processes just like any other service on your system.

            systemd-boot doesn’t interact with systemd at all; it’s not even a Linux program.

            The reason these components have “systemd” in their name is that these components are maintained by the same people as part of the greater systemd project. They have no further relation to systemd pid1 (the service manager).

            Whoever told you otherwise milead you and likely had an agenda or was transitively mislead by someone who does. Please don’t spread disinformation further.

            • ubergeek@lemmy.todayEnglish
              11·
              6 days ago

              Without going into the weeds and all, given they all are in the same project, regardless…

              You said “a gui for managing systemd”, so which part? Boot, udev, and journal? All three are required and not optional for systemd the OS infrastructure layer suite (or whatever it’s called these days), so minimally, assume that?

              If so, what kind of sane gui could manage those three very disparate things?

              • Atemu@lemmy.ml
                11·
                5 days ago

                If you talk about “a GUI for systemd”, you obviously mean its most central and defining component which is the service manager. I’m going to assume you’re arguing in bad faith from here on out because I consider that to be glaringly obvious.

                systemd-boot still has no connection to systemd the service manager. It doesn’t even run at the same time. Anything concerning it is part of the static system configuration, not runtime state.
                udevd doesn’t interact with it in any significant user-relevant way either and it too is mostly static system configuration state.

                journald would be an obvious thing that you would want integrated into a systemd GUI but even that could theoretically be optional. Though it’d still be useful without, it would diminish the usefulness of the systemd GUI significantly IMHO.
                It’s also not disparate at all as it provides information on the same set of services that systemd manages and i.e. systemctl has journald integration too. You use the exact same identifiers.

      • Eugenia@lemmy.mlEnglish
        32·
        6 days ago

        That’s the point. That systemd is convoluted, so a gui could help. And yes, for everything. :)

        • ubergeek@lemmy.todayEnglish
          4·
          6 days ago

          My point is there is no way to sanely create a GUI for something has it’s tendrils in… Everything. In fact, there’s no sane way to do any sort of UI for such a beast.

        • catloaf@lemm.eeEnglish
          31·
          6 days ago

          Maybe the system should be made less convoluted.

          I mean, do we really need a half dozen network management services, all broken in their own way and none that do everything you need?

      • oldfart@lemm.ee
        2·
        5 days ago

        Everything! And a virt-manager like tool for nspawn! And for the faux-cron jobs! Make it as byzantine as systemd itself

    • notabot@lemm.ee
      62·
      6 days ago

      SystemD is far too much of a poorly thought through mess to have anything like a sane GUI configuration, it doesn’t even have a sane textfile based configuration. We’re going to have to wait fir SystemD to crumble under it’s own weight and be replaced with multiple, simple, cleanly designed components before we have any hope of a sane config again. Sort of like we used to have before a certain someone/some company (depending on how conspiratorial you’re feeling) decided to come along and muck it all up.

      /rant

      Thank you for coming to my Ted Talk Rant. You may gather I dislike SystemD quite a lot.

      • Atemu@lemmy.ml
        44·
        6 days ago

        For anyone else reading along: This person is talking out of their ass.

        • esa@discuss.tchncs.de
          2·
          5 days ago

          I also find that calling systemd “SystemD” is a tell that someone is unfamiliar with or has a conspiratorial relationship to it. It’s named “systemd”, all lowercase (but I’m likely to capitalize it on sentence starts like a normal word). Using an ungrammatical uppercase D at the end of the word, that isn’t even something the creators claim is correct, is … a choice.

          (And it’s a choice that reminds me of e.g. how rabid anti-cyclists in Norwegian can’t even spell “cyclist” correctly, but instead consistently use “bicycleist”.)

          • notabot@lemm.ee
            2·
            4 days ago

            Ok, fair point on the capital D, I must have read it like that years ago and it stuck. I shall have to make an effort to unlearn it.

            As to the rest, systemd has been a constant thorn in my side ever since L. Pottering published “Rethinking PID 1” back in 2010 or so. I found, and still find, that most of the assertions and actions in that document either don’t really hold, or just aren’t really relevant. Basically it’s trying to solve a problem that really wasn’t an issue in the real world, and does so in such a massively overbearing way that everything actually becomes more laborious than it otherwise would be. From my perspective it’s an unnecessarily complex and poorly architected attempt to answer a need that was better served in different ways. That it’s become a near mono-culture is deeply concerning.

            I’ve also run into all sorts of awkward edge cases and misfeatures over the years, from the automounter that occasionally didn’t to race conditions that only manifest at the worst moments, none of which would have occured had the basic tenet of “do one thing and do it well” been followed. The extreme verbosity of the configuration, and unnecessarily large number of places it can be spread just serve to make it even more unpleasant to deal with compared to the simplicity of init scripts, crontabs and the like.

            The sad thing is, there’s undoubtedly some good ideas buried in it, but they could all have been implemented much more lightly and in a way that worked with the rest of the ecosystem rather than fighting it. Things like starting daemons in what is essentially a repeatable sandbox, or being able to isolate logging per service. They could, and had both been implemented already, but systemd has a real “not invented here” problem, so everything was built again, with all the attendant bugs, and design issues that inevitably brings.

            Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn’t grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.

            • esa@discuss.tchncs.de
              1·
              3 days ago

              Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn’t grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.

              I also have a sysadmin/devops/sre type career, and my impression is rather the opposite: With systemd Linux became a lot cleaner and predictable, compared to the mess of shell scripts we had before. There’s never been anything clean or well-architected about shell scripts, they’ve always been a messy collection of not-quite-the-same languages that have all safeguards turned off by default, and it’s up to the programmer to turn them on and hope they actually work. Good for one-shots and exploration in the terminal, though.

              I also don’t miss logrotate or finding out that some app places its logs somewhere mystical. Being able to read app logs just by knowing the service name is wonderful, as are the timestamp and boot arguments.

              systemd didn’t appear as just one guy’s brain child, nor could it rise to the dominance it has if the way it works was as controversial or bad as it is in your opinion.

              I haven’t been on-call for the past few years, but my impression is that there have been fewer and fewer on-call events over my career. That’s also largely on app developers and a shift to Kubernetes, but it’s a generally pleasant change. There’s nothing I hate more than being woken up.

              • notabot@lemm.ee
                1·
                3 days ago

                I agree with the sentiment regarding being woken up, but I used to look forward to being on call. I could go to bed happily, knowing I was earning a significant premium and I’d still get a good night’s sleep because the systems just didn’t go down. I had the advantage that most of the customers I supported had similar requirements, so I had their systems locked up pretty well. Minor problems (disk space. Why is it always disk space?) would self heal, catastrophic failures (hardware failures or the engineer who supposed to replace a component unplugging the wrong server) would fail over to the rest of the cluster. I never had much trouble with logging either, it was typically one of the first things set up, and I had most of the setup automated to avoid missing anything. I suppose the thing was I was supporting systems I’d built, and I’d built them to ensure I didn’t have to be woken up.

                I do a lot more troubleshooting and rescue type work nowadays, and the number of times I run into systemd components just not doing what they should is frustrating to say the least. Being able to pull the logs by knowing the service name would be nice, but a) you could already do that because you set up different services to log to different places and b) you don’t always know the service name in question. Being able to just grep the log directory is a lifesaver. You can still do that, but only because distros set systemd up to log to file as well as it’s binary format. I loathe the way systemd ends up spreading it’s unit files over about a dozen different directories, with overrides increasing that even further. I just want to know what services I’ve got and what will start up, in exactly what order, on the next reboot, dammit! The last one is particularly tricky as, due to services being started in parallel, you can’t predict exactly what order things will actually start between targets. That shouldn’t matter, units should have all their dependencies properly listed, but it’s no fun tracking down a race condition that only happens once every x reboots when a particular network service takes a few hundred milliseconds longer to come up. Give me sequential boot any day. It might take a few tens of seconds longer, but it happens the same way each time, and I only need to look in one place to know what that is.

                As to systemd’s dominance, once Redhat, where Mr Pottering worked, chose it, it became hard for other distros not to. Derivative distros obviously went with it, and if you look back through the various email discussions, it was far from a unanimous choice for distros like Debian to choose it. They did so eventually mostly, as far as I can see, because it would theoretically make packaging easier. Fortunately they still support sysvinit, so all is not lost for those of us who want a mainstream distro without systemd bloat.

                Shifting stuff to kube is definitely goot for making things more robust, so long as you’ve got the underlying clustering working, and I quite like working with it too. Once you realise it’s basically just a database and message queue with a bunch of controllers for managing storage, networking, containers and the like, and the ability to extend that, you can do all sorts of fun things with it.

                Anyway, I’ve gone on for long enough. If you’re a sysadmin and the number of trouble calls is going down, then you probably don’t hear this often enough: well done, you’re doing a great job.

    • dasenboy@lemm.ee
      5·
      5 days ago

      You should try gufw. Great for simple setups! For more complicated ones you could use opensnitch.

      • JustVik@lemmy.mlEnglish
        1·
        4 days ago

        Thanks. I will try all the suggested options and see which one is more convenient. :)

    • Phoenixz@lemmy.ca
      2·
      5 days ago

      I use csf which isn’t GUI, text only, but the configuration is so straightforward and simple that it’s been my default for years now on server and desktop

      • JustVik@lemmy.mlEnglish
        1·
        4 days ago

        Thanks. I will try all the suggested options and see which one is more convenient. :)

      • JustVik@lemmy.mlEnglish
        1·
        4 days ago

        Thanks. I will try all the suggested options and see which one is more convenient. :)

  • Sem@lemmy.mlEnglish
    31·
    6 days ago

    I’m missing a lightweight (not like Thunderbird) contacts app, that can work with CardDAV and allow me to see, search and edit my contacts.

    • oldfart@lemm.ee
      1·
      5 days ago

      vCardStudio is pretty nice GUI wise but the backend could be more robust, it doesn’t read all my files.

      • Sem@lemmy.mlEnglish
        32·
        6 days ago

        For me gnome apps are not “lightweight” and work fine only all together (Evolution + gnome-contacts + other gnome tools)

        • wildbus8979@sh.itjust.works
          6·
          6 days ago

          You don’t need evolution for gnome-contacts and I’m not sure how much more lightweight a contact app can get. It literally does nothing but list and edit contacts, and works with dav via gnome-accounts.

  • pr06lefs@lemmy.ml
    121·
    6 days ago

    One thing I kind of miss is autohotkeys on windows. It was relatively easy to do things like set keyboard keys to act as mouse keys. I did that once when I was getting over tendonitis.

    These days I have a keyboard with mouse keys on it and a trackball also with mouse keys. I can use the middle button on the trackball and scroll with it, but I can’t use the middle button on the keyboard and scroll with the trackball, which would be more ergonomic for me. Haven’t figured that one out yet.

    That said, I mostly don’t miss GUI stuff. I use a tiling window manager and command line utilities to do most things on my system. Its kind of primitive I guess, but the benefit is it works exactly the same on remote systems, headless servers, etc.

  • D_Air1@lemmy.ml
    6·
    6 days ago

    I’ve recently gotten into using cockpit. I just wish it was as expansive as openSUSE’s yast.

  • oshu@lemmy.world
    74·
    6 days ago

    I’ve been using linux for over 25 years and I don’t understand this post. One of the strengths of linux is that you don’t need a gui to do sysadmin.

  • flashgnash@lemm.ee
    394·
    6 days ago

    I generally don’t miss anything graphical, once I learn how to do something from the cli I rarely feel the need to do it graphically anymore as it’s usually a lot slower

    The obvious one would be Photoshop and paint.net of course but krita does the trick

    • user_naa@lemmy.worldOPEnglish
      107·
      6 days ago

      I maybe need to correct my post. I am talking about system utilities like Device Manager or something else.

      • atzanteol@sh.itjust.worksEnglish
        155·
        6 days ago

        Why would I want gui for those things? CLI is often a better interface. Being able to grep lsusb rather than scanning a gui for an entry is much better. It’s easier to pipe to an email as well. Screenshots don’t allow copy/paste…

        • Tlaloc_Temporal@lemmy.ca
          21·
          5 days ago

          As a newcomer to CLIs, GUI are great because you don’t need to know what you’re looking for. I can just open the devices window, and they’re all there, with most of the extra hardware stuff that’s not actually a real device already cleaned out.

          To do the same with a CLI would take me 10 minutes of looking up what the hardware commands are, 5 minutes figuring out flags, and 30 minutes researching entries to see if they’re important. Even just a collapsible list would make that last step so much easier. And no, I can’t grep for what I need, because I don’t know what I need, I just know something in there is important with a vague idea of what it might look like.

          Once I figure that all out for one thing, the best I can do is write that to a notes file so I don’t need to search so far next time, but there’s a good chance that I’ll need a different combination of commands next time anyway.

          Not hating on CLIs, just wishing I could figure out how to use them faster.

          • Tekhne@sh.itjust.works
            3·
            4 days ago

            Another really helpful tool is to use the fish shell instead of bash. It has tons of useful features, but my favorite is by far the autocomplete. It parses man pages to provide suggestions for flags, subcommands, even passed arguments, and each item in the results list has a description, and it’s all searchable by hitting shift+tab.

            fish autocomplete subcommands

            fish autocomplete git

            That’s what leveled up my cli game from 0-100. It’s a massive difference in usability and discoverability. And unlike things like nushell, it’s close enough to bash that you won’t feel confused if you have to use bash instead.

          • 9488fcea02a9@sh.itjust.works
            5·
            5 days ago

            apropos - command to list relevant commands tldr [command] - shows the most commonly used flags/options for that program

            apropos comes installed by default (on debian at least), tldr needs to be installed with your package manager

            As someone who cannot even remember tar flags (inser xkcd here), tldr is very helpful

            Your 45 mins becomes 5 mins now. Hope that helps

          • esa@discuss.tchncs.de
            3·
            5 days ago

            The name is constructed from two parts:

            1. ls: list
            2. usb: usb

            It lists usb devices that your machine (/kernel) knows has been connected; they may not necessarily be usable.

            E.g. I have some sound output device connected via USB to one machine. On most of my machines I’ve switched from pulseaudio to pipewire¹, and I figured I’d bring that machine closer to the others so there’s less variance. Unfortunately the sound output device didn’t want to work with pipewire. The problem manifested as no sound and pipewire not listing the device. lsusb helped me know that the machine at the very least recognized the device, but wasn’t currently able to use it. (It did actually also show up as an error in dmesg -H, but reinstating pulseaudio let the device work again as normally. So now I just have to live with a situation where some machines use pipewire because bluetooth and others use pulseaudio because … usb?¹)

            ¹ There’s a memory of ALSA vs OSS I didn’t want to be reminded of

              • esa@discuss.tchncs.de
                1·
                3 days ago

                I think I wouldn’t find it particularly useful, as I’m used to the quasi-programming I can do in a terminal. The shell commands take some time & effort to learn, but once you’re over that hump, being able to extract and compose information is really good. The primary shell tools I’d miss in a gui are |, jq, awk, sed and grep/rg, as well as for, if, while, variables, and having everything in one lightweight window.

  • algernon@lemmy.ml
    143·
    6 days ago

    I have Emacs, and I have my NixOS configuration. That’s all the GUI system configuration I need.

  • ubergeek@lemmy.todayEnglish
    171·
    6 days ago

    A decent GUI LDAP client.

    Yes, I know, I can use slapcat and all… But holy hell, I’m tired of writing basic LDAP files to populate a new domain. And, no, I really don’t want to spin up a webserver just to run a web based GUI that I NOW have to ensure is locked down.

    • Leaflet@lemmy.worldEnglish
      2·
      6 days ago

      One of my favorite things about Gnome is that almost anything can be customized via CLI with dconf or gsettings. Which is great until you encounter one of the few things you can’t customize, like displays.

    • user_naa@lemmy.worldOPEnglish
      7·
      6 days ago

      What is your DE? On KDE Plasma Wayland you can just use kscreen-doctor output.HDMI-A-1.scale.2 to set it to 200%

      And it seem like CLI not GUI issue :)