Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Systemd headsup of L.P. - reads like at first of april
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sat Oct 26, 2013 9:12 pm    Post subject: Reply with quote

mv wrote:
Mask the networkmanager unit and write a script which is able to start networkmanager based on a dynamic configuration.


Why would you write something that is implemented in NetworkManager?

mv wrote:
Mask the encryption unit(s) and write a script which is able to start encryption support based on a dynamic configuration.


Yes, that's the same as you would do with OpenRC; unless, well, there is a service to do this for you. The border between a script and a service gets small here; so, which one you end up choosing doesn't matter...

mv wrote:
Mask the loading of modules somehow (BTW: not even possible with systemd) and write a script which is able to load the modules based on a dynamic configuration.


Why would you write a script for something that the kernel does?

mv wrote:
Switch off all the systemd and write a configurable init-system without systemd supporting you in any way.


Nothing stops you from configurable scripts in systemd; so, I don't see a reason for turning it off.

mv wrote:
As I said: The more reasonable way is to wipe systemd and use a configurable sane init-system from the very beginning (instead of writing your own init-system on top of the retarded static systemd BS).


I'd rather spend time configuring and using my computer than to unnecessarily implement things that already exist; the whole point is about not writing any init system at all, note how what I said applies just as well to OpenRC.

Separation of Concerns is an important design principle to reduce the risk of error and for saving time; as a side benefit, it also makes things easier to understand, design and manage...
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Oct 26, 2013 9:36 pm    Post subject: Reply with quote

TomWij wrote:
Well, then you could look for another service to use and configure that service to do it; these tasks you describe are tasks that should not belong in an init system. Why should something designed to start services know of the fine details of the location the user is at, touch files totally not related to itself or take the decision itself to mount a certain (encrypted) partition based on a set of rules. Of course you could easily do many of that in systemd, but why would you set up such a design that is the opposite of what most of us want from systemd (it being minimal); it's preferable to have the services do this, as their functionality is not supposed to merge into systemd.

s.systemd.openrc.g and I concur. It seems to me that systemd does "integrate" many services, so your description does not really fit it.
Quote:
If you do however want it; you can still write services that run scripts to start specific targets, or otherwise use /etc/local.d (for example, especially handy for mounting the encrypted partition).

But if you go down that road then you go back to the old days of hacking it in and giving up on the comfort that services do, can or should provide...

Personally I take this concept of "the bad old days" with a large dose of scepticism. IMO the reason people think shell is bad, is because they are bad at shell. At first they think "it's easy" and ofc it is: it's designed to make sense of user-input at a terminal. Then when they find out their scripts are full of holes, they somehow twist that into "sh is bad" instead of realising they did not know the language in the first place.

This is exacerbated by things like the == extension in "bash as sh" for string equality, so that it's even easier to pretend you're not writing shell, and rely on "muscle-memory" from other languages. When you should get slapped into line instead, so that you realise you are in shell before someone else uses your output.

So yeah, "anyone can make a distro" and "anyone can write a shell script"; that doesn't mean it's any good, nor that I'd even dream of letting it near my machine, let alone actually running as root to start critical services.

The whole point of "casual hackability" is that the admin can write shell if they choose, to do what they want or tweak things as they choose. Take that away and
a) it becomes a whole lot more boring, and
b) you cut off your developer pool, since you treat users as idiots
all the time, not just when they are actually working on something else and don't have time to concentrate on what used to be clearly-defined functionality (but hey look ma, I changed it all and it doesn't work now in a whole new way!)
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sat Oct 26, 2013 10:02 pm    Post subject: Reply with quote

steveL wrote:
s.systemd.openrc.g and I concur. It seems to me that systemd does "integrate" many services, so your description does not really fit it.


Have to confess I haven't looked into which and what exactly; but I'd hope and think, that those are what constitutes mostly the base system. In any case; despite that, they're still replaceable.

(CONFIG_PROTECT="/usr/lib/systemd/system/" goes a long way)

steveL wrote:
Personally I take this concept of "the bad old days" with a large dose of scepticism. IMO the reason people think shell is bad, is because they are bad at shell. At first they think "it's easy" and ofc it is: it's designed to make sense of user-input at a terminal. Then when they find out their scripts are full of holes, they somehow twist that into "sh is bad" instead of realising they did not know the language in the first place.

