uselessd: Brought to you by boycottsystemd.org
 

http://uselessd.darknedgy.net

We at boycottsystemd.org have been working to inform people of the various issues that surround and encompass systemd. We've found some success on this front. But ultimately, simply presenting this information to you has done very little to actually encourage movement away from systemd. So, a while back, one of our wannabe greybeards set up a fork of systemd with the intention of stripping away (almost) everything that we viewed as harmful, uneccessary, or poorly implemented. After a couple of months or so of work, they're proud to release uselessd - a fork that strives to avoid most of systemd's failures.

Aside from stripping out a lot of cruft under the hood, uselessd accomplishes several things which the systemd developers have either ignored or blatantly refused.

uselessd

• is lightweight. One of our goals with uselessd was to purge systemd of a mostly useless codebase, in favour of a smaller, simpler project. uselessd does not depend on libudev, and compiles without journald.
  
• has a concrete goal. Initialize the system, supervise processes, and shutdown the system - No more unwanted feature creep.
  
• is portable. Cleaning up the mess that is systemd's inner workings meant not only stripping away cruft, but reimplementing glibc-specific features (a process we call deGNUification) in mostly libc-agnostic ways. uselessd compiles on glibc, musl, uClibc and even BSD libc.
  
• is grokkable. One of the biggest issues people have with systemd is that because it's so monstrously complex, seemingly only a highly skilled team of developers could maintain it. uselessd does not strive to encompass all the major aspects of your operating system, and we believe this makes for a cleaner "userspace building block."
  
• has a cool logo.

I applaud someone for taking the general code of systemd and making something significantly more streamlined from it, however, at this point with how many teams have already integrated systemd into their distro, and the fact that one of the linux big names obviously will not abandon it, I'm not sure if this will get any mainstream traction. Which is a pity.

I first I thought this was a joke. Then I asked whether I'd really trust my computer to a piece of software produced by a single developer and unsupported by any distribution. Then I wondered if it was a joke…

I followed the link(s) and actually read what was on offer. Whether one developer or a team, I think it is a worthwhile effort if only to set some kind of boundary condition to answer how little systemd is going to be necessary to continue with Linux. But I think this particular guy does himself a disservice in his presentation - it is a serious effort but as others have noted, it comes off as maybe a joke when you visit the webpage. He should make it more clear that it is a serious undertaking earlier in the page.

I have added it to my own list of systemd-avoidance information resources but will not likely try to install or use it at this time.

I am neck-deep in my own strategy for preventing systemd from interfering with my own use of my computing devices. One component of that strategy is to follow (and support where possible) the efforts of others who are capable of developing the necessary code, which I am not, and hope that one or more will emerge as viable alternate paths forward, if needed.

But my overall strategy is not dependent on finding a "new" init system, I don't need one - yet. I am more focused on keeping with the stability of the existing options and think they will hold their own against the fads and corporate packagings, at least for my uses and lifetime.

Looks somewhat interesting, but I dunno. Could use a better less inclined to be joke of a name though. However they probably could have left logind in maybe since the shim being developed by OpenBSD is including it. Overall, it's a step somewhere, but with the obviously comedic insult to the systemd website and author it's a bit hard to say forward or backward. It does give the "knocked down a peg or two" amusement.

Maybe a name like serviced would have been taken more seriously. They could have kept logind since the focus of ConsoleKit and hald are shifting.

It's a start though. Killing journald was a real start though. The systemd kabal (as they call themselves) should take note and make everything in systemd completely optional, if they did they might acceptance from the reluctant.

So much for the theory that "systemd will offer a complete set of building blocks for GNU/Linux". If everything could be stripped, ripped, and modularized then basically all we have is the theory of "the more things change, the more they stay the same" building blocks we've used for years.

>4chan goes "let's make a systemd!"

OK, kid.

To pull a Darth-Vadarism: "Never underestimate the power of 4chan!"

i had been long since put off systemd as it continued to swell and swallow other components and functionality.

this seems to return it to closer to when i was on the fence, and steer it back away from what put me off.

very glad uselessd exists, regardless of whether it gets picked up by any distros, or if a joke, or a proof of concept, or if i'll even use it*.

and i do like the name. and the site. kinda does well to silence the systemd fanbois before they even start. :) ... well, nearly. ;)


*might have a poke at trying it in a minimal lightweight-compiled from-scratch system at some point.

I just hope someone can spin out logind into a stand-alone service as well.

To be true, this doesn't just shut up the fanbois, it's a direct assault on what systemd personifies, and it outright upholds the argument of cathedral versus bazaar project principles.

I hope they do well, but that remains to be seen.

So are there still binary logs and configs ?

I hope it isn't ported to BSD. I'd rather they not get any ideas about switching to anything like systemd.

Journald is dead.

Elaborate?

They removed it out. You'll still need rsyslog, sysklogd, etc.

The README on the uselessd rep says:

"systemd/uselessd will warn you during boot if /usr is on a different
file system than /. While in systemd itself very little will
break if /usr is on a separate partition many of its
dependencies very likely will break sooner or later in one
form or another. For example udev rules tend to refer to
binaries in /usr, binaries that link to libraries in /usr or
binaries that refer to data files in /usr. Since these
breakages are not always directly visible systemd will warn
about this, since this kind of file system setup is not really
supported anymore by the basic set of Linux OS components."

I am running Arch and have my /, /usr, /var, /opt and /home as separate partitions. I am still
not convinced about the need to have everything in "One Big /usr" which precludes one from having
a minimal system I could boot up into as a rescue device. Well, it is there and as I generally like Arch,
I well ...

But, the question is "What are the subdirectories that one can continue to have on separate partitions to
be able to comply with the new diktat of One Big /usr?"
1) Not /usr any more
2) /home - thank God for that
3) /var - given the crap that goes into it package cache, mail spool putting it on a separate partition makes a ton of sense, but
wait! It has /var/log on it.
4) /boot - yes that is still possible

So, by adding /usr and /var - my / goes from < 100 MB to 16 GB+! Why can't we continue to have small binaries, possibly self-contained and statically linked in the old /bin and /sbin? I have still not understood the rationale of the Big /usr? Avoiding duplication? The fact that there is an init?

---------- Post added 09-23-14 at 08:51 PM ----------

The README on the uselessd rep says:

"systemd/uselessd will warn you during boot if /usr is on a different
file system than /. While in systemd itself very little will
break if /usr is on a separate partition many of its
dependencies very likely will break sooner or later in one
form or another. For example udev rules tend to refer to
binaries in /usr, binaries that link to libraries in /usr or
binaries that refer to data files in /usr. Since these
breakages are not always directly visible systemd will warn
about this, since this kind of file system setup is not really
supported anymore by the basic set of Linux OS components."

I am running Arch and have my /, /usr, /var, /opt and /home as separate partitions. I am still
not convinced about the need to have everything in "One Big /usr" which precludes one from having
a minimal system I could boot up into as a rescue device. Well, it is there and as I generally like Arch,
I well ...

But, the question is "What are the subdirectories that one can continue to have on separate partitions to
be able to comply with the new diktat of One Big /usr?"
1) Not /usr any more
2) /home - thank God for that
3) /var - given the crap that goes into it package cache, mail spool putting it on a separate partition makes a ton of sense, but
wait! It has /var/log on it.
4) /boot - yes that is still possible

So, by adding /usr and /var - my / goes from < 100 MB to 16 GB+! Why can't we continue to have small binaries, possibly self-contained and statically linked in the old /bin and /sbin? I have still not understood the rationale of the Big /usr? Avoiding duplication? The fact that there is an init?

Part of me thinks that if having a big ego creates motivation then it's okay. How about notRedHatd ? I really want to see a clear separation between systemd ,uselessd and init no mater if they all exist at the same time.

Maybe we could just change the name of the best existing method to SysVinitd and stick with the proven winner? Sure would save wasting everyone's time chasing the biggest loser-d!

/home is just a replacement for /usr, where the user directories resided (i. e. /usr/home), before they got moved to /home.

There are even setups, where /var/log is a separate partition mounted with different flags. And /tmp, of course.

/boot is just a workaround for separating the boot files from a cluttered /, when / = /usr

AFAIK the "UsrMove" was a design decision to make the BSD jails copycat "docker" work. But I didn't look into the details and I'm not interested.

I don't see this mentioned anywhere official. Is it just one distro you are talking about? Or is it a rumor?

Have a link?

http://uselessd.darknedgy.net/

The uselessd maintainer was able to remove the journald code completely from the codebase and after more stripping down the code, all he was left with was the bare bones init system, the part of the project that actually is the init system itself, no more, no less.

Gradually, many bits and pieces of software that sit between the kernel and userspace are all hoovered up into one monolithic code block controlled by a single company. Because of the loss of all those various bits, there is only a single player that all other distros must adopt, as the alternative will no longer be developed or supported.

Now that's happened, a single company will be able to unilaterally dictate further GNU/linux development, or break other distros, maybe purposely, while advancing its own distro.

This is a clear "Embrace, extend, extinguish" strategy.

No more systemd-shim then.

Guess it's back to reviving ConsoleKit somehow...