View previous topic :: View next topic |
systemd or openrc - which one do you use? |
systemd |
|
15% |
[ 22 ] |
openrc |
|
81% |
[ 117 ] |
other, say which in the comments below |
|
3% |
[ 5 ] |
|
Total Votes : 144 |
|
Author |
Message |
Gatsby Tux's lil' helper
Joined: 18 Jan 2010 Posts: 116 Location: 127.0.0.1
|
Posted: Thu Jan 01, 2015 4:41 pm Post subject: |
|
|
OpenRC.. of course. _________________ Γνωθι σεαυτον. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Thu Jan 01, 2015 11:08 pm Post subject: |
|
|
khayyam wrote: | John R. Graham wrote: | So, I would love to see a re-imagining of the userland dev tree management system concept with a more approachable scripting language at its core. |
John ... mdev perhaps? ... no particular language required. | Hi, Khay. I think you're missing the point. udev and eudev don't require any particular language either; in my opinion, to their detriment. With a properly integrated embedded language, writing rules would be easier.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Fri Jan 02, 2015 1:17 pm Post subject: |
|
|
John R. Graham wrote: | khayyam wrote: | mdev perhaps? ... no particular language required. |
I think you're missing the point. udev and eudev don't require any particular language either; in my opinion, to their detriment. With a properly integrated embedded language, writing rules would be easier. |
John ... yes, I probably am, but surely all that happens here is that the device manager detects the uevent and then triggers some action. So what is the particular use case for this embedded language?
best ... khay |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Fri Jan 02, 2015 5:10 pm Post subject: |
|
|
Because it's often more complicated than that. An embedded language would assist, in my opinion, in two different ways:- The trigger condition establishment today is basically involves manual initialization of entries in a state table. An embedded extension language would make this simpler, more readable, and allow for reasonable defaults.
- The taking action part would be where the extension language would shine. Right now, even simple establishment of names often requires the execution of external helper applications (e.g., /sbin/blkid). Furthermore, the current rules definition language itself is a nightmare. The lack of documentation is really not relevant, but certainly exacerbates the abstruse nature of the current language syntax.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
stephan-t Tux's lil' helper
Joined: 12 May 2014 Posts: 122
|
Posted: Fri Jan 02, 2015 8:13 pm Post subject: |
|
|
I moved from Systemd to OpenRC, not really like the new way that's like Systemd do. Am not to old but love oldschool thing, maybe someday again will advanture with D. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3509
|
Posted: Fri Jan 02, 2015 9:39 pm Post subject: |
|
|
John R. Graham wrote: | Because it's often more complicated than that. An embedded language would assist, in my opinion, in two different ways: |
I've made up a pet quote, "Every 'simple language' aspires to Turing completeness." New attempts at configuration syntax or whatever eschew shell as being too complex. Then when they hit the real world, this or that situation isn't covered, and features are added to handle it. Eventually some sort of loop creeps in, and some sort of conditional, sometimes at the same time in the same construct. Eventually it becomes Turing complete, and very messily at that.
Heck, a few decades ago I used Script/VS - a text markup language that became Turing complete.
You're better off admitting that that's where you're headed, and just do it right. That often means just using a Posix shell.
It also makes me want to learn Lua. From what I understand, it's designed to be Turing complete - and embedded.
EDIT - cleaned up spelling and composition - a little. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Jan 03, 2015 1:16 pm Post subject: |
|
|
@jrg: I think you missed my post on previous page? Would be nice to see what kind of thing you actually want. |
|
Back to top |
|
|
mrbassie l33t
Joined: 31 May 2013 Posts: 772 Location: over here
|
Posted: Wed Jan 07, 2015 6:36 pm Post subject: |
|
|
I use openrc. I gave systemd a brief go before I came to Gentoo and a brief go afterwards. It wasn't the huge increase in startup times it was touted to be, networking broke, these odd feeling *ctl commands were a real turnoff. So I didn't try very hard to get it to work either time. What would be the point? It failed at it's main 'selling point', felt very alien to me and so why bother with the hassle?
What do these people love about it so much? |
|
Back to top |
|
|
lexflex Guru
Joined: 05 Mar 2006 Posts: 363 Location: the Netherlands
|
Posted: Wed Jan 07, 2015 9:37 pm Post subject: |
|
|
Running Gentoo now for like ten years on various systems and openrc always works the expected way.
I must admit I never tried systemd myself, but there never was any reason for me to change that.
From what I read I agree with the principle side of the discussion in favour of openrc.
Of course, if the systemd way would/could provide some advantage that could otherwise not be achieved than that might change some minds, but right now that does not seem to be the case for me.
Last edited by lexflex on Thu Jan 08, 2015 8:46 am; edited 1 time in total |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9676 Location: almost Mile High in the USA
|
Posted: Wed Jan 07, 2015 11:27 pm Post subject: |
|
|
Both. _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Jan 08, 2015 8:50 am Post subject: |
|
|
++ |
|
Back to top |
|
|
v_andal Guru
Joined: 26 Aug 2008 Posts: 541 Location: Germany
|
Posted: Fri Jan 09, 2015 12:50 pm Post subject: |
|
|
John R. Graham wrote: | Because it's often more complicated than that. An embedded language would assist, in my opinion, in two different ways:- The trigger condition establishment today is basically involves manual initialization of entries in a state table. An embedded extension language would make this simpler, more readable, and allow for reasonable defaults.
- The taking action part would be where the extension language would shine. Right now, even simple establishment of names often requires the execution of external helper applications (e.g., /sbin/blkid). Furthermore, the current rules definition language itself is a nightmare. The lack of documentation is really not relevant, but certainly exacerbates the abstruse nature of the current language syntax.
- John |
I don't know if it is of any use here, but I had to create a system for configuring and managing fairly complex server. This involved bringing up listeners, providing code for various events, setting various parameters, etc. Since I was trying to keep things very modular and simple I could extract small framework for building various things. This framework includes ability to create fairly sophisticated embedded scripting language as well as a (more or less secure) way to execute scripts remotely.
The best (for me ) is that the scripting language is self-documenting. The interpreter can produce slightly modified BNF notation for the syntax. The opcodes allow restoring of the original code. The language is built as collection of mostly independent and simple parsers (average parser is less than 200 lines of C code). So one can add or remove parsers as desired.
For the sake of example I've created simple file server that allows uploading and downloading of files, this is protected using RSA keys. The scripting language allows execution of opcodes depending on the user who signed the code. The example can be found at http://sourceforge.net/projects/vandalix/?source=directory
BTW, originally I've also tried to do configuration via pseudo-files but then came to conclusion that using remote procedure calling with embedded scripting is much more flexible and convenient. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Sat Jan 10, 2015 2:24 pm Post subject: |
|
|
Split off the vdev discussion to its own topic: Discussing vdev from Devuan Project.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
msst Apprentice
Joined: 07 Jun 2011 Posts: 259
|
Posted: Tue Jan 13, 2015 8:42 pm Post subject: |
|
|
I am actually also using both systems.
On my Desktop machine Gentoo with OpenRC
On my weak Nettop with Atom processor archlinux with systemd (compiling on that machine is a pain)
And I have to say systemd is ok, but only if someone else does all the configuration and maintenance on it. Every time I have to deal with anything like systemdctl, journalctl etc. I almost puke. This seems to be all programmed to annoy anyone who has to deal with it. So it is only ok whle it runs completely untouched and in the standard way.
So I can understand why systemd is good for a standard binary distro, where you do not want to customize much. For gentoo it would be a disaster. |
|
Back to top |
|
|
bstaletic Apprentice
Joined: 05 Apr 2014 Posts: 249
|
Posted: Wed Jan 14, 2015 5:34 pm Post subject: |
|
|
Neither,
Was using systemd with Arch but when I saw the monstrosity systemd will soon become I started to search for an alternative. So i turned to gentoo and openrc, which worked great yet no as fast as systemd on arch. Then compiling has become tiresome, so I returned to arch and spent a few hours trying to set it up using sysv and openrc. Along the way I found an aur package named eudev-systemdcompat. The package provides systemd-217 but only to satisfy dependancies, there's no way to run anything systemd related. That package made the transition pretty smooth. Again a slight decrease in speed caused by swithc to openrc mad me wonder if there's more init systems which would be a reffuge from systemd and provide same performance. That's when I stumbled upon epoch, which is somewhere between the two in every way (not counting systemd's intrusiveness). I wont go into describing epoch.
When I say performance I mean boot speed and starting of services, not overall system performance which can't be affected by just init. |
|
Back to top |
|
|
stephan-t Tux's lil' helper
Joined: 12 May 2014 Posts: 122
|
Posted: Wed Jan 14, 2015 7:47 pm Post subject: |
|
|
bstaletic wrote: | Neither,
Was using systemd with Arch but when I saw the monstrosity systemd will soon become I started to search for an alternative. So i turned to gentoo and openrc, which worked great yet no as fast as systemd on arch. Then compiling has become tiresome, so I returned to arch and spent a few hours trying to set it up using sysv and openrc. Along the way I found an aur package named eudev-systemdcompat. The package provides systemd-217 but only to satisfy dependancies, there's no way to run anything systemd related. That package made the transition pretty smooth. Again a slight decrease in speed caused by swithc to openrc mad me wonder if there's more init systems which would be a reffuge from systemd and provide same performance. That's when I stumbled upon epoch, which is somewhere between the two in every way (not counting systemd's intrusiveness). I wont go into describing epoch.
When I say performance I mean boot speed and starting of services, not overall system performance which can't be affected by just init. |
The Openrc and eudev not same as when you use in Gentoo. eudev-systemdcompat contain sysmtemd library like libsystemd and forked version of udev under lib. Just a layer, but yes this is the chance to use another init system in Arch.
Compile is hell of pain but Gentoo flexibility and liberaty awesome thing. This is pull out from 4 year Archlinux uses.
Talking about the topic: Systemd growing to freaking init system who implent many old good developments.
Just see the fresh post on Phoronix and I laugh it, called the new services plan.
Skyrocketd the name remind me the Rocket Raccoon |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54211 Location: 56N 3W
|
Posted: Wed Jan 14, 2015 8:13 pm Post subject: |
|
|
stephan-t,
Quote: | ...called the new services plan |
Its the same as the old services plan, you pay lots of money, you get some service ... maybe.
Perhaps they just document your bug and call it a feature, like binary log corruption.
The new bit is that this plan comes with vendor lock in, like with Microsoft and the whole "Workstation" market before microprocessors.
Younger readers, say younger than 60, need to read the History Lesson.
Microsoft and Red Hat investors need to be afraid ...
OK its a deliberate misqute :) but we don't have a misquote tag. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Jan 15, 2015 6:37 am Post subject: |
|
|
bstaletic wrote: | openrc, which worked great yet no as fast as systemd |
Did you try with /bin/sh symlnked to dash? It's bash which is the "speed killer" of openrc, and with dash openrc is faster than systemd, here (tested on i3, core2, athlon, and pentium3 machines; maybe it is different on i5 or i7 where parallel starting might really gain you something). |
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Thu Jan 15, 2015 7:22 am Post subject: |
|
|
mv wrote: | bstaletic wrote: | openrc, which worked great yet no as fast as systemd |
Did you try with /bin/sh symlnked to dash? It's bash which is the "speed killer" of openrc, and with dash openrc is faster than systemd, here (tested on i3, core2, athlon, and pentium3 machines; maybe it is different on i5 or i7 where parallel starting might really gain you something). | Use an SSD and Openrc with parallel turned on and you will get to the log in prompt faster than the screen can adjust its resolution. At least, as long as you don't enable some slow stuff on boot (NFS, I think I don't have that box in front of me). Good hardware really makes the point moot.
(Yes, this would be with an i7) _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
bstaletic Apprentice
Joined: 05 Apr 2014 Posts: 249
|
Posted: Thu Jan 15, 2015 11:50 am Post subject: |
|
|
I have not tried dash with openrc, butI have tried dash with systemd. There's been no noticable gain and I just realized it's probably because systemd doesn't rely on bash much (if at all). Maybe I'll try again it in a few days. |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2034 Location: United Kingdom
|
Posted: Thu Jan 15, 2015 3:48 pm Post subject: |
|
|
On Wed Dec 31, 2014 9:40 pm Fitzcarraldo wrote: | OpenRC. No complaints at all. |
I thought this poll was about Gentoo specifically, which is why I posted as I did. However, I see that a couple of people have mentioned another distribution. In that case, I use OpenRC in Gentoo, but systemd in Sabayon (the only possibility in that distribution these days). _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
Back to top |
|
|
|