Nobody wants to go back to HAL.Quote:
Originally Posted by boast
We were all happy with udev and it worked really nice.
But now they're trying to force systemd to be a dependency of udev I heard.
And they develop it in the same branch and stuff.
Printable View
Nobody wants to go back to HAL.Quote:
Originally Posted by boast
We were all happy with udev and it worked really nice.
But now they're trying to force systemd to be a dependency of udev I heard.
And they develop it in the same branch and stuff.
Read literally any of my posts in this threadQuote:
Originally Posted by uid313
You are right in that the udev takeover did not mean immediate breakage for non-systemd systems, but you will also understand that maintainers of such systems do not like sitting on a ticking bomb at the mercy of a hostile developer, right?Quote:
Originally Posted by Ericg
Of course not, but Lennart also clarified afterwards that support for non-systemd+udev would only end once once there werent any real non-systemd systems left.Quote:
Originally Posted by pingufunkybeat
Major distros who are using SysV?
Gentoo, Slackware, Debian (Im leaving RHEL + its clones out of this because RHEL7 uses systemd)
Major distros using Upstart?
Ubuntu, (+derivatives, but basically Ubuntu.)
Everyone else? systemd
Debian wants to be able to swap out kernels so theyre stuck with sysV. If and when systemd removes non-systemd support from udev they'll probably switch to eudev.
Gentoo lets you swap out components anyway. The users who want to use systemd will use mainline udev. The users who dont want systemd will use eudev.
Slackware.... who the hell knows what those guys will do.
Ubuntu...I really hope will adopt systemd but I'm not holding my breath. They're basically in the same boat as debian/gentoo. If they dont want to use systemd they'll use eudev, if they do want to use systemd then its a non-issue.
Udev is officially promoted as an userspace part of the Linux kernel. Anybody using Linux, therefore, has to use udev, or needs to otherwise replace it with something equivalent, which is both (a) not supported and (b) nearly impossible to do while maintaining feature parity with the official udev implementation, especially considering that udev is constantly changing together with the kernel.Quote:
Originally Posted by Ericg
If you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd. Since there is a non-empty set of people who are interested in running Linux without running systemd (full disclosure: I'm one of them), it was no surprise that when udev and systemd were merged some voices were heard of people fearing that they would be pushed into using systemd.
On that occasion udev and systemd developers reassured everybody thay "nothing would change", as it was merely a matter of "sharing code". It turned out that no, in fact things would change, as udev changed in an incompatible way when it was merged; another change was that now you have to build the full systemd package in order to obtain the udev binary (which also changes name into "systemd-udev", and gets moved to another location upon installation) and manually rip it out of the built package. Building the systemd package has many more requirements than udev, and some of them can't be cleanly cross-compiled (just one of them: Python). Not to mention the fact that installing udev changed from a matter of "configure / make / make install" into a much more complicated job. Patches to allow udev to be built separately from systemd were rejected.
The blog post says that people are free not to use systemd because "free software isn't Mafia" ; well, the reader will decide what kind of behaviour it is to push people into using systemd by making their life noticeably harder if they don't.
Anyway, after we discovered that, unlike was promised, things would indeed change for non-systemd users of udev, we finally got an official announcement by the systemd lead developer stating that they dislike having to support non-systemd users, and that they look forward to the day when they'll get rid of the "inconvenience".
Now, it doesn't matter if his dreams of Linux domination will become true in 2013, in 2014 or in 2020. This statement is of extreme importance now, because:
(1) the use of udev is for all practical purposes required in order to fully make use of the Linux kernel;
(2) the udev maintainers are claiming that they are working to stop supporting udev without systemd in a somewhat unspecified future (and, as anyone can see, in the meantime they are already behaving as if non-systemd users of udev were second-class citizens, and are publicly stating it in order for it to be well known);
from (1) and (2) we get that non-systemd users are friendly advised to either stop using the Linux kernel, or prepare themselves to develop and maintain an alternative to udev. Or, much more conveniently, switch to systemd.
No you can't. Try to do it and tell me your experience.Quote:
You can still build udev solo,
You still can, but it's a pain in the ass, which it wasn't before the udev-systemd merger, and most importantly, it's a use case with an expiration date. Which is unacceptable.Quote:
you can still use it without systemd.
Please forgive me for this rant in a systemd thread, but hearing people say that non-systemd users of Linus exaggerate or are paranoid when they say that they're being pushed into using systemd, means having insult added to the injury to me.
The really heavy obstacles in our world are beliefs:
, this a long time Gentoo advocate at:Quote:
RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", ...
https://forums.gentoo.org/viewtopic-...6.html#7229136
Therfore true Linux/Unix is: It has to just NOT work!
Otherwise it is a conspiracy ....
As a note Gentoo also supports other kernels like BSD. It also supports prefixes (mostly) and a number of other crazy setups. so add gentoo to debian in the first comment.Quote:
Originally Posted by Ericg
Is there a supported way to build and install only udev? how about only systemd? only journal? On a gentoo system all three will be seperate compiles and installs. Having to always build all three will make it take longer to install, require more disk space, and generally be annoying.
On to systemd questions; Can I write my own init file in plaintext with gvim for systemd? Is there documentation on how to build these. I like the well documented gentoo setup for this reason. It's very easy to write one if i want to, and I have in the past.
May be you shouldn't rip that quote out of context, so that you can present the actual meaning, which is quite different from your conclusion:Quote:
Originally Posted by ulenrich
Quote:
Oddly enough the clueless noob who doesn't configure anything will be better off, because he/she won't have things like "config_eth0=..." sitting anywhere to become stale.
RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", except when it doesn't, then abandon all hope, because we're removed, hidden, obscured, or obfuscated the knobs that allow you to make it work. Your choices are to be a complete clueless noob, or to become a near-developer - the self-educated hacker is out of luck.
Building stock systemd pulls in hard dependencies on udev, and journal and by default pulls in some of the things I mentioned in an earlier post, along with others. The only things you HAVE to build when you build systemd is systemd, udev and journal, all else is optional. (Hostname / timezone / hardware clock / cron / etc)Quote:
Originally Posted by cynyr
Journal depends on systemd so they cannot be decoupled.
Udev CAN be decoupled from systemd the only weird thing is you have to pull in all of the systemd sources to do it since they are in the same tree. So you get ALL of the systemd sources but when you actually compile it, you can tell it "I only want udev to be compiled" and when its done, you'll only have udev.*
I'm ASSUMING (Correct me if im wrong) when you say "init file" you mean the files that typically resided in /etc/init.d/ or gentoo equiv, correct? (Arch's equiv was /etc/rc.d/)Quote:
Originally Posted by cynyr
in the systemd world those are called ".service" files. And yes they are written in plaintext.
The defaults (distro package provided ones) are stored in /usr/lib/systemd/system/
If you want to modify or override anything provided by the distro then you place them /etc/systemd/systemctl and they will take priority over the ones in /usr/lib. Packages supply their own .service files, systemd does not provide them itself.
the Arch wiki has a great section where some non-default .service files are done for programs that dont have a native systemd service file: https://wiki.archlinux.org/index.php/Systemd/Services
Below this is a shortrun through an example .service file since I got the impression you hadnt looked at one before. if you have, sorry >_> but its a good read for anyone else who has not since they are so simple.
Description: is what appears when someone looks at the daemon through systemctl (systemctl status adsuck)Quote:
[Unit]
Description=Adsuck daemon
After=network.target
[Service]
Type=forking
ExecStart=/usr/sbin/adsuck -l 127.0.0.1 -c /var/adsuck -f /resolv.conf /hosts -r /filter
ExecStartPost=/bin/sh -c "echo 'nameserver 127.0.0.1' > /etc/resolv.conf"
ExecStop=/bin/kill $MAINPID
ExecStopPost=/bin/sh -c "cp /var/adsuck/resolv.conf /etc/resolv.conf"
ExecReload=/bin/kill -HUP $MAINPID ; /bin/kill -USR1 $MAINPID
[Install]
WantedBy=multi-user.target
After: Tells systemd to only start this after the network has been started (not necessarily established, but just the daemon responsible for the network has been successfully start
Type: tells systemd what to watch for. in the sysV world a process can be lost if it double-forks, thereby seperating it from its parent process. In the systemd world that isnt allowed. They can still fork as many times as they want, but systemd will always know where it is and what its process tree (including parent) looks like
ExecStart: tells systemd what command to run when the service file is passed "start" (systemctl start adsuck)
ExecStartPost: tells systemd what commands to run AFTER the service has been successfully started.
ExecStop: tells systemd what commands to run when the service is passed the "stop" command (systemctl stop adsuck)
ExecStopPost: tells systemd what commands to run when the service reports a clean exit. Eg: cleanup commands.
ExecReload: tells systemd what to do in the event the service wants to be stopped and then restarted immediately (systemctl restart adsuck)
WantedBy: tells systemd what level in the init tree this should go into. Systemd has a concept of runlevels, they jsut aren't called that.
single-user.target is runlevel 1 from sysV
mutli-user.target is runlevel 3 from sysV
graphical.target is runlevel 5 from sysV
reboot.target is runlevel 7(?) from sysV
Graphical.target pulls in anything linked against multi-user.target which in turn pulls in anything linked against single-user.target. The rule of thing is lowest level necessary. Adsuck is a network daemon and doesnt have or atleast does not require a GUI, therefore it goes against multi-user.target. But kdm or gdm DO require a gui so they go against graphical.target
And so ends what was probably my longest post on these forums, ever XD
Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.Quote:
Originally Posted by Ericg
Yep that is what I mean.Quote:
Originally Posted by Ericg
Nope I haven't looked at them at all, all my computers boot great (mostly) right now, and mucking with semi-supported inits isn't all that interesting on live systems, and low priority for playing with in a VM.Quote:
Originally Posted by Ericg
One of the things I really like in gentoo is the pre_up and post_up functions for the networking init scripts. This allows things like setting up ssh tunnels when not on a particular wifi network, or setting link speeds before trying to get an IP address (to work around a busted network card I had at one point). It looks like execstartpost exists, and I'll assume that a execstartpre also does.
poking around arch's wiki for systemd I stumbled into another question, is there a way to read the log for a computer that I have a non-bootable system on? Normally I'd yank the HDD and mount the drive, and read /var/log/messages however I like. even if there was some minor corruption of that file it's likely something could still be read.
TBH I have a bit of knee jerk reaction to LPs stuff and have a tenancy to let it settle out for a while before I even try it out. For the most part it seems like LP lifted some of the things I like from openRC and added a few more interesting looking things the inherent directive or .path services for example. However a lot of the stuff sunning on my server seems like I would need to write .service files for at this point in time, like mediatomb and lighttpd. Though those may be provided by systemd itself.
Maybe one of these day I'll get around to playing with it in a VM.