5 ms·
DMD has all those advantages as well. Dmd is the gnu daemon managing daemons.
by antocv 13y ago
DMD has all those advantages as well.
Dmd is the gnu daemon managing daemons.
- davexunit 13y agoI'm very excited about dmd. It's being developed in conjunction with the Guix project for an official GNU distribution. I hope to soon steer clear of this systemd mess by using a Guix system running dmd.
- antocv 13y agoYeah me too, and we can help, get on the guix-devel list and try to follow, learn guile/scheme and such. Im planning at least to provide more documentation, when I learn guix and dmd more.
- itistoday2 13y agoAre you kidding me? Have you actually looked at it? I'm a huge fan of Lisp-based languages, but this thing actually wants people to use Lisp for creating service files! http://www.gnu.org/software/dmd/manual/dmd.html#Service-Examples http://www.gnu.org/software/dmd/manual/dmd.html#Service-Exam... Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins. Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
- davexunit 13y agoYes, I've looked at it. You need to understand that dmd is still a fledgling project. Note the version number before you trash a software project. It lacks the features of the popular init systems, but it works well enough to run some basic services on the demo Guix VM images. I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
- sparkie 13y agoData-based formats are most useful when you know all the requirements one will need up-front, because they need to be coded into your "schema" or DSL - these schemas quickly break down when you have new requirements - and initialization is an extremely diverse area. The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software. It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile. As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.