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:
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 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.
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
Also: https://kainctl.github.io/isd/
It seems like services.msc for systemd.
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.
But all their issues are being tracked tho? The author looks like put it on roadmap
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.
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.
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.