Uselessd - stripped version of systemd
Quote:
A valid alternative for slackware? |
|
Interesting. I trust Patrick to make decisions about Slackware.
|
Quote:
Quote:
On the other hand, if in the future Slackware has to ship something looking like systemd (most probably then because upstream developers of desktops would make that a requirement for future versions), we would need other components than that just the init sub system to be replaced, and all the parts will have to fit together - which is at the core of our BDFL's effort, I guess ;) In any case this project will need a few years to mature and the situation will have changed then. Conclusion: wait and see. |
Needs more frop
Quote:
caused by overheating of the attention gland. This dense packing of brain cells without proper organic coolants, such as frop [...] |
|
Already an existing topic:
http://www.linuxquestions.org/questi...rg-4175519475/ I have mixed feelings on it as my other reply states. Yes, journald's exoticism was pivotal, but they removed logind which is being used by the systemd-shim projects in both GNU/Linux and the BSDs. So not the best maneuver, plus the website fringes on blatant insult humor rather than being one of seriousness. It's a serious project granted, but it's masked in such as abstractness, you'd think it was just a joke. I'm actually seconding Didier's comment: "Wait and see." But in my opinion, more seriousness could have been a better approach. However, I do admire his stance about Distribution maintainers getting a bad case of laziness. |
First of all, kudos for funny :) The systemd "discussion" often lacks humor.
Presently, it has 2 or 3 deal-breakers for me on alt distros I have that use systemd. BUT, it is perhaps an interesting "proof of concept". |
It concept is sound. Strip it down to the bare essentials and go back to the bazaar methodology.
The author has many sound concepts as well once you get past that ghastly opening statement. It really rips at a lot people for various reasons, but once you read on, you find that nothing listed is based in any bias. |
It would seem to be of no benefit to Slackware, since it only provides init and we already have a nicely working init.
What Slackware is lacking is reliable and well maintained alternatives to the non-init parts of systemd (logind, udev, etc.). Many components already depend on them (and likely more in the future). This is where the problem lies, so from a Slackware perspective uselessd is exactly that, useless. |
Well, I'll say one thing about uselessd: reading over its intro page has been far more informative and succinct about what systemd contains than any hot-headed blog post I have seen anywhere else on the 'net.
I am still unclear about the real advantages of systemd. I get that it is super advanced and nifty, and I do use it on some spare boxen, but honestly as a user I have not ever looked at Slack's init system and felt that it was insufficient for anything I ever do. And I don't think I'm a light user of my computers; I use them, I use 'em hard. And Slack's init system works. So, no rush for me to get to systemd, nor to a replacement for systemd. Even so, the existance of uselessd is nice to know about. Open source. Kinda neat that way. |
Quote:
Other important point, most framework depend or will depend on systemd (including KDE). Knowing this makes me wonder if a bloated free version of systemd does not have its merits. |
Quote:
edit: I've just read the comments: it seems systembsd is quite BSD-specific, so it needs to be ported to Linux. There was also some talk of porting it to a minimal busybox-like system, stripping out glib. |
Quote:
In summary we don't yet know if we can rely on the various alternatives to provide all that is needed and in addition, that the various projects will continue to be well maintained. More work is required followed by a leap of faith that these are better than just taking on systemd, warts and all. Quote:
So it has merit only if you want a new init for its own sake and as far as I can tell, the answer is that Pat doesn't want a new init. He has almost said this when ReaperX7 once suggested considering OpenRC instead of systemd. Quote:
This is most likely to happen because of the non init parts of systemd. Leaving two possible scenarios in my eyes. We use replacements for the other systemd components in conjunction with the current init, or we switch to systemd. Alternative inits such as OpenRC, Runit, uselessd, etc. are pure fantasy and are not looking likely any time soon. P.S. All these posts and no ranting and raving thus far. Best systemd thread we have ever had on the Slackware forums. Or am I pushing my luck saying this out loud? ;) |
For udev, there is eudev.
And for me the slackware init, which as I understand it is actually a bit of a sysv/bsd hybrid, is still doing the job just fine, and I am not a fan of fixing what is not broken. That said, if there is a need for a change going forward, I rather like the init posted here (near the bottom in a blockquote.) |
Quote:
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. |
Quote:
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! |
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. |
Quote:
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. |
Quote:
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. |
Quote:
|
Quote:
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. |
Quote:
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) |
Quote:
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) Code:
add@/devices/pci0000:00/0000:00:09.0/0000:03:00.0/usb3/3-2/3-2:1.0 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: Code:
bash-4.2# cat /sys/bus/pci/devices/0000\:00\:09.0/0000\:03\:00.0/usb3/3-2/3-2\:1.0/modalias 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 |
I'm now thinking this uselessd is just a joke. I mean, the whole site is set up as a joke, it doesn't all add up. It's probably exactly what the title says "useless".
|
It's pronounced as "use less d", not "useless d".
|
It's both. It's useless in that nobody wants or needs it (especially on FreeBSD or any BSD at all), and it uses less in regards to systemd's full functionality. From the website:
Quote:
|
Useless because it reduplicates about a half dozen init systems yet again, and use less because it offers the systemd init method, but without all the unwanted toys.
|
All times are GMT -5. The time now is 04:38 AM. |