This is exacerbated by things like the == extension in "bash as sh" for string equality, so that it's even easier to pretend you're not writing shell, and rely on "muscle-memory" from other languages. When you should get slapped into line instead, so that you realise you are in shell before someone else uses your output.


Well, I started out wanting to go the POSIX route; but then looking at the Portage tree, you'll notice a lot of people use Bash and if I'm not mistaken (shoot me otherwise) our stage3 comes with Bash as a default. So well, then the "if nobody else does it, why should I" mentality kicks in. And that doesn't really mean that POSIX or Bash is either better or worse; but rather, the additional necessity to learn to write by a standard that not everyone else use is depriving. So, I think a lot of us just resort to using a tool to check for bash-isms when we need to...

Life's too short to read, understand and follow all rules to the letter; in reality, I don't think there are much people that know, understand and follow all the international, federal, state and local laws by memory.

One could argue that's a necessity to be a living human being on this planet; but well, if we just try to follow it as it fits us and our surroundings everyone will be happy... (apart for the occasional misunderstanding.)
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany

PostPosted: Sat Oct 26, 2013 10:56 pm    Post subject: Reply with quote

TomWij wrote:
Well, I started out wanting to go the POSIX route; but then looking at the Portage tree, you'll notice a lot of people use Bash and if I'm not mistaken (shoot me otherwise) our stage3 comes with Bash as a default. So well, then the "if nobody else does it, why should I" mentality kicks in. And that doesn't really mean that POSIX or Bash is either better or worse; but rather, the additional necessity to learn to write by a standard that not everyone else use is depriving.

Yeah, im pretty sure it was that kind of thinking that gave us "Optimized for Internet Explorer" websites…
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Oct 26, 2013 11:08 pm    Post subject: Reply with quote

*sigh* if you learnt bash from greycat et al, in #bash, you'd know not to bother with == in bash [[ either. Irrespective, sh is not bash, and believe me I'm fine using bash where it is appropriate. Initscripts are not one of those places, but learning to write correct sh is vital if you intend to ask others to use your work in it. I don't really see anything contentious in that, nor anything worth arguing about.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sat Oct 26, 2013 11:10 pm    Post subject: Reply with quote

Dr.Willy wrote:
TomWij wrote:
Well, I started out wanting to go the POSIX route; but then looking at the Portage tree, you'll notice a lot of people use Bash and if I'm not mistaken (shoot me otherwise) our stage3 comes with Bash as a default. So well, then the "if nobody else does it, why should I" mentality kicks in. And that doesn't really mean that POSIX or Bash is either better or worse; but rather, the additional necessity to learn to write by a standard that not everyone else use is depriving.

Yeah, im pretty sure it was that kind of thinking that gave us "Optimized for Internet Explorer" websites…

It's a metaphor that doesn't apply as long as sys-apps/portage depends on bash to process the ebuilds; because, otherwise it would be like saying every browser would be based on Internet Explorer.

And even if you get everyone to write in POSIX shell; we're just a step closer to the next level, what about other programming languages and/or standards?


Last edited by TomWij on Sat Oct 26, 2013 11:38 pm; edited 1 time in total
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sat Oct 26, 2013 11:36 pm    Post subject: Reply with quote

steveL wrote:
*sigh* if you learnt bash from greycat et al, in #bash, you'd know not to bother with == in bash [[ either. Irrespective, sh is not bash, and believe me I'm fine using bash where it is appropriate. Initscripts are not one of those places, but learning to write correct sh is vital if you intend to ask others to use your work in it. I don't really see anything contentious in that, nor anything worth arguing about.


Well, while you learn some POSIX on the way if you stay long enough and read everything that passes on; the flip side is that people are fighting for some time over how to implement something as opposed to actually helping the person that doesn't even care in the first place and just wants to get their task at hand done. One person's sin is another person's joy. And it doesn't stop with just POSIX details; sometimes it are just simple preference based things, like the way to clarify something is a command to the user, just contribute to the noise of that channel. Compare this to #gentoo, where we prefer to have signal instead of such noise. Why do they name their channel the way they don't want it to be in the first place? That's just a recipe for disaster... "Why do you suggest me POSIX? I want Bash. ^^"

Granted and I agree with you, there are certainly settings where POSIX compliance is a must; and I'd be on my guard if I were to write for that, but in general, it'll be a lack of care for places where it ain't needed and nobody will be bothered by it.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Oct 27, 2013 7:44 am    Post subject: Reply with quote

