You are not logged in.
Stop whining about KISS/Arch way because many of you obviously don't get it.
Offline
masteryod wrote:PS Only one complain: please, please can we get blue'ish [ OK ] notifications instead of green'ish?
I made a patch for this. If you want to abs it in or vote on the bug report, it's here: https://bugs.archlinux.org/task/31245
Reason for closing: Won't implement
Additional comments about closing: Figure out a way to get upstream to accept this as a configurable. I'm not applying random cosmetic patches to systemd.
That's why I love Arch - technological sanity. OK people, try to push this upstream: https://bugs.freedesktop.org/show_bug.cgi?id=53937
Last edited by masteryod (2012-08-22 14:41:51)
Offline
masteryod wrote:Stop whining about KISS/Arch way because many of you obviously don't get it.
I moved to systemd the other day and not only was the move flawless (aside from slight retardation getting in the way), I've moved the extra (oh noes!!) config files to my openbox menu and everything is great. I don't fully understand all the intricate details, but this seems like a big fuss over pointless semantics (read Asperger's(not trying to be offensive)) to me.
I trust the Devs understand what they are doing, that is enough for me. Keep up the good work
"No sympathy for the devil. If you buy the ticket, take the ride."
- Hunter S. Thompson
Offline
Somehow I don't think upstream will make this configurable, they'll likely argue that it's the distribution's responsibility to handle the cosmetic changes, but I +1'd your bug report anyway.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
but this seems like a big fuss over pointless semantics (read Asperger's(not trying to be offensive)) to me.
I agree, there's no real functional difference between having to type something like rc.d start service (or /etc/init.d/service start) and systemctl start service. Listing active services is slightly more work, but it requires about as much effort as switching to another distro's init system with the added benefit that systemd is actually poised to unify init across all participating distros. So, in theory at least, using a different distro that also supports systemd will essentially be limited to learning 1) what services or service names exist on that distro and 2) package managers and other convention differences. The cool thing is that supplying systemd unit files with your software will be easier and you won't have to worry about writing various bash file using start-stop-daemon, writing various bits of logic (in bash), and so forth. This also means it'll be easier for package maintainers (at least, in theory). This is a Good Thing™.
I believe that if one were to objectively analyze resistance to systemd's adoption, it would likely be due to little more than historic inertia--e.g. the status quo (initscripts) is "easier" because it's familiar. systemd therefore is "harder" because it's different and new. From a purely administrative standpoint, systemd is easier to manage once you take the time to learn it (yes, including the units), and because systemd aggregates all init-related cruft into a single place (syslog, tmpfiles, services/daemon management), it's no longer necessary to worry all that much about maintaining so many loosely-coupled, disparate scripts and services to achieve the same goal. Certainly the code base of systemd looks more complicated (700+ LOC compared to ~100-300 for various other init systems according to Wikipedia), but in actual use it's much simpler.
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
Mod-time....
tomegun wrote:Benefits:
I have spent too much time arguing against the perceived deficiencies of systemd...
Blah.. blah.. blah.. bottom line is that of your listed 10 bullets.. 95% of your user base does not need or care about any of them. You are taking a set of simple basic functions and turning them into one big interdependent mess of complexity.. definitely not KISS and definitely not in a good direction for any distro. In the past, every time this kind of thing is attempted, where simple is purposely made complex.. what ever the project.. it ends up never completely working right ever, which removes confidence in using the system. I fear this is where arch is headed.. time to bail.
Learn to post please. Productive criticisms are welcome. Rants of this type aren't. If you're bailing, good for you, don't let the door hit you on the way out. If you want to stay, learn some manners.
How i converted to systemd
-- blog link mod-removed by ngoonee - don't do that --
Please don't post links to your blog et. al., that violates the Forum Etiquette on the issue. Removed.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
tomegun your post was brilliant and informative, thanks so much.
I've already converted my Arch install to systemd (once again, because of the brilliant Arch Wiki) and besides an occasional hang on reboot (after unmounting filesystems, I get the feeling this is my own error somewhere, will be easy to fix I'm sure) it works absolutely perfectly. I can't wait to get it handling my automounts instead of AutoFS and taking over from ConsoleKit etc.
I wasn't too sure of systemd before with all the conflicting information and flamewars around the internet, but if the Arch Developers (who believe so strongly in the KISS/Arch Way) believe it to be the future and find it to be very beneficial, I'll trust them.
Arch Linux - Intel E5200 Desktop (MATE GTK3) | Fedora 25 - ASUS Core-i7 Optimus Laptop
Offline
The dev's may be to polite to say it - or just not give quite enough of a damn to even respond* - but I doubt they care about that 95% of the "user base". I doubt they care about the other 5% either ... and they shouldn't.
I don't want a system made by people who are making it for some hypothetical (or mythological!) user base. If I did, I'd use <insert-other-OS-name-here>. I want to use a system made by people who make it the way THEY want, because THEY use it.
I'm very happy to acknowledge my nature as a grateful parasite benefitting from the hardwork and talents of others who make something for themselves and are generous enough to share. Being a grateful parasite may not be the best title ... but it beats being an ungrateful one!
*note of clarification: they may not give enough of a damn to respond to rants like the one in question - nor should they.
Last edited by Trilby (2012-08-23 02:28:27)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
The dev's may be to polite to say it
I have never been called polite before....
Offline
Wouldn't want that.
People might expect you to start appologizing for breaking everything.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Systemd seems to be a great advancement for linux. IMO Arch should drop sysvinit support completely with the transition to systemd. It would be a waste of time if its done any other way. But although some of the developers have said it, there is resistance for no obvious reason. Yes it changes pretty much everything. Get over it. Start getting familiar with it. Approach the unknown with curiosity. For a distribution like Arch it doesnt make sense not fully switching to systemd.
Unlike Debian for example which is gonna be debating about this for a decade or so.
Some interesting reading. Lennart's reply is ace.
Full article
Debian developer mail
Lennart fights back
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
I can't wait to get it handling my automounts instead of AutoFS and taking over from ConsoleKit etc.
systemd's automount is much easier than autofs and some of the other hack-ish solutions. I'm using it for NFS on my desktop and for an HTPC, both of which bring up the NFS mounts on demand without any fuss (or lengthy boots). Try it. I think you'll be very pleasantly surprised--I was!
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
ElderSnake wrote:I can't wait to get it handling my automounts instead of AutoFS and taking over from ConsoleKit etc.
systemd's automount is much easier than autofs and some of the other hack-ish solutions. I'm using it for NFS on my desktop and for an HTPC, both of which bring up the NFS mounts on demand without any fuss (or lengthy boots). Try it. I think you'll be very pleasantly surprised--I was!
Thank you, you're absolutely right. I re-added my Samba shares to fstab with the systemd option switch and got rid of autofs... and it just works perfectly. The shares even seem to be faster to access and quieter (as in my shared external HDD isn't working as hard). I don't know if that's actually possible but it's definitely a smoother and seamless experience. Plus one could argue the way systemd uses fstab as opposed to separate methods like autofs is more KISS anyway.
Arch Linux - Intel E5200 Desktop (MATE GTK3) | Fedora 25 - ASUS Core-i7 Optimus Laptop
Offline
ElderSnake wrote:I can't wait to get it handling my automounts instead of AutoFS and taking over from ConsoleKit etc.
systemd's automount is much easier than autofs and some of the other hack-ish solutions. I'm using it for NFS on my desktop and for an HTPC, both of which bring up the NFS mounts on demand without any fuss (or lengthy boots). Try it. I think you'll be very pleasantly surprised--I was!
Yes this will probably be a cause of discussions for the next decade or so; systemd does go against the unix-philosophy here and there, but when it does it actually works much better and more seamless than pre-exisiting solutions. So who knows, perhaps the philosopical implications of systemd might be even more profound than the practical ones, interesting times ahead!
ᶘ ᵒᴥᵒᶅ
Offline
Friendly mod-reminder, just as much as rants are not appreciated, fanboy posts aren't either, so keep the 'systemd is awesome' stuff for your blogs please.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
This is the way to go - I've converted both my arches to systemd.
Systemd is easy - logically. If you just get your brain around it (and not only your keyboard, which I fear is what most computer-of-any-kind-user does recently), then you'll see why you get *.service, *.socket, *.device and what a unit generally is. Plus you'll see why it's easy to work with, and why your computer boots up in 5 seconds (mine does, - the grub part). With the recent libc update, I've even posted something very much disfavouring the changes, ie reducing the importance of rc.conf etc. However, systemd is a good way to go. The devs make a very sane decision, and it's obvious that the decision will meet resistance.
Only thing I'd like clarification on - how does one go about writing your own unit? I've dug around /usr/lib/systemd/system, and it appears that those are no oridinary scripts. Since I'm also a fresh user of systemd, I might not see all the intricacies of the software. Any help appreciated.
Last edited by piotroxp (2012-08-25 06:09:40)
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
See "man systemd.unit" and "man systemd.service" (or .socket, .mount, etc.). Save custom unit files to /etc/systemd/system/.
If there's a currently existing unit file that you want to use as a basis/modify, copy it to the aforementioned location.
e.g.
cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/alt-httpd.service
Any changes you make to the /usr/lib files will be lost when you upgrade systemd.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
You don't even have to rename it when you copy it - files in /etc/... override those in /usr/..., and the command systemd-delta will show what's redirected/overridden and the differences of the files:
└$ systemd-delta
[OVERRIDDEN] /etc/systemd/system/smbd.service → /usr/lib/systemd/system/smbd.service
--- /usr/lib/systemd/system/smbd.service 2012-08-07 06:26:44.000000000 -0400
+++ /etc/systemd/system/smbd.service 2012-08-25 03:19:54.066948347 -0400
@@ -1,5 +1,5 @@
[Unit]
-Description=Samba SMB/CIFS server
+Description=Changed for demonstration purposes
[Service]
ExecStart=/usr/sbin/smbd -F
1 overridden configuration files found.
Offline
Blah.. blah.. blah.. bottom line is that of your listed 10 bullets.. 95% of your user base does not need or care about any of them. You are taking a set of simple basic functions and turning them into one big interdependent mess of complexity.. definitely not KISS and definitely not in a good direction for any distro. In the past, every time this kind of thing is attempted, where simple is purposely made complex.. what ever the project.. it ends up never completely working right ever, which removes confidence in using the system. I fear this is where arch is headed.. time to bail.
Yeah, 95% of systemd user base don't have to care about things Tomegun posted, because it's systemd that cares about them! The only thing you have said is NOTHING. sysvinit is as good as dead. Complex, slow and irritating bash written mess unsuitable for modern systems like Linux. systemd will bring Arch Linux into next level, because it will simplify a lot of things and your user base will grow a lot.
Offline
Yeah, 95% of systemd user base don't have to care about things Tomegun posted, because it's systemd that cares about them! The only thing you have said is NOTHING. sysvinit is as good as dead. Complex, slow and irritating bash written mess unsuitable for modern systems like Linux. systemd will bring Arch Linux into next level, because it will simplify a lot of things and your user base will grow a lot.
The funny thing is that you got me thinking about how the one thing I'll miss about initscripts is the ability to easily modify any of the start up files. But then, I also remembered that if you have to modify the most basic initscripts to get your system to boot, there's fundamentally something very wrong with your install, and you have other, much more serious issues.
Personally, systemd has simplified quite a lot for me, even migrating to a more "pure" setup without rc.local (e.g. using tmpfiles to inject values into /proc, for instance, like with lirc) make a bit more sense than stuffing shell commands into another file. But these days, I don't really want to be bothered or worried about the init process. I just want the system to boot so I can use it, and I see systemd as simplifying a means to that end. I realize there are those who will strongly disagree, who believe that shell scripts were far simpler, but from an administrative vantage point--are they really? If you've ever used more than three distros and one or more of the *BSDs, you'll know the answer to this. Knowledge of /bin/sh (or similar) is transferable, but when init is considered, almost everyone has their own idea of what "transferable" means.
Apologies for waxing optimistic, but I sincerely hope that systemd adoption will, over time, alleviate many of the issues with disparate init systems and help unify Linux distros in some manner, making it far less work on package maintainers whenever getting a service started is required (or heck, even upstream can take on that responsibility). Others, like Upstart, seem promising too, but I don't know enough about them to pass judgement. However, it does show that, independently at least, many major distributions are beginning to migrate away from good ol' sysvinit. It's been fun, it has served well, but I think it's time to put it to rest.
Last edited by Zancarius (2012-08-25 20:24:26)
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
Could someone give a briefing on what changes should be done as more packages move to systemd??
Ie i read that hibernate and suspend will depend on systemd so is there something that must be done prior to this if for example you suspend various modules with SUSPEND_MODULES= ??
Or any other info of that kind. Things that need to be taken care of in a way.
Offline
Ie i read that hibernate and suspend will depend on systemd so is there something that must be done prior to this if for example you suspend various modules with SUSPEND_MODULES= ??
SUSPEND_MODULES is something you would have to work around with a custom sleep hook (modprobe/rmmod): https://wiki.archlinux.org/index.php/Sy … leep_hooks
You may also check if SUSPEND_MODULES is still necessary on your setup. Afaik this is almost exclusively used to workaround bugs in the kernel which may have been fixed by now (which is probably the reason systemd doesn't implement something similiar ).
Offline
What I've noticed mostly is how fast shutdown/reboot speed is. Its barely a couple seconds or so.
I hope this is safe (disk wise) but I suppose it must be if it's implemented so. Other distros running systemd, such as Fedora seem to behave mostly the same.
Arch Linux - Intel E5200 Desktop (MATE GTK3) | Fedora 25 - ASUS Core-i7 Optimus Laptop
Offline
What I've noticed mostly is how fast shutdown/reboot speed is. Its barely a couple seconds or so.
I noticed this on my systemd installs as well. I don't even have time to read any of the messages at poweroff; they flash by and then the machine is off.
Offline
89c51 wrote:Ie i read that hibernate and suspend will depend on systemd so is there something that must be done prior to this if for example you suspend various modules with SUSPEND_MODULES= ??
SUSPEND_MODULES is something you would have to work around with a custom sleep hook (modprobe/rmmod): https://wiki.archlinux.org/index.php/Sy … leep_hooks
You may also check if SUSPEND_MODULES is still necessary on your setup. Afaik this is almost exclusively used to workaround bugs in the kernel which may have been fixed by now (which is probably the reason systemd doesn't implement something similiar ).
Thanks. I ll test it with 3.5. There are some stuff i don't like in the logs related to USB. Hopefully they'll be fixed.
Offline