Just learn it. Then you'll be able to modify existing software to your taste, and take over others that you find valuable but that are no more maintained.

1 members found this post helpful.

http://www.amazon.com/gp/aw/d/013110...&robot_redir=1

Pretty good book and really easy to follow (starter this week)

The BSDs ignore systemd? You might be interested in these GSoC project from OpenBSD: https://www.google-melange.com/gsoc/...39274879778816 http://www.openbsdfoundation.org/gsoc2014.html#systemd

That is what I said already before. Instead of complaining on Internet forums the just go ahead and do something about the situation. Now it would be funny if their solution will be portable to Linux, so that any Linux user that doesn't want systemd can use its OpenBSD replacement.

3 members found this post helpful.

Yes, but that project is OpenBSD only for now, and we have no idea how tied to the kernel it is, if its anywhere near completion, or even if and when it'll be stable. Plus, is it even compatible with FreeBSD, NetBSD, etc.?

Its yet another step in the right direction, but for now, still skeptical on this.

1 members found this post helpful.

Sure, it is just in the beginning and we don't know if it ever will come to any other OS, but that wasn't my point. My point was that they simply go ahead and do something about this situation, that they are not ignoring it (as I said before, ignoring a problem will not solve it). They just go: "Hey, look, this new systemd thing is used by more and more projects, especially DEs, we have to do something about it when we want to have the option to run that software on our systems, so let's start coding!"

1 members found this post helpful.

The bad thing is that systemd is more designed around a desktop environment, but less designed for command-line. Most BSD systems I've worked with are not desktop systems, but servers running a command shell.

Plus its still stepping away from the UNIX philosophy so its still going to be a wait and see I guess. I just hope this effort isn't one that is going to be a huge waste of time and effort on things that could be focused elsewhere more important.

2 members found this post helpful.

You sure do make it sound so easy...when you're volunteering someone else.

Why don't *YOU* give it a shot? Volunteer yourself first before you volunteer others.

I checked the link, and they say that the goal is for the replacement to be "os-agnostic".

Very interesting. Looks like they aren't interested in systemd's init features, and are just looking to implement the parts that DEs are likely to have as dependencies.

3 members found this post helpful.

I suggested to ReaperX7 to volunteer because I'm tired to see so many posts he writes about what should or could be done by other people regarding replacement of systemd, instead of doing it himself (and this is not to minimize his contributions to (B)LFS in that matter, but that don't seem to be ported to other distributions at time of writing, especially to Slackware).

Me, I don't care to volunteer to projects I'm not interested in.

But I do contribute to projects I'm interested in, like slint that I lead.

2 members found this post helpful.

This is not true. systemd provides more functionality than previous init systems - functionality which is (now) needed by certain DEs. This does not mean that systemd is designed more for DEs than it is for servers. (In fact I'd say it's the other way around, but it doesn't even matter.) You're trying to make systemd into something it isn't. Some kind of anti-UNIX, anti-ReaperX7 machine. It's a patently Linux-focused solution to the developers' needs.

I typically refrain from posting on any forum, but your FUD is ridiculous.

Irs not my problem if my contributions to BLFS are aimed at BLFS. I even posted that if anyone wanted to they could easily import the work into any Linux based OS, including Slackware. It's not my problem if my target distribution isn't in your comfort zone. BLFS is about as open as any distribution can get, so unless you feel my work isn't to your standards, my works are under the MIT license and you're free to port it out as you see fit such as the Runit and Eudev ports. Myself, Keith, and Stoat all put a great deal of effort into them all, so I'm sorry if our work isn't to some high and mighty standard you feel it should be at.

You know full well everything in BLFS is done through makefiles which are merely automated through SlackBuilds.

Just because the way I see things is more in tune with the UNIX philosophy and founding principles doesn't make my points of view and more or less valid than anyone else's.

And Fatalfrrog if you have a problem with where I got my info on systemd being more for DEs than CLI, go talk to Bruce Dubbs one of the developers of LFS and BLFS and tell him he is wrong, not me.

3 members found this post helpful.

Well, I didn't despise your work on BLFS in any way but just noted that it's not os-agnostic (and that is a statement of fact, not a reproof to anyone), so I don't understand your answer. As I'm not that much interested in that systemd topic, I will refrain from posting again in this thread, sorry for the noise, I offer my apologies to all readers.

How is our Runit implementation for example not system agnostic? All you need is the basic software sets from any distribution, some recycled sysvinit or bsd-style-sysvinit bootscripts and it drops right in with minor edits. All you have to do is work out the run scripts which are fairly system universal.

Anything from LFS is built fairly much system universal to Linux.

1. You concede it's "linux-focused" - not the *nix way.
2. It does a lot more than init - very true and a good part of why it inspires distrust. An init system has one job to do, adding more jobs to it just expands opportunities for failure. Not the *nix way.
3. If it were friendly to the command line why would it even for a fraction of a second have ever even considered locking the log files up in binary?

It may well be that they are focused on servers (as in *virtual* servers if I dont miss my guess) but it's certainly NOT focused or even interested in the *nix way. And it looks very much to me like a return to the bad old days of proprietary unix forks doing things in wierd ways because of MBA-buzzword-logic instead of solid software engineering.

9 members found this post helpful.

No, it does not. systemd the init system does exactly what an init system does: starting and supervising processes. systemd the project offers indeed a lot more options, but they are, except systemd-udevd and systemd-journald, optional and can be replaced with any services you want. This is basically the same as the BSDs do: offering a base system on which you can built up.