Systemd-manager-TUI: A TUI application for managing systemd services | Hacker News Reader

Systemd-manager-TUI: A TUI application for managing systemd services

github.com

84 pointsthunderbong27 comments

Open articleView on HN

I use systemctl-tui for this. It looks more mature sw than this project.

https://github.com/rgwood/systemctl-tui

Great now we need an awesomelist for this. Maybe Claude can make one for us. All of them look promising.

There are already websites creating terminal tools catalogues. I like https://terminaltrove.com/

Whoa thanks a lot

Also: https://kainctl.github.io/isd/

I'd welcome such a tool, but it makes me nervous that it hasn't had any activity at all in three months. Was this just a single-shot effort, and move on?

Three months for a utility tool like this is nothing to panic in comments about.

It’s open source. If you discover any bugs, report them. If the author doesn’t fix them quickly enough to satisfy you, fix them yourself.

    Permission is hereby granted, free of charge, to any person obtaining a copy
    of this software and associated documentation files (the "Software"), to deal
    in the Software without restriction, including without limitation the rights
    to use, copy, _modify_, merge, publish, distribute, sublicense, and/or sell
    copies of the Software, and to permit persons to whom the Software is
    furnished to do so, subject to the following conditions:

Unless you're invested in the tool for one reason or another, it's so much easier and more practical to just find a different one.

Doing what is easiest often causes suboptimal results. In this case people hopping from one inadequate tool to the next, instead of sticking with one tool for a long time and slowly improving it any time an inadequacy is discovered.

It's fine to mature projects if they're good enough according to author's point of view. No point of fixing something that's not broken. No point of adding features that no one needs.

That goes without saying. But there are a few bug reports and issues that have gone without a response for months. It seems abandoned, rather than finished to perfection. Not to mention that systemd is a moving target, with new features released quite often.

I had a look at the issues. I see comments added to each one of them. Some of them are already on the roadmap.

Why can software not be finished?

I once wrote a Rs-232 translator softeare converting between two different flavors of a control signal. This thing is running for 15 years without update and a single bug now.

Granted it also isn't user facing and it's environment won't change, so there is no pressure for changes, but why do we think software needs constant updates? Because y'all use dependencies you need to update? Because you're used to software shipping half finished?

For a small, essentially feature complete, utility, I would not be concerned. In fact for a tool like this I'd be more concerned by rapid turn-over suggesting current instability (i.e. a project in its early days, so buggy and/or changing rapidly).

But all their issues are being tracked tho? The author looks like put it on roadmap

I actually use this tool and it's pretty great, certainly for my needs anyway.

I tried making a similar project using Qt that would support a host of different init systems, but I unfortunately found that due to the available APIs and differing architectures of the different init systems, a consistent UI was really difficult. Systemd in particular didn't have a dbus API for logs.

Were you concerned about the overhead of shelling out to journalctl?

No, at the very worst I could have done it on a different thread (although I don't expect to have needed to). Since I initially planned on supporting 3 different init systems (systemd, Shepherd, and OpenRC) which are all used on wildly different systems, the shelling approach seemed way too brittle. Paths for example are going to be significantly different for systemd on Ubuntu and NixOS for example, and then there are distros like Alpine that like to put binaries into /usr/lib instead of /usr/bin sometimes for some unknown reason (had that one happen to me with Ninja, which caused problems with some CMake scripts I was using). So ultimately, I decided that the project had too many unknowns. Bit of a shame, since I planned to use it to really get to grips with Haskell.

You abandoned your dreams of mastering Haskell by making a system operator UI using QT, but gave up out of concern that `journalctl` might not be in PATH?

I gave up because I couldn't see a way to make the program consistent. The path issues were the most immediate concern, yes, but not the only one. I really wanted a consistent UI because there are few things that irritate me more than UI layouts switching up on me, but I just couldn't see a way of doing that. For example, OpenRC stores the complete description of service definitions in 2 separate files, one of which is optional. You have a shell script that contains the code to run in /etc/init.d, but you also have a config file that describes the environment that code is ran in in /etc/conf.d. If I wanted to have services be editable live in the GUI (and that was one of the main features I wanted out of it), I would have had to split the text editor into two panes for OpenRC.

Overall, I guess this is a kind of perfectionism or choice paralysis I guess. I have continued to write Haskell since, and am now comfortable with the base language, if not the ecosystem (I have no idea what a lens is).

[stares awkwardly in Haskell]

I often have to remind myself that we have the programs we have today only because somebody wanted them to exist more than they wanted them to express abstract properties like consistency.

It seems like services.msc for systemd.

This would look right at home on an IBM 3278 at the operator's station, controlling started tasks, releasing jobs to run.

I think I'm going to put on one of those retro CRT terminals :- D

I got a great I idea: let's turn this into a language, one that supports parallelism, so we can boot the system while maintaining full flexibility! /s

Now if we base this off the D programming language, the universe will remain at peace.. and who knows, something beautiful may blossom.

Nobody has made bold choices in Linux since it's inception. It's the same dated design, now supporting the latest hardware. Because, you know, backwards compatibility. What about compatibility with the future? Nah.

Turn the TUI for systemd into a language?

I don’t see what you’re seeing.

Reply on news.ycombinator.com