Support Testing of Uselessd

nobicycle · 2014-09-22 05:17:02

Uselessd is a true Linux init project forked from systemd.
http://uselessd.darknedgy.net/

Download: https://bitbucket.org/bcsd/uselessd/downloads
Install instructions: https://bitbucket.org/bcsd/uselessd/src … inux-devel

The project requires testing.

In step 2 of the instructions I would like to know what the correct values would be for Arch Linux?
:

Run configure, view the help, enable and disable
   components as seen fit. Of particular importance
   are the following prefixes, which may vary between
   distros:

   --sysconfdir=
   --with-root-prefix=
   --with-sysvinit-path=
   --with-tty-gid=
   --with-telinit=
   --with-sysvrcnd-path=
   --with-kbd-setfont=
   --with-kbd-loadkeys=
   --with-rc-local-script-path-start=
   --with-rc-local-script-path-stop=

   sysconfdir is /etc, root prefix is typically left
   blank, sysvinit path is typically /etc/init.d/,
   GIDs can be discovered using `getent group
   <GROUPNAME>`, sysvrcnd-path may be /etc/rcS.d/,
   so on and so forth.

ewaller · 2014-09-22 05:35:53

I am not sure what to do with this, but an init system does not belong in kernel and hardware. It is neither.

Moving to AUR Issues. Let's see what happens there.

tomk · 2014-09-22 07:00:09

Apart from the examples given e.g. sysconfdir=/etc, there are no "correct values" here - just try various options and see what works best. If/when others decide to try it out, you can all compare notes and come up with some guidelines for Arch.

ANOKNUSA · 2014-09-22 13:41:00

The OP should probably replace this ambiguous description:

Uselessd is a true Linux init project forked from systemd.

...with the one found on the project's website:

uselessd (the use less daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.

Calling this project a "true Linux init project" is just begging for another bullshit flamewar.

tzoi516 · 2014-09-22 16:44:21

Seeing a lot about uselessd via my Twitter and Linux RSS feeds. Plus, Linus doesn't seem to fond of it.

stevenhoneyman · 2014-09-22 17:00:26

I'm all for systemd replacements, but a quick read of the description and it seems most of the things it's offering can already be un-included in systemd with a couple of extra ./configure parameters. (httpd,logind,coredump,networkd,etc)

Awebb · 2014-09-22 19:25:03

Looks like uselessd.darknedgy.net is down. Too much traction for a small server, I guess.

falconindy · 2014-09-22 20:02:13

Awebb wrote:

Looks like uselessd.darknedgy.net is down. Too much traction for a small server, I guess.

Down again, you mean. It was already hacked and defaced (at least once) over the weekend.

exidux · 2014-09-22 22:33:47

It is up and running when i checked it just now ; http://uselessd.darknedgy.net/
I feel like testing this, but....

Awebb · 2014-09-23 05:45:29

Hacked and defaced? Is there no end to this stupid XvsY games? One day, I swear, I will get my hands on one of those script kiddies and then I will deface it. With a peeling knife.

jasonwryan · 2014-09-23 06:46:19

@Awebb: that is unnecessary, please refrain from hijacking the thread any further.

tzoi516 · 2014-09-23 11:37:00

If Linus doesn't like systemd, and uselessd is more simple and lighter, than wouldn't The Arch Way call for a possible replacement in the future?

th3voic3 · 2014-09-23 12:34:11

tzoi516 wrote:

If Linus doesn't like systemd

He is neutral

falconindy · 2014-09-23 12:43:02

tzoi516 wrote:

If Linus doesn't like systemd, and uselessd is more simple and lighter, than wouldn't The Arch Way call for a possible replacement in the future?

Your premise is as flawed as your conclusion. Linus had a spat with Kay (a single systemd developer who also writes a lot of kernel code), and certain "news" outlets decided to turn this into linkbait by tying in his relationship to systemd. Linus has stated that he's ambivalent about systemd.

Linus wrote:

I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.

Source

I don't know why you think anyone would ever want to adopt uselessd over systemd. The project page makes it clear they don't know what they're doing. Counterpoints:

> Support for compilation under musl and uClibc
This just means they've rejected the glibc solutions for real problems and replaced them with insecure alternatives. For example, they blindly use getenv in place of secure_getenv (introducing security risks) and qsort in place of qsort_r (losing reentrancy).

> Certain superfluous unit types removed, namely devices, timers, swaps, mounts and automounts.
It's misguided to call these "superfluous", mostly with regard to device units. This is a key element of systemd -- tying device events to system services. This is the only way you can activate hardware-dependent services in a race-free fashion. For example, you'll run into problems with something as simple as unlocking an encrypted USB device through /etc/fstab. Without tying into udev, you have no idea when USB hub enumeration will finish and present the raw block device for decryption. Their proposal to use udev rules as a full replacement is infeasible -- it's not nearly as flexible and only fragments service configuration.

> Various unnecessary auxiliary daemons (hostnamed, timedated, localed, logind, etc.) have been stripped from the source tree level.
Well, except that these all provide value. The first 3 allow you to do things like change your hostname, time and date, timezone, and locale as an at-console non-root user, as well as set these properties transiently on a read only root. logind has obvious value (I'm sure they're just going to recommend using the very dead consolekit instead).

> All generators, sans getty-generator and rc-local-generator, have been removed, as well, either due to assuming libudev semantics, because of implementing faultily defined logic, or because they rely on unit types we do not use.
...which means that you'll just have to reimplement these things with some out-of-band solution that won't integrate as well. I sure as hell don't want to go back to the old way that Arch handled encrypted devices, but uselessd wants you to do that. I also don't know what they mean by "faultily defined logic", but that sounds like bugs that they were too lazy to file and/or fix.

> systemd-fsck has been replaced with a service file that starts /sbin/fsck to fsck devices. In essence, this isn’t much different from what systemd-fsck already did, but with the overhead of a middle man executable interfacing with /sbin/fsck cut out. This also means that the systemd-defined sysctl parameters for its fsck are gone, and you should use the old ones (/forcefsck, etc.) instead.
The downside to this is that you're now waiting on fsck to finish checking everything, instead of allowing bootup to continue after critical filesystems are checked. I don't know what sysctl parameters they're referring to -- no such thing exists (maybe they meant kernel commandline options). The /forcefsck file is absurd -- if you suspect a problem with a filesystem, you don't want to issue additional writes to it. No, you'll probably want to remount it read-only ASAP and reboot so you can fsck it before it's even mounted. /forcefsck offers pretty much the polar opposite of this.

> Setup routines for various MAC/ACL systems, including SMACK, IMA and SELinux, are gone. We want to stick to a more clearly defined purpose, one that is agnostic of such elements. Nonetheless, we have retained SELinux access routines in D-Bus APIs and unit options for SMACK attributes in socket unit files to respect existing configurations.
Apparently, having a "clearly defined purpose" means keeping random tidbits of selinux and smack. Claiming to keep these bits in order to "respect existing configurations" is silly given that they blatantly break configuration semantics elsewhere (e.g. removal of x-systemd options from /etc/fstab, wholesale removal of various unit types, wholesale removal of logind).

No, let's not invoke "The Arch Way" here. I don't want any part of this project.

tzoi516 · 2014-09-23 13:47:47

falconindy wrote:

Linus had a spat with Kay (a single systemd developer who also writes a lot of kernel code), and certain "news" outlets decided to turn this into linkbait by tying in his relationship to systemd. Linus has stated that he's ambivalent about systemd.
Linus wrote:
I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.

Which is it 1 person or some of the developers?

I think this is an interesting discussion that doesn't warrant comments that could incite flame wars. Sure, I was slightly wrong, but I didn't make a post that contradicted what I was saying either.

Back on topic ...

Last I've read systemd and an issue with the base kernel’s debugging routine. Has that been fixed? If it hasn't does uselessd fix it? I think if people like Linus and Ingo have issues with how the developers code then that tells me it's not as refined as it should be and maybe looking for an alternative wouldn't be a bad idea.

falconindy · 2014-09-23 13:54:24

tzoi516 wrote:

Back on topic ...
Last I've read systemd and an issue with the base kernel’s debugging routine. Has that been fixed? If it hasn't does uselessd fix it? I think if people like Linus and Ingo have issues with how the developers code then that tells me it's not as refined as it should be and maybe looking for an alternative wouldn't be a bad idea.

Yes, systemd changed its handling of the kernel commandline word "debug". I don't know that uselessd backported that change (since it was done so after v208).

edit: no it did not.

Last edited by falconindy (2014-09-23 15:20:05)

ANOKNUSA · 2014-09-24 15:29:41

tzoi516 wrote:

Which is it 1 person or some of the developers?

It's irrelevant either way. Leave it at that.

darkfeline · 2014-09-24 20:42:14

nobicycle wrote:

Uselessd is a true Linux init project forked from systemd.
http://uselessd.darknedgy.net/

I think that domain name says it all, really. Dark and edgy, some project by a teenager with too much time on their hands.

I don't know enough personally to make any technical claims about uselessd or systemd, but as far as replacing systemd with uselessd officially, that is not The Arch Way at all.

Is it broken? Does systemd crash or misbehave all the time, and your bug reports are ignored? (Personally, I haven't had systemd crash or noticeably bug out since Arch migrated.) If it ain't broke, don't fix it.

Does uselessd add new, useful features? No, it in fact removes useful features.

So there's no reason why Arch should use uselessd. KISS means SIMPLE, not split every functionality up into its own separate binary. Yes, the systemd code might be less simple than uselessd, but when it comes to using it? With systemd, it "just werks". Simple. The Arch Way.

Feel free to roll your own PKGBUILD in the AUR though.

ConnorBehan · 2014-10-02 03:59:15

falconindy wrote:

I don't know why you think anyone would ever want to adopt uselessd over systemd. The project page makes it clear they don't know what they're doing. Counterpoints:

These are pretty easy to work around for uselessd's target audience (hobbyists who prefer cheap self-written hacks to enterprise software). Following worse is better doesn't make him a bad programmer.

However, there is also no evidence that he's a good programmer. And I agree that Arch should not tie its reputation to a random anonymous dev who has suddenly jumped on a bandwagon.

Spider.007 · 2014-10-25 13:16:35

falconindy wrote:

[...]
> Various unnecessary auxiliary daemons (hostnamed, timedated, localed, logind, etc.) have been stripped from the source tree level.
Well, except that these all provide value. The first 3 allow you to do things like change your hostname, time and date, timezone, and locale as an at-console non-root user, as well as set these properties transiently on a read only root. logind has obvious value (I'm sure they're just going to recommend using the very dead consolekit instead).

Thanks for your extensive reply; I have been wondering about a few of these issues as well. I'm not sure if I agree on your response to the auxiliary daemons mentioned, especially hostnamed & timedatectl. I don't see an enormous value in these utilities and I wonder if/when the systemd' devs will decide that they don't need /etc/localtime and /etc/hostname anymore. Would you agree that the removal of those poses a risk to the Linux ecosystem?

darkfeline wrote:

[...]
I think that domain name says it all, really. Dark and edgy, some project by a teenager with too much time on their hands.

I think judging software on it's domain name is a terrible idea.

darkfeline wrote:

Is it broken? Does systemd crash or misbehave all the time, and your bug reports are ignored? (Personally, I haven't had systemd crash or noticeably bug out since Arch migrated.) If it ain't broke, don't fix it.

One of the issues I have with systemd is that if it doesn't work; there is no alternative, or a simple method to debug it. This is an huge difference compared to simpler init-systems that are based on clear-text shell-scripts, such as the one Arch previously used.

Earnestly · 2014-10-28 19:34:34

ConnorBehan wrote:

Following worse is better doesn't make him a bad programmer.

Yes, yes it does.

Arch Linux

#1 2014-09-22 05:17:02

Support Testing of Uselessd

#2 2014-09-22 05:35:53

Re: Support Testing of Uselessd

#3 2014-09-22 07:00:09

Re: Support Testing of Uselessd

#4 2014-09-22 13:41:00

Re: Support Testing of Uselessd

#5 2014-09-22 16:44:21

Re: Support Testing of Uselessd

#6 2014-09-22 17:00:26

Re: Support Testing of Uselessd

#7 2014-09-22 19:25:03

Re: Support Testing of Uselessd

#8 2014-09-22 20:02:13

Re: Support Testing of Uselessd

#9 2014-09-22 22:33:47

Re: Support Testing of Uselessd

#10 2014-09-23 05:45:29

Re: Support Testing of Uselessd

#11 2014-09-23 06:46:19

Re: Support Testing of Uselessd

#12 2014-09-23 11:37:00

Re: Support Testing of Uselessd

#13 2014-09-23 12:34:11

Re: Support Testing of Uselessd

#14 2014-09-23 12:43:02

Re: Support Testing of Uselessd

#15 2014-09-23 13:47:47

Re: Support Testing of Uselessd

#16 2014-09-23 13:54:24

Re: Support Testing of Uselessd

#17 2014-09-24 15:29:41

Re: Support Testing of Uselessd

#18 2014-09-24 20:42:14

Re: Support Testing of Uselessd

#19 2014-10-02 03:59:15

Re: Support Testing of Uselessd

#20 2014-10-25 13:16:35

Re: Support Testing of Uselessd

#21 2014-10-28 19:34:34

Re: Support Testing of Uselessd

Board footer