TomWij wrote:
mv wrote:
Mask the networkmanager unit and write a script which is able to start networkmanager based on a dynamic configuration.


Why would you write something that is implemented in NetworkManager?

By "start ... based on" I mean mainly whether to start Networkmanager (and dependencies like polkit and thus make your system insecure). (And once more, many setups I need, NetworkManager is not able to do. NetworkManager is not made for more complex static setups.)
Quote:
mv wrote:
Mask the encryption unit(s) and write a script which is able to start encryption support based on a dynamic configuration.

Yes, that's the same as you would do with OpenRC; unless, well, there is a service to do this for you.

I assumed that in both cases there is a service which does this. The difference is that the systemd service is hardcoded either on or off (and if on with a fixed configuration) while the openrc service can decide whether and how it is activated based on dynamic configuration (I hope it is clear what I mean by the latter: All sorts of tests the user wants to script like processor abilities (read from /proc) certain magic files or whatever is convenient for the user to decide which "modes" he wants the machine to run at this boot; perhaps even an interactive query in some cases).
Quote:
The border between a script and a service gets small here; so, which one you end up choosing doesn't matter...

If you write a new service, yes. If you want to start an existing service based on certain conditions you cannot easily do this with systemd except for rewriting the whole service on your own. Simply convenient ways of dynamic configuring are missing: In openrc you write some /etc/conf.d/... and then can do all sort of shell-code there. With systemd /etc/conf.d can be used only as static environment fies.
Quote:
mv wrote:
Mask the loading of modules somehow (BTW: not even possible with systemd) and write a script which is able to load the modules based on a dynamic configuration.

Why would you write a script for something that the kernel does?

The kernel does not load all modules. It cannot. That's why /etc/conf.d/modules (for openrc) or /etc/modules-load.d (for systemd) exist. Again, the difference is the /etc/conf.d/modules can use any shell code that you want to determine the modules you need (e.g. for mounted encrypted partitions you should better load some modules depending on the processor properties [because some are processor optimized algorithms, just check the kernel configuratoins; the kernel does not automatically choose the "best" one) while for systemd you can only use a static setup.
Quote:
mv wrote:
Switch off all the systemd and write a configurable init-system without systemd supporting you in any way.

Nothing stops you from configurable scripts in systemd; so, I don't see a reason for turning it off.

Because you have to rewrite practically everything which you want to use because systemd does not support you: You cannot use its services when you want dynamic configuration.
Quote:
I'd rather spend time configuring and using my computer than to unnecessarily implement things that already exist; the whole point is about not writing any init system at all, note how what I said applies just as well to OpenRC.

Exactly. The point is that openrc just needs to be configured (wit a few tests put into /etc/conf.d/... files) while in contrast, the systemd services cannot be configured dynamically except if you practically rewrite everything manually in scripts (which means that you are practically forced to re-implement most of the systemd things in a sane manner)
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 8:53 am    Post subject: Reply with quote

mv wrote:
Because you have to rewrite practically everything which you want to use because systemd does not support you: You cannot use its services when you want dynamic configuration.


No, you don't. In systemd you can do this using generators, which can effectively be a bash script that creates a symbolic link of a certain service based on certain conditions; if you need to implement such specific and/or exceptional rules that services don't already cover.

mv wrote:
Exactly. The point is that openrc just needs to be configured (wit a few tests put into /etc/conf.d/... files) while in contrast, the systemd services cannot be configured dynamically except if you practically rewrite everything manually in scripts (which means that you are practically forced to re-implement most of the systemd things in a sane manner)


The whole point about systemd is not having to do extra configuration in the system daemon for matters that the service itself allow you to configure. It's a paradigm shift; so, there's no need and no point in rewriting it manually (and no, you're not forced to do that as in that paradigm it is not a sane thing to do).
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Oct 27, 2013 10:35 am    Post subject: Reply with quote

TomWij wrote:
No, you don't. In systemd you can do this using generators, which can effectively be a bash script that creates a symbolic link of a certain service based on certain conditions

Which is possible only for a few service modules but not for the many hardcoded things like the mentioned /etc/modules.load.d (which is read hardcoded even before you can do anything), time handling in systemd, etc.
Quote:
The whole point about systemd is not having to do extra configuration in the system daemon[...] It's a paradigm shift [...] in that paradigm it is not a sane thing to do).

Exactly: It is a paradigm shift. From configurable flexible init-system in which every task is its own program to a static setup with hardcoded behaviour all implemented in one bulky program and the possibility to choose between a few more or less fixed setups which fall into Poetterings/Redhat main use cases. For practically all use-cases not foressen by Poettering you are forced to work against the infrastrcuture provided by systemd which - I completely agree - is not a sane thing to do. The sane thing is to drop the infrastructure which forces this stupid paradigm of limited choice and use a working init-system without such stupid restrictions. (The fact that you can work against the infrastructure because by calling your own scripts you can do anything - including implementing an init-system which works for you if you are willing to waste your time - is not a reason to use the broken infrastructure.)
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 12:12 pm    Post subject: Reply with quote

mv wrote:
TomWij wrote:
No, you don't. In systemd you can do this using generators, which can effectively be a bash script that creates a symbolic link of a certain service based on certain conditions

Which is possible only for a few service modules but not for the many hardcoded things like the mentioned /etc/modules.load.d (which is read hardcoded even before you can do anything), time handling in systemd, etc.


Of course, that's what it says; "systemd-modules-load.service is an early-boot service that loads kernel modules from static configuration.", if you don't want "static configuration", then use something else. And even though it mentions it to be static, you can actually still pass it modules from the kernel command line and use it in a dynamic way; but really, just use a dynamic service instead if you very much prefer that.

mv wrote:
Quote:
The whole point about systemd is not having to do extra configuration in the system daemon[...] It's a paradigm shift [...] in that paradigm it is not a sane thing to do).

Exactly: It is a paradigm shift. From configurable flexible init-system in which every task is its own program to a static setup with hardcoded behaviour all implemented in one bulky program and the possibility to choose between a few more or less fixed setups which fall into Poetterings/Redhat main use cases.


What is hardcoded? I've just shown you how things are dynamic. Just because there are a limited use cases provided, doesn't mean that you cannot extend it with your own...

mv wrote:
For practically all use-cases not foressen by Poettering you are forced to work against the infrastrcuture provided by systemd which - I completely agree - is not a sane thing to do.


How is it against the infrastructure to use generators or adjust the configuration of the services?

mv wrote:
The sane thing is to drop the infrastructure which forces this stupid paradigm of limited choice and use a working init-system without such stupid restrictions. (The fact that you can work against the infrastructure because by calling your own scripts you can do anything - including implementing an init-system which works for you if you are willing to waste your time - is not a reason to use the broken infrastructure.)


The whole point is that there's no need to work against it, I'd rather prefer to use systemd the minimal way it is; by not hacking the "system daemon", but rather start picking and configuring the right services.

If I'd ever go back to OpenRC, I'd do `rm -rf /etc/conf.d/` for a start as to not have unnecessary duplicate configuration files; I don't see the point to have something what is effectively a configuration directory inside a configuration directory (/etc/etc/)...


Last edited by TomWij on Sun Oct 27, 2013 12:17 pm; edited 2 times in total
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Sun Oct 27, 2013 12:15 pm    Post subject: Reply with quote

mv wrote:
For practically all use-cases not foreseen ...


This six words nail the issue pretty much for me.

The difference lies where systemd behaves more like osx or android closed playground, it works only the way systemd is designed for and within those limits. Whereas the openrc (not hardcoded) gives room for flexibility and improvisation.

systemd got caught up re-inventing the wheel, re-inventing the script, re-inventing the shell, re-inventing sh. Which not necessarily bad, if they get a kick out of it.

However what is wrong is claiming systemd is the ultimate solution and force it upon everyone. Not to say including shady shit like Gnome dependencies.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 12:24 pm    Post subject: Reply with quote

_______0 wrote:
mv wrote:
For practically all use-cases not foreseen ...


This six words nail the issue pretty much for me.


It's not in systemd's goal to cover them as part of the systemd code; so, I don't which issue you are addressing.

_______0 wrote:
The difference lies where systemd behaves more like osx or android closed playground, it works only the way systemd is designed for and within those limits. Whereas the openrc (not hardcoded) gives room for flexibility and improvisation.


Exactly, it is not meant to be another OpenRC; it limits it scope to not cover what services already can, such that it can focus to improve more internal matters like the system daemon itself.

_______0 wrote:
However what is wrong is claiming systemd is the ultimate solution and force it upon everyone.


Who does? Can you quote?

_______0 wrote:
Not to say including shady shit like Gnome dependencies.


The USE flags systemd and openrc-force allow you to pick one or the other.
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Sun Oct 27, 2013 2:42 pm    Post subject: Reply with quote

TomWij wrote:

Who does? Can you quote?


Now you sound like the classic infiltrator. What's that tone implying systemd is without controversy? Through this thread you've employed massive amounts of efforts sugar coating systemd implementation, dissecting everyone's post line by line. That same amount of effort could've been used to refine openrc. The only explanation is some goal to weaken gentoo's openrc idea internally.

There are plenty of other systemd lovin' distros, such as sabayon. Leave gentoo alone.

Let me ask you this, why don't you help improving openrc?
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Sun Oct 27, 2013 3:05 pm    Post subject: Reply with quote

The cold war of a communist Systemd insurgency is happening right here in this thread!
_______0 wrote:
TomWij wrote:
Who does? Can you quote?
Now you sound like the classic infiltrator.

An agent provokateur , who is
Quote:
sugar coating systemd implementation

by
Quote:
dissecting everyone's post line by line.

He is weakening the ideas of the free world by trying
Quote:
to weaken gentoo's openrc idea internally.

Behind the lines internally!

Quote:
Leave gentoo alone.

Please, leave this thread meant to discuss. Not to propagate such conspiration theory, which would perhaps fit against Android. But I guess more than half the people telling this nonsense are using Google, talk, chrome, android etc.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Oct 27, 2013 4:38 pm    Post subject: Reply with quote

TomWij wrote:
if you don't want "static configuration", then use something else. And even though it mentions it to be static, you can actually still pass it modules from the kernel command line and use it in a dynamic way; but really, just use a dynamic service instead if you very much prefer that.

kernel command line is not "dynamic" in the sense described several times.
Quote:
What is hardcoded? I've just shown you how things are dynamic.

You have just admitted that the only way to have it dynamic is "use a dynamic service" - which is exactly what I had described: Switch off the systemd functionality and rewrite it on your own. That is, work against the infrastructure.
Of course, kernel modules are not the only example. /etc/tmpfiles.d is another one. The way mounts are handled is yet another one (despite that there is a "generator"). Actually, whole systemd idea is such an example.
Quote:
How is it against the infrastructure to use generators or adjust the configuration of the services?

Necessity to switch off the provided services like module-loadin, tmpfiles handling, mounting etc. and rewriting this all on your own, because it cannot be configured in the desired way: It is hard to imagine how one could work more against the infrastructure.
Quote:
I'd rather prefer to use systemd the minimal way it is; by not hacking the "system daemon", but rather start picking and configuring the right services.

If you are in one of Poettering's use-cases, this is possible. Otherwise you are fucked with systemd.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Sun Oct 27, 2013 4:56 pm    Post subject: Reply with quote

mv wrote:
I assumed that in both cases there is a service which does this. The difference is that the systemd service is hardcoded either on or off (and if on with a fixed configuration) while the openrc service can decide whether and how it is activated based on dynamic configuration

@mv, a few articles above you spoke about missing dynamic configuration of net with Systemd. I just found a new contribution at systemd-git which provides ethtool capabilities. Will this fit your needs when Systemd-209 will be released? A longer comment about it from Tom Gundersen at
http://cgit.freedesktop.org/systemd/systemd/commit/?id=af6f0d422c521374ee6a2dd92df5935a5a476ae5
following is a patch called "udev: link-config: add ethtool support" at
http://cgit.freedesktop.org/systemd/systemd/commit/?id=a501033335ed402c8f7e86fe41a15531ba69abd7
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Sun Oct 27, 2013 5:12 pm    Post subject: Reply with quote

TomWij wrote:
Well, since NetworkManager can do that

Ahahahah! Thats funny. Back in the days of RHEL6 we had to remove NM from everywhere cuz it had been behaving like a retard high on cocaine if something unexpected happened (like a vpn tunnel or two). So no, NetworkManager can not do. Just can not.

TomWij wrote:
systemd is just a system daemon, not a network manager.


Define "just a systemd daemon" please. Because from what I can see, systemd is a log manager, authentication manager, device manager, display backlight manager, user ass wiping manager, etc.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 6:01 pm    Post subject: Reply with quote

_______0 wrote:
TomWij wrote:

Who does? Can you quote?


Now you sound like the classic infiltrator. What's that tone implying systemd is without controversy? Through this thread you've employed massive amounts of efforts sugar coating systemd implementation, dissecting everyone's post line by line.


You are avoiding the question. And indeed no init system or system daemon is without controversy. This thread is about systemd and its implementation; so, dissection is a first step to improving it and its usage...

_______0 wrote:
That same amount of effort could've been used to refine openrc. The only explanation is some goal to weaken gentoo's openrc idea internally.

There are plenty of other systemd lovin' distros, such as sabayon. Leave gentoo alone.

Let me ask you this, why don't you help improving openrc?


Because Gentoo is all about choice (see About, Philosophy and the Handbook Introduction); so, neither choice should be left alone. This thread is however not about OpenRC; so, to answer your question, I don't run it and neither have interest in running it because I am running systemd for specific reasons, as a consequence I am unable to help to improve OpenRC. It doesn't imply that OpenRC is a bad idea; like I said before, it is just a shift in paradigm. And that's exactly what makes it a choice if people want to use one paradigm or the other; in the terms of clothing, there is not a single size that fits everyone...

Note that I have not contributed to systemd yet either; because just like OpenRC, it works for me so I don't really see what to improve about it.


Last edited by TomWij on Sun Oct 27, 2013 6:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 6:06 pm    Post subject: Reply with quote

mv wrote:
TomWij wrote:
if you don't want "static configuration", then use something else. And even though it mentions it to be static, you can actually still pass it modules from the kernel command line and use it in a dynamic way; but really, just use a dynamic service instead if you very much prefer that.

kernel command line is not "dynamic" in the sense described several times.


Yes, that is why it mentions it as static; which is why a dynamic service is more preferable.

mv wrote:
Quote:
What is hardcoded? I've just shown you how things are dynamic.

You have just admitted that the only way to have it dynamic is "use a dynamic service" - which is exactly what I had described: Switch off the systemd functionality and rewrite it on your own. That is, work against the infrastructure.


By the implication of the paradigm shift it has nothing to do with the systemd infrastructure, because you move to a different infrastructure; eg. NetworkManager, which isn't part of systemd.

mv wrote:
Quote:
How is it against the infrastructure to use generators or adjust the configuration of the services?

Necessity to switch off the provided services like module-loadin, tmpfiles handling, mounting etc. and rewriting this all on your own, because it cannot be configured in the desired way: It is hard to imagine how one could work more against the infrastructure.


No, you would use external services to handle these tasks if you want them dynamic; this does not imply rewriting them on your own, you can reuse what exists on the internet, except for the few small cases not already covered.

mv wrote:
Quote:
I'd rather prefer to use systemd the minimal way it is; by not hacking the "system daemon", but rather start picking and configuring the right services.

If you are in one of Poettering's use-cases, this is possible. Otherwise you are fucked with systemd.


Why? The many services that exist out there cover almost all use cases, not just the ones imagined by the systemd developers.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 6:14 pm    Post subject: Reply with quote

grey_dot wrote:
TomWij wrote:
Well, since NetworkManager can do that

Ahahahah! Thats funny. Back in the days of RHEL6 we had to remove NM from everywhere cuz it had been behaving like a retard high on cocaine if something unexpected happened (like a vpn tunnel or two). So no, NetworkManager can not do. Just can not.


Yes, it might have been like that back in the days; VPN tunnels for example work fine here. But it is just an example; NetworkManager isn't the only service out there, just use one that you prefer.

grey_dot wrote:
TomWij wrote:
systemd is just a system daemon, not a network manager.


Define "just a systemd daemon" please. Because from what I can see, systemd is a log manager, authentication manager, device manager, display backlight manager, user ass wiping manager, etc.


Well, it depends on what you define as systemd; which can be perceived as a "system daemon". That some software comes with documentation, doesn't suddenly make the software into a documentation library.

With just a one liner`systemctl disable systemd-journald.service systemd-logind.service systemd-udevd.service systemd-backlight.service ...` I still have systemd running after reboot; so, I wouldn't imply those as part of it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Oct 27, 2013 6:26 pm    Post subject: Reply with quote

TomWij wrote:
steveL wrote:
*sigh* if you learnt bash from greycat et al, in #bash, you'd know not to bother with == in bash [[ either. Irrespective, sh is not bash, and believe me I'm fine using bash where it is appropriate. Initscripts are not one of those places, but learning to write correct sh is vital if you intend to ask others to use your work in it. I don't really see anything contentious in that, nor anything worth arguing about.


Well, while you learn some POSIX on the way if you stay long enough and read everything that passes on; the flip side is that people are fighting for some time over how to implement something as opposed to actually helping the person that doesn't even care in the first place and just wants to get their task at hand done. One person's sin is another person's joy. And it doesn't stop with just POSIX details; sometimes it are just simple preference based things, like the way to clarify something is a command to the user, just contribute to the noise of that channel. Compare this to #gentoo, where we prefer to have signal instead of such noise. Why do they name their channel the way they don't want it to be in the first place? That's just a recipe for disaster... "Why do you suggest me POSIX? I want Bash. ^^"

I'm sorry the above just does not parse to me: it appears to be witter, if you don't mind me discussing your statements and won't take it as an attack upon your person. ;)
If you want bash, use a #!/bin/bash shebang is about the only response I can muster.
Quote:
Granted and I agree with you, there are certainly settings where POSIX compliance is a must; and I'd be on my guard if I were to write for that, but in general, it'll be a lack of care for places where it ain't needed and nobody will be bothered by it.

You mean like where it won't work on another, POSIX-compliant, shell?

There is a reason = is string comparison in test/[, and == is numeric in $((..)). This is not C, so better to forget any muscle-memory from C, or any other language, and realise you are in sh, and focus on that, before an end-user finds the other holes in your script, usually when it really messes them up.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Oct 27, 2013 6:35 pm    Post subject: Reply with quote

steveL wrote:
Quote:
Granted and I agree with you, there are certainly settings where POSIX compliance is a must; and I'd be on my guard if I were to write for that, but in general, it'll be a lack of care for places where it ain't needed and nobody will be bothered by it.

You mean like where it won't work on another, POSIX-compliant, shell?

There is a reason = is string comparison in test/[, and == is numeric in $((..)). This is not C, so better to forget any muscle-memory from C, or any other language, and realise you are in sh, and focus on that, before an end-user finds the other holes in your script, usually when it really messes them up.


Exactly. The bash scripts I usually write don't reach end-users, but circle around my home directory and use Bash; so, the only cases where it is necessary (eg. init scripts) I switch to POSIX compliance.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Oct 27, 2013 6:46 pm    Post subject: Reply with quote

TomWij wrote:
mv wrote:
Exactly. The point is that openrc just needs to be configured (wit a few tests put into /etc/conf.d/... files) while in contrast, the systemd services cannot be configured dynamically except if you practically rewrite everything manually in scripts (which means that you are practically forced to re-implement most of the systemd things in a sane manner)


The whole point about systemd is not having to do extra configuration in the system daemon for matters that the service itself allow you to configure.

Huh? We configure our services somewhere, whether in systemd or openrc. That you don't like the name conf.d, does not change that. At least with openrc we're not restricted to an insane setup foisted upon us by red-hat's inability to etc-update, which sticks configuration data in /usr/lib of all places, plus various other apparently random choices we have to dig through to see what is happening.
Quote:
It's a paradigm shift; so, there's no need and no point in rewriting it manually (and no, you're not forced to do that as in that paradigm it is not a sane thing to do).

No it's not; it's a regression. Instead of mostly-declarative config, plus custom initscripts should the admin require them and the existing scripts do not fit the bill, and dynamic configuration in line with everything else an admin does, we have a purely-declarative config, or use javascript (what a corker of an idea!); afaict that appears to be the direction posited.

As discussed above, this "paradigm shift" actually leads to more work. Keep it thanks. ;-)

Now, can we have our Gentoo back without being labelled haters? We don't mind what others want to do, we just want to make the traditional setup work, exactly as it always has, and indeed is required to within an initramfs.

Why are we labelled haters, when we simply do not care about a new piece of software, and we have proven we can keep the traditional setup running, in line with upstream requirements? (Well, as stated by the one member of the udev "inner-circle" who isn't apparently off his head, Greg K-H.)

Answer that question to your own satisfaction, and you will understand a lot more about group-dynamics, groupthink, and peer-pressure, as well as marketing, propaganda and "fashion".
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Oct 27, 2013 6:47 pm    Post subject: Reply with quote

TomWij wrote:
Exactly. The bash scripts I usually write don't reach end-users, but circle around my home directory and use Bash; so, the only cases where it is necessary (eg. init scripts) I switch to POSIX compliance.

And what does that have to do with "the bad old days" of crappy initscripts written by amateur Linux "developers"?
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 5 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum