I was reading up on GNU and the packages associated with it, and read userland (Or user space) and GNU sound synonymous with each other.

I had never read that systemd (or init) was part of a GNU package... But systemd and the system daemons run in user space... so I got curious at the potential contradiction

I read the man & info pages... but saw on the wiki page systemd is licensed as part of GNU LGPL 2.1+... But it was developed by Red Hat. Since it's not developed part of Richard Stallman's GNU project.... How exactly does it fit into GNU?

Since it's not part of the GNU project... Is it accurate to say it's part of the userland? Part of GNU? How would someone describe this

GNU LGPL is a license. Seems to me it's very different of GNU softwares.

You need to distinguish between software that the GNU foundation actually developed (GNU utilities, the gimp, gnome, gtk) and the GNU license, which anyone can use for their software. All GNU-licensed software is free open-source software but not all of it is developed by GNU. Red Hat, Mozilla and other groups have added a lot.

Userland is simply everything that isn't the kernel.

And it's probably better not to start threads on systemd. It tends to provoke flame wars.

No. GNU makes (or federates groups that make) software. Other groups and companies also make software. E.g. Gnome, Firefox, MySQL, Apache are not from GNU. They may not even use a GNU license: Mozilla has its own license, for example.

What do you mean by “fit”?
Software often has components that run in the kernel and other components that run as user processes. Examples iSCSI or Openvswitch. So, this is not an accurate description either.

You describe it as: The kernel is Linux, a lot of the fundamental software is from GNU, other software is developed by others, and software can include kernel components. Linux distros bundle all that together, and almost everything is open-source, often with a GNU license.

Personally I like a nice fire. Let’s add some fuel. You know, I think systemd represents a huge progress in system management.

for the U.S government it sure dose how else could they have gotten a back door installed other than having one of there contractors do it Red HAT

yep it gives the us government total system management over every computer with systemd installed on it

^ that didn't take long!


anyhow, Linux or GNU isn't any sort of tightly structured organization; software gets developed here and there and everywhere, and under certain circumstances gets integrated into larger software projects and distributions, and if that's one of the large distributions, it can become a de-facto standard...

Yes, I am quite pleased. I didn’t expect that my fuel would burn that fast.

Actually, the backdoors are in the kernel. I mean, Thorvalds drives a Mercedes.

Sorry for turning the question into a bonfire, but I think the OP has received a few good answers already.

GNU is responsible for the core userland of GNU/Linux, while Linux is responsible for the Kernel to setup the hardware to work for the userland. GNU is also responsible for creating the most known free software licence.

Where does Init fit into this? It fits into it about where a bootloader fits into it. "Between" things. Init is simply the first process that starts the userland. It is not part of the Kernel, nor is it part of the core GNU userland, but it is started by the Kernel and starts the userland core or the "environment".

I am not an expert on init, but sysv init is basically a bunch of scripts that just started the necessary things to invoke the userland, and this was why SystemD was born, because they did not think that was a good solution, and wanted not only to start everything, but also control everything that was started. Then the whole controversy about SystemD was born.

So, init doesn't fit into GNU or Linux. It is a separate projects, like many bootloaders also are, that is part of the vital first part of the system, getting it booted and running. Most "independent projects", those that are not THE GNU/Linux part, normally concern themselves with things that are not core to the system, ie, Firefox as a web-browser, running on an already existing system, or additions to the userland. The init doesn't fit that description, and falls into the same camp as the bootloader, as an independent projects that is part of the core system, but is neither GNU nor Linux, but integral to both.

Sure, I know Grub is a GNU project, but there are plenty of non-GNU bootloaders as well. Sure, GNU could have made their own init system, but this was not needed.

System V was actually created by AT&T for Unix, and the GNU/Linux variant is like much else, a rewrite from scratch. I'm not an expert on the history of SysV in GNU/Linux, I'm sure someone else can sum up the history better than I can.

Often but not always:
- Bootloader starts Kernel
- Kernel starts init
- Init starts userland

Not really: init is a process (compiled executable) that works from a table (/etc/inittab) to start up a lot of things, like the getty's (console, textmode login), the display manager (gui login) and i.e. powerfail shutdown.
Where the scripts kick in is with the rc scripts for managing the run levels.
Here is where BSD init and the one from System V differ, BSD essentially only differentiates between single user (runlevel S or 1) and multi-user state, the rc.M (multi-user) script (singular) does "the rest". SysV has multiple directories for each of the levels with (links to) the scripts that must be started (or when shutting down: stopped) for that level. This is very flexible but indeed, a bit slow (although using dash instead of bash FOR those scripts already makes a large difference).

In my opinion (but you are allowed to have a different one) SysV has never been implemented the right way IN Linux (I came from real System V Unix and have seen how it's been done there), but I will not rant about it, it is how it is.

But to the OP: init is much older THEN linux as a whole and even lots of the GNU tools originally were developed as Open Software alternatives TO the original Unix ones. Even the X.org project (which is NOT Gnu) is older then Linux.
But currently Linux is used as a short name for Linux kernel + GNU tools + X + .....

I'm not really that familiar with sysv init, but sysv and init itself is two different things, no? And from my understanding sysv is a bunch of scripts that invokes various things, isn't it?

Anyways, I recently read the whole main init script of Slackware, which I guess the init executable invokes? Isn't it the same way in SysV?

sysv is a short name for System V Unix, which also has set standards for Unix in general (the SVID, System V Interface Definition, see http://en.wikipedia.org/wiki/System_...ace_Definition

In System V the original "/etc/rc" script (singular), which was one of the things started through the /etc/inittab table, was broken up into separate scripts, that can be started (or not) and stopped, that's mostly called the sysv init system.

Slackware essentially uses a BSD (Berkeley Software Department, they developed their own kind of Unix) type init system with only a few scripts (rc.?, single character). rc.M does use other scripts, though, to give more flexibility (in pure BSD you would always have to edit the rc.M script for that).
It also looks through the rc?.d directories for add-ons that could have installed startup scripts there, although in a pure Slackware install those are all empty.

tbh I like it the way Slackware does it. It's simple and it works.
Sorry, I said I read through the "main" init script in Slackware.. Sure I did that, but I also read through the 2 other ones.

I like the idea of multitasking those start up tasks though, but it is not really that important. It's a bit of an oxymoron in SystemD that you multitask a bunch of init things that you don't really need but is required by SystemD. Does that really speed up anything, or is it a false solution?

bsd init is definitely faster. Crux uses it too and somebody wrote a version for LFS which I've adopted. But afaik both sysvinit and bsdinit use the same init program. It's only the arrangement of the scripts that is different.

Yes!
The Slackware man page for init even says:
In Slackware that last is done through the /etc/rc.d/rc.sysvinit script (which is called from rc.M). But, as I said before, in a standard Slackware install with no 3rd-party packages, all of those rc directories are empty, they are only there for when you install some package that wants to put its System V compatible rc start/stop scripts in there.
When you would make rc.sysvinit non-executable you will loose the sysv compatibility and have a pure BSD init.