alt.hn

5/3/2026 at 10:55:30 AM

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

https://github.com/Matheus-git/systemd-manager-tui

by thunderbong

5/3/2026 at 12:36:30 PM

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

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

by jbvlkt

5/3/2026 at 5:01:46 PM

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

by unixhero

5/3/2026 at 11:14:39 AM

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?

by quantummagic

5/3/2026 at 12:29:40 PM

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

by pamcake

5/3/2026 at 2:14:13 PM

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:

by db48x

5/3/2026 at 3:35:13 PM

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.

by nozzlegear

5/3/2026 at 11:49:00 AM

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.

by alfanick

5/3/2026 at 12:01:23 PM

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.

by quantummagic

5/3/2026 at 12:17:19 PM

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

by thunderbong

5/3/2026 at 4:30:01 PM

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).

by dspillett

5/3/2026 at 1:58:23 PM

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

by RevaFloyd

5/3/2026 at 1:30:00 PM

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

by drcongo

5/3/2026 at 5:29:09 PM

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?

by atoav

5/3/2026 at 1:57:02 PM

It seems like services.msc for systemd.

by zx8080

5/3/2026 at 6:13:14 PM

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

by marshray

5/3/2026 at 1:42:18 PM

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.

by Pay08

5/3/2026 at 4:34:26 PM

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

by physicles

5/3/2026 at 4:53:15 PM

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.

by Pay08

5/3/2026 at 6:21:04 PM

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?

by marshray

5/3/2026 at 6:32:54 PM

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).

by Pay08

5/3/2026 at 6:52:25 PM

[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.

by marshray

5/3/2026 at 2:15:06 PM

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.

by childintime

5/3/2026 at 4:33:05 PM

Turn the TUI for systemd into a language?

I don’t see what you’re seeing.

by paulddraper