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?
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:
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).
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 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?
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.
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.
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.
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 awesomelidt for this too. Maybe Claude can make one for us. All of them look promising.
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?
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.
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.
Three months for a utility tool like this is nothing to panic in comments about.
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).
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.
But all their issues are being tracked tho? The author looks like put it on 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?
I actually use this tool and it's pretty great, certainly for my needs anyway.
It seems like services.msc for systemd.
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.
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.