Meh, if you look at the code to sysvinit it will probably dawn on you that this minimal init fails the criterion of "but not simpler," in "as simple as possible but..." e.g. it probably ought to look at which signal its child got when it returns from wait (or, heck, maybe even do a little error handling). I'm probably missing the point. Perhaps he's only put this out there as an elaborate way of saying, "as simple as...," as opposed to, "use this instead of bloated sysvinit's init".

I skimmed the code of sysvinit on the weekend as penance for participating in a systemd thread in another forum (whoops, now what should I read?). It's pretty small and easy to read as it is, so I'd be sad too to see it go. I love code where all the parts seem to do something concrete as opposed to setting out a structure or providing an abstraction. It's very much more fun for the casual reader that way.

If you don't like the whole concept and interests behind systemd, it's not too wise and tactical to adapt to its ecosystem by emulating API or forking it. This way you open another door for 3rd party software to make it even more a "standard" and common dependency. The opposite to generic universal approach with possibility of choice.

So I don't welcome this project and find such initiatives as a trick to cheat and misguide people unsatisfied what happened with recent RH's takeover success.

4 members found this post helpful.

A very good point, well stated!

If everyone supports systemd-like inits it only enables other parts of the ecosystem to become systemd dependent. The only effective resistance against that happening is if signifigant parts of the user base (i.e. distros and other major projects) do not adopt systemd-like inits.

As I have stated elsewhere, my own strategy for avoiding systemd contamination does not include finding an alternative - I don't need one and am not looking for one!

While I do take some interest in these kinds of projects, I ultimately hope they fail due to failure of systemd itself. In the event that too many upstream projects and/or my distro of choice must adopt systemd, I have already adopted FreeBSD as a fallback alternate.

The only way I currently see a systemd alternate in my own future is if the day comes when there is no Unix-like OS without it and all my old systems should fail to boot - afterall it is Unix that I depend on. I do not expect to live that long!

4 members found this post helpful.

Reimplementing init isn't an easy task. I doubt that without Patrick's guidance any init could be made viable for Slackware on the deepest levels. Command options, execution paths, etc. would all have to be specifically tailored to Slackware. You couldn't just reuse existing stuff from the bsd style sysvinit scripting used by Slackware or any other system. Some init methods execute in the foreground rather than the background, some execute as daemons and some do not, etc. Each init solution has to be custom tailored to the system in question. Slackware is no different.

uselessd only seems a stop-gap solution to the problem. It's a more sound solution being without the unnecessary parts, but if that's the case then all it offers is parallelization of boot, assignment of sockets as opposed to FIFO named pipes (which actually has never been proven to be better or worse), but it is just an init and nothing more.

2 members found this post helpful.

Two problems I have with this argument:

1. Taking the case of systembsd shims, the people involved seem to me be reacting to a broader environment where more broadly influential people, who have numbers, seem to be more or less implicitly telling them, "you don't matter." You see OpenBSD taking very uncompromising stances in other areas, e.g. no binary blob kernel drivers. You can't say they're pushovers. Here what do you expect the two who need Gnome for their work to do (look into it and you see where one at least has already communicated on Gnome mailing lists about the pain being caused them before this GSoC project ever began, so it's not like this was their first choice reaction). So what now, should they get mtier's users all to move to another desktop in protest? Which desktop with similar functionality will make life easier for them? How do they explain to their users and bosses why this is necessary?

2. Taking the case of uselessd, by forking and implementing only the narrow definition of an init system, if it did take off it would effectively be applying pressure on upstreams not to depend on those features of big systemd that it lacks. It's only going to be enabling upstreams to depend on a a limited common subset of shared features. Given he seems to want to support FreeBSD to some degree (so depending on cgroups would be out, for instance), I can't see that subset being very large or obnoxious.

it's not
you need two types of exec, forking(daemonizing) and one-shot
you need, and this is the most complex part, an algorithm to resolve dependencies (like topological sorting, but segmented)
a file format to describe all the needed data, like:
type:daemon/one-shot
exec:/bin/whatever
exec_argv:--an-option --another-one
depends_on:ice_cream
would_be_nice:spoon
env:
PATH=/bin/
IDK=/usr/share/candy
similar for env_change, env_add or idk
as_user:cookie_monster
proper_error_reporting:true/false

so now you got a format to describe things to execute and can, after parsing it, make dependency graphs that you can export in a .dot file for a nice overview before you reboot your computer into failing

actually executing things is also fairly easy
one-shot things return after fork-exec as expected

deamons have the "proper_error_reporting" flag that says if they are written properly
a daemon, amongst other things, does what is called double forking
it forks itself then the parent exits, making it parentless (but you don't care if you are not tracking its state)
a proper daemon would open a temporary file (like with shm_open) and fork itself
the parent would poll on the fd and exit when the fd has data in it
the child would set up whatever it needs to set up then write anything to that fd

if the child fails to set up it can write an error code to the fd, that the parent could return as an exit code for the init to read

maybe i forgot something, but that's the general idea

as for tracking processes you can use cgroups as an easy way or ptrace as a proper way (since it is way more powerful)

hf

PS socket activation is stupid

edit: also something like "network/internet" for a network connection
and "core" for.. idk devices (that udev sets up) and mounts, basically rc.S
(core should be implied thou)

@genss: you already stated that "making something like an init system or udev or whatever (isn't) hard".

The best way to convince us that it's easy would be to do it yourself.

By the way, if/wen you find the time to execute your plan I'll be interested in trying your udev replacement.

1 members found this post helpful.

Don't forget also you need to carefully consider which daemons can be triggered as events through another process as well through effective scripting.

ConsoleKit is a prime example of a daemon that can be ran as a service and as an event. You can trigger it with init scripts, or script it in from something like startxfce4's xinitrc file with a specific optional trigger.

Knowing which services can be one-shotted into the system also can be particularly bothersome as well. You have to carefully choose which goes into boot and which goes into long-term supervision.

no plans to write an init
slackware's is great for me

after i found that gentoo people are doing a great job in extracting udev my plan fell in priority
not that it was high since current udev works fine
it is still a plan thou

if anyone wants to see some simple udev code, check out mdev
it's way better documented then udev
it makes nodes, bout initial and hotplugged
it loads firmware
it can execute things on add command (says so, didn't look up the code that does it)
it exits when it does its job
some other thing
what it does not do is:
load modules (the lookup modules.alias then modprobe thing) so you would have to add them yourself at boot
persistent naming (gentoo people have a script for that)
note that hard drives have persistent names since their ordering is done by bios/uefi, so it's a network interface nr. problem
keyboard mapping, that i didn't know udev did (not layout)
some xorg input configuration, that i also didn't know udev did (idk if it is needed)
maybe niece race conditions since it uses /proc/sys/kernel/hotplug instead of the netlink interface
(like if you unplug something while the initial scan is going; shouldn't be a problem after it's done)

it is less then 1k lines of C, out of what a third is comments
most of the code is patching text together

what i'l do one sunny day will probably end up very similar just uglier and less commented
thinking about it now just adding module loading and persistent naming to mdev would make almost complete udev
(probably some extra checking code for that rare race condition; or netlink and make it run constantly)

no init should supervise what a user is starting
afaik console-kit is run as a privileged user and is started by a desktop manager
a "tracking init" would follow all forks and execs
good point, you can make it stop tracing when something is executed as a user

there arn't that many things that just need to be run once
mounting, setting kernel state, making device nodes, loading extra modules, in one case the network and.. idk
basically most daemons need a "core" set (drives being mounted, device nodes) and maybe networking

ptrace is very powerful but needs more knowledge then just boxing in cgroups
adding more logic beyond the basic ptrace loop would allow to catch misbehaving processes (like fork bombs)
basically, its fun

PS suse, i think, have made a framework based on ptrace
edit: yes

Isn't there a project called smdev?

y
even shorter then mdev
but, as far as i see, doesn't do firmware or execute things

What would be needed to supplement the missing portions of mdev? Could we revive older projects to handle firmware and such like hotplug for example?

firmware is handled by the kernel in almost all cases (i think it is written in the modules themselves)
mdev already handles cases that the kernel does not
those cases the kernel does not handle for security and/or licensing reasons

modules however... example hotplug event (over netlink, other hotplug sends the same data over env variables)
the MODALIAS string, in this case usb:v0BDAp8187d0100dc00dsc00dp00ic00isc00ip00in00
needs to be matched to strings in /lib/modules/`uname -r`/modules.alias (including regex)
it matches the string in line 4128 that says "alias usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip*in* rtl8187"
where rtl8187 is the module that the device needs

note there are multiple events for every part of the device

for the initial sweep when first started the modalias string is in a file called modalias withing the /sys filesystem
in this case that would be something like:
v=vendor
p=product
rest, i didn't check the meaning (http://unix.stackexchange.com/questi...numeric-values)

i think that is the old path and that mdev and udev use a different one (/sys/class/ one)
to explain all those numbers in the path; they represent physical connections from the cpu to the device
in this case 0000:00:09.0 is my PCI bridge, 0000:03:00.0 is an USB controller (checked via lspci)
the rest... idk, usb is complicated (a network protocol none the less)
lsusb shows Bus 003 Device 003 (funny it also gives device id's ID 0bda:8187)

so mdev just needs to do that while it is scanning /sys/class and when it is receiving events

persistent naming also similar
device has a specific name (can't remember, it's somewhere in /sys/class)
formatting used would be whatever
"alias ID NAME" would be fine i guess (i forgot how udev defines it for itself, if i knew at all)
maybe something more human readable to be easily modified if needed or idk


PS sorry for offtopic

edit, unrelated to modules;
hotplug events also give MAJOR= and MINOR= numbers, that are used by mknod to make the actual nodes in /dev
same is written in a "dev" file in /sys/class/somewhere and devices can have multiple of those, like buttons on a mouse for example

another edit:
i found modprobe also accepts modaliases, so this works:
modprobe usb:v0BDAp8187d0100dc00dsc00dp00ic00isc00ip00in00
makes sense actually
i guess that the whole of udev could then be written in a shell script
hmm