| View previous topic :: View next topic |
| Do you want systemd as default on Gentoo? |
| I <3 systemd!! I want Gentoo to switch!! |
|
12% |
[ 26 ] |
| Get that horse-crap away from Gentoo as far as possible! |
|
87% |
[ 186 ] |
|
| Total Votes : 212 |
|
| Author |
Message |
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
 Posted: Fri Oct 10, 2014 4:25 pm Post subject: |
 |
|
http://www.itwire.com/opinion-and-analysis/open-sauce/65652-no-interest-in-poetterings-problems-says-torvalds
| Quote: | | Linux creator Linus Torvalds has indicated that he has no interest in the problems faced by chief systemd developer Lennart Poettering that led to the latter blaming Torvalds for the negative feedback he (Poettering) has faced. |
Unfortunately, the rest of the article isn't too ensuring. Basically all that's stopping Linux from accepting patches for kdbus/systemd seems to be code quality and maintainance(let's hope LP/KS are continuing to fail in that regard).
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
 |
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Oct 10, 2014 4:47 pm Post subject: |
|
|
| depontius wrote: | I've said before, and I'll repeat... We're not the real enemy. Linus is not the real enemy. He hasn't yet met the real enemy. But because he managed to stage a political victory and take over all of the mainstream (Let's face it, these days Gentoo and Slackware are fringe distributions, Chrome aside, which people generally don't recognize as Linux, anyway.) he's about to meet the real enemy. In the next year he's going to be out of early adopters and into mass adoption, and that includes the unwashed masses.
The real enemy is going to be real life.
Does anyone here believe systemd is going to Just Work (TM) under mass deployment?
Does anyone have any reason to believe this will go better than the pulseaudio initial deployment did? (At least pulseaudio never went NEAR a server.)
Chinese proverb/curse - "May you live in interesting times."
Same general source, I believe - "Be careful what you ask for - you may get it."
Finally, Helmuth von Moltke the Elder - "No battle plan survives contact with the enemy." (Back to that word "attacks" that started this.)
EDIT - Funny thing... Had they not gone on the rampage and taken over all distributions last fall, had they staged systemd in smoothly and ironed out the mass-distribution bugs with ordered growth, they probably would have achieved their goal and become the monoculture they so desire. Now they're very likely to have to deal with a backlash, in the server space at the very least. |
Richard P. Feynman phrased this very consisely  (copied from Wikipedia):
| Quote: | | "For a successful technology," Feynman concluded, "reality must take precedence over public relations, for nature cannot be fooled." |
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
Ottre
Tux's lil' helper
Joined: 23 Dec 2012
Posts: 129
|
| Posted: Fri Oct 10, 2014 5:15 pm Post subject: |
|
|
Some interesting comments from Craig Sanders, one of the longest serving Debian developers (1994-present):
| Quote: |
> ISTM that if neither upstart nor systemd deliver the goods once
> finished, then a third new offering will arise. Parallel starting of
> services, and effective handling of events will be provided, one way or
> another, I expect.
that's the problem with systemd - once it takes over, this "third new
offering" will never happen because in order to have even a chance of
success it will not only have to do init's job, it will have to do
dozens of other unrelated tasks. and it will have to do them *ALL* from
the very first version.
|
http://lists.luv.asn.au/pipermail/luv-main/2014-October/006852.html
| Quote: |
an individual may be able to choose to disable some of systemd's features,
but a systemd-replacement can not because it can not know which features
(if any) other people choose to disable.
at the moment, this problem is less than obvious because we're still
in a transition phase - most people are still using other programs for
the functions that systemd is taking over. it's a lot easier to switch
to software that gradually, through feature-creep, replaces dozens of
other programs than it would be to, when systemd is ubiquitous, replace
systemd with dozens of other programs all at once. i.e. the transition
to systemd is likely to be one-way, impossible or immensely difficult to
revert.
|
http://lists.luv.asn.au/pipermail/luv-main/2014-October/006870.html |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Oct 11, 2014 4:11 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | People who use systemd have difficulty, especially if they want to decide for themselves what components they run, as you have found. Or indeed if they try to switch back, afaict. |
Since AFAIK you never tried to run systemd seriously, let me make some corrections to these assumptions: |
No, sorry: show me where I've assumed anything at all in the above sentence, first. The first sentence is simply acknowledging the experience of another user. The second I address below, though I've told you about it before.
You don't just get to characterise my statements like that, and then move on without being picked up on it.
| Quote: | | People who use systemd have difficulties, but mainly because much of the crap is not working as documented, or at least not reproducible as documented - it is full of programming errors. There are things which are not intended to be switched of (mounting, journald), others are (dhcp/networkd, timedated, time) and in fact, usually you have to switch them off, because they are lousily implemented or do not work at all. So switching the things off is not the difficulty, you get only difficulties it you try to use them. Of course, this might change in some future systemd versions, but at least in in the last few releases, they essentially just added features and new bugs and eliminated only very few known bugs. |
So IOW it's crap, from amateurs who have zero clue.
| Quote: | | Switching back to openrc is not a problem at all: The init systems use different config files (except for some common things like tmpfiles.d). |
Landley mentioned on IRC (can't remember the channel, I think it was #musl) that in fact when you have systemd files still installed, the udev rules still in place on the FS, run and then bail because systemd is not running, which leads to worse performance under other init systems. (Nice way to screw the competition, who you've forced to build and install the whole of systemd.)
So again, this was not assumption on my part, but relaying of information. Perhaps one might characterise it as hearsay, if one were trying to avoid it; either way the issue still needs to be addressed.
I'd hoped you would have checked that last time we discussed it. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Oct 11, 2014 5:36 am Post subject: |
|
|
| steveL wrote: | | mv wrote: | | steveL wrote: | | People who use systemd have difficulty, especially if they want to decide for themselves what components they run, as you have found. Or indeed if they try to switch back, afaict. |
Since AFAIK you never tried to run systemd seriously, let me make some corrections to these assumptions: |
No, sorry: show me where I've assumed anything at all in the above sentence, first. |
It is not the first time that my poor knowledge of English would lead to misunderstandings between us.
You never before spoke from some experiences which you have made with systemd, and to me the phrase "Or indeed if they try to switch back, afaict" does not sound like if you speak about an experience which you actually made. Since this is only the second part of a sentence, it seemed that this holds for the first sentence as well.
| Quote: | | Perhaps one might characterise it as hearsay |
This is what I meant; for my English understanding "hearsay", "assumption", or "educated guess" are practically synonymous. I wanted to contribute some true experience and not something which can appear as rumour. If this was already clear from your sentence, I excuse for my misunderstanding. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Oct 11, 2014 5:59 am Post subject: |
|
|
| steveL wrote: | | when you have systemd files still installed, the udev rules still in place on the FS, run and then bail because systemd is not running, which leads to worse performance under other init systems |
I never received such an error message, but maybe this is because I have my own rules for all of my FS, and 99-systemd.rules is last.
What I do receive are error message, because of the "!.." flag in tempfiles.d which is not recognized by openrc (we talked about this flag in another thread).
However, it seems safe to ignore these errors for the files provided by systemd.
| Quote: | | (Nice way to screw the competition, who you've forced to build and install the whole of systemd.) |
I am not sure whether the rules have this reason. After all, they probably serve some purpose in systemd. Since I do not know which exact rules you talk about, I cannot judge.
Anyway, you can easily "mask" 99-systemd.rules, but unfortunately not conditionally.
This is not a problem of systemd alone. In fact, it is a problem of the (e)udev and tmpfiles.d configuration files: You cannot make them conditional, becaues they are not shell code; in shell code you could just add a test whether you want them and thus e.g. activate them for one init system but not for the other.
(OK, in udev rules you could call a shell script and work with GOTO, but this is extremely inconvenient and cannot be easliy used in /etc/udev... to skip files from /lib/udev.
Moreover, for tempfiles.d there is no such possibility at all.)
I would really like to see such an exension of these quasi-standards to include at least conditionals easily: This would also have the advantage that you could simpler write files which can be used for a whole set of different machines. /etc/modules-load.d of systemd could also need such an extension. (openrc's /etc/openrc/modules is shell code and thus does not have this problem.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Oct 11, 2014 9:03 am Post subject: |
|
|
| mv wrote: | | It is not the first time that my poor knowledge of English would lead to misunderstandings between us. |
Don't worry about that; if I react to a statement it's to the content in its context, and shouldn't be misinterpreted as a criticism of you, nor as offence-taking on my part. I'd have stopped using the internet a long time ago if i were to take offence at people disagreeing with me, in whatever terms. I'll go into this in a bit more detail, as I'd like to simply have substantive discussion with you.
In discussion terms, yes I don't like being told my statements are simply "assumptions", especially not when it's just slipped in like that, and then segue onto the next point. That kind of elision is ill-mannered in English discussion terms: it's better to stop and say "this is pure assumption, and this is why." In fact, your statement presumes agreement with that characterisation, which most people will react to, ime; it comes across as condescending.
A bit like stating "I know you can't help yourself, so I'm going to do this for you," rather than just helping a fellow human-being.
However when you use the word "assumption" it implies that you know what the other person was thinking, in some sense; in any event it implies sloppy thinking on the part of whomever you are attributing the assumption to.
To the specific: The thing is you used the word assumption in the plural, and there are only two points you're discussing. The first statement I made: "People who use systemd have difficulty, especially if they want to decide for themselves what components they run" was clearly simply a reiteration of what someone else had already reported, along with many others across various distros.
That is not an assumption. I appreciate your final point, which I address below, speaks to this as well.
| Quote: | | You never before spoke from some experiences which you have made with systemd, and to me the phrase "Or indeed if they try to switch back, afaict" does not sound like if you speak about an experience which you actually made. Since this is only the second part of a sentence, it seemed that this holds for the first sentence as well. |
Oh you're absolutely right that I have no experience with systemd: quite deliberately, and I've never hidden that fact.
The point is (in the context of us getting past these misunderstandings), that I used "afaict" to indicate that fact once again; your characterisation came across as implying that I'm somehow hiding that fact, and just talking out of the top of my head.
| Quote: | | Quote: | | Perhaps one might characterise it as hearsay |
This is what I meant; for my English understanding "hearsay", "assumption", or "educated guess" are practically synonymous. I wanted to contribute some true experience and not something which can appear as rumour. |
Well that's why I wanted to ask you about what Landley said. Yes he's fairly reliable, but I'd rather hear it confirmed or denied. For all I know those rules might not get fired any more, though it doesn't strike me as something the upstream would ever bother themselves about.
But really, if you keep accepting constraints from upstream as to how to approach this, you'll never get anywhere; in this case you'd end up never listening to a bug report, since it's just "hearsay".
Perhaps that's what the NOTABUG resolution is about. As an aside, I have to say that's a terribly-amateur way to label user bug-reports.
I don't think you are stating that all the people who've had issues with systemd and using other components, should merely be dismissed as hearsay; but at this point, that's how it seems, from your text so far. (and that's how it seemed before, only it was my "assumption" which should be dismissed.)
| Quote: | | If this was already clear from your sentence, I excuse for my misunderstanding. |
Well I must apologise if I'm coming across as angry; it's not my intent at all. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Oct 11, 2014 9:18 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | when you have systemd files still installed, the udev rules still in place on the FS, run and then bail because systemd is not running, which leads to worse performance under other init systems |
I never received such an error message, but maybe this is because I have my own rules for all of my FS, and 99-systemd.rules is last.
|
No it's not about error messages: Landley said they just run and then exit, with the user none the wiser. He only found it when he was profiling the various options. To get a reasonable profile without systemd, he had to remove all of it, effectively, or it skewed the results.
Though ofc this is just hearsay, filtered through my memory ;) I just thought it should be investigated by someone impartial.
| Quote: | | Quote: | | (Nice way to screw the competition, who you've forced to build and install the whole of systemd.) |
I am not sure whether the rules have this reason. After all, they probably serve some purpose in systemd. |
Oh I'm sure they do; however there is an assumption in systemd that they are the only init system in the world, and in fact even helping users to run something else is somehow "bad" for the user. It's a short step to forcing users to run whatever, as we've seen.
My point is as above: I don't think they'd care if it did happend, and I think they'd refuse patches to make it not happen, on the grounds that they're "helping" the user by forcing them to use systemd, even if that means by screwing the benchmarks; in fact I think they'd see that as a really kewl way to "help" the user, since it's so sneaky. They seem to get a kick out of power and obfuscation, much like many religions, from what I've read.
| Quote: | This is not a problem of systemd alone. In fact, it is a problem of the (e)udev and tmpfiles.d configuration files: You cannot make them conditional, becaues they are not shell code; in shell code you could just add a test whether you want them and thus e.g. activate them for one init system but not for the other.
(OK, in udev rules you could call a shell script and work with GOTO, but this is extremely inconvenient and cannot be easliy used in /etc/udev... to skip files from /lib/udev.
Moreover, for tempfiles.d there is no such possibility at all.)
I would really like to see such an exension of these quasi-standards to include at least conditionals easily: This would also have the advantage that you could simpler write files which can be used for a whole set of different machines. /etc/modules-load.d of systemd could also need such an extension. (openrc's /etc/openrc/modules is shell code and thus does not have this problem.) |
Your last statement says it all. Keep going down that route of "incremental extension (so that's okay, right?)" and you end up with a crappy, fragile and bloated reimpl of sh, that only does half the job; badly.
With a tenth of the performance.
Another one of those "bigger picture" discussions, I'm afraid. Put it this way: it'd look like cmake code, and overall perform much worse than what we already have, imo.
Especially when performance is about so much more than "how quickly can we fill a btrfs partition with junk," or indeed how fast can we get through the max 20 seconds per 6 months of uptime that matters. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Oct 12, 2014 6:43 am Post subject: |
|
|
| steveL wrote: | | mv wrote: | | I would really like to see such an exension of these quasi-standards to include at least conditionals easily: This would also have the advantage that you could simpler write files which can be used for a whole set of different machines. /etc/modules-load.d of systemd could also need such an extension. (openrc's /etc/openrc/modules is shell code and thus does not have this problem.) |
Your last statement says it all. Keep going down that route of "incremental extension (so that's okay, right?)" and you end up with a crappy, fragile and bloated reimpl of sh, that only does half the job; badly. |
For time reasons, let me only stick to this point, since this bothers me a lot:
I would really like to use the same configuration files on different machines and in different settings. So, in a sense, it would be necessary to allow at least for some sort of conditionals in these files. This is a problem if configuration files are declarative. The most important examples of declarative configuration files causing grief in this respect are: - /etc/tempfiles.d (of openrc/systemd)
- /etc/modules-load.d (of systemd)
- /etc/systemd (of systemd; only partially)
- /etc/modprobe.d (of kmod)
- /etc/{passwd,group,{g,}shadow}
- /etc/fstab
- /etc/X11/xorg.conf.d
- /etc/DIRCOLORS (partially)
- /etc/udev/rules.d (partially)
- /etc/portage
- /etc/ssh/ssh{,d}_config
These files are always an additional maintenance burden if you have several machines, because large parts of these files are identical, but some parts have to be machine- (or sometimes even booting-mode-) dependent. In case of directories (like fortunately in portage), you have at least the possibility to put the common things to some files and the individual things to other files. However, if you have a lot of files, this is an additional maintenance burden, too, since you cannnot just copy the directory from one machine to another. In fact, for manyl of these cases, I ended up writing scripts which generate/copy the corresponding files - which of course is a mess to maintain, too.
systemd has introduced some Condition...=... assignments (which unfortunately do not work everywhere) which linger the problem. Also, as mentioned earlier, udev has "GOTO="-assignments which - if combined with execution of an appropriate script - can be used to avoid the problem (at the cost of another complexity and speed), the location of /etc/DIRCOLORS can be changed dynamically (again at the cost of another complexity and speed).
For most cases, the possibility to check for an existence of a file would be sufficient: You could make some "magic" directory containing flags.
For many cases, however, a real programming language would be preferrable. For instance, in /etc/fstab you could use one variable to contain "your" default ext4-filesystem flags, /etc/DIRCOLORS could be written in a more reasonable way, etc.
Surprisingly, many people do not agree with me: For instance, squashmount (a perl project) was critiziced by some people because of its configuration being in perl, too. (In contrast, I consider it an important feature of squashmount that you can change the configuration extremely flexible).
In fact, I also criticize policykit for its decision to use javascript - however, for a different reason: The latter files are interpreted by a root daemon at runtime; I would probably not have such objections if the javascript interpreter would run only once at startup time, although still the choice of a web language for a configuration is more than questionable; actually using web stuff like XML for configuration is IMHO completely wrong, to start with. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Oct 12, 2014 8:59 am Post subject: |
|
|
| mv wrote: | | I would really like to use the same configuration files on different machines and in different settings. So, in a sense, it would be necessary to allow at least for some sort of conditionals in these files. |
Well, there are projects like puppet and cfengine. So that's not necessarily true: just if you don't want to add yaf layer to do what sh can do in a flash. Usually considered de-rigeur because RedHat has no dispatch-conf/etc-update (so let's force every other distro to scatter config files across the machine.)
| Quote: | This is a problem if configuration files are declarative.
..
These files are always an additional maintenance burden if you have several machines, because large parts of these files are identical, but some parts have to be machine- (or sometimes even booting-mode-) dependent. In case of directories (like fortunately in portage), you have at least the possibility to put the common things to some files and the individual things to other files. However, if you have a lot of files, this is an additional maintenance burden, too, since you cannnot just copy the directory from one machine to another. In fact, for manyl of these cases, I ended up writing scripts which generate/copy the corresponding files - which of course is a mess to maintain, too. |
Again, not sure why you're not using one of the above, since they're the default goto packages for that situation.
I agree it sucks that you need that simply to facilitate what is so basic to Unix, and so easy in openrc. (because it doesn't try to reinvent Unix as userland.exe.)
Also, I'd see version control as useful here, but I'd have to /join #git to get some real info about what others have done, before I went ahead.
That's what I love about runscript though: it can be purely declarative if you want, but when you need to do something you can. After all what good is a computer that can't do things? Hence my disinclination to call any of these nubskool idiots Computer Scientists; in that sense I'd prefer the courses they take to be considered part of some other dept. It's just a shame that's instead done by making CS part of Business/Marketing.
| Quote: | systemd has introduced some Condition...=... assignments (which unfortunately do not work everywhere) which linger the problem. Also, as mentioned earlier, udev has "GOTO="-assignments which - if combined with execution of an appropriate script - can be used to avoid the problem (at the cost of another complexity and speed), the location of /etc/DIRCOLORS can be changed dynamically (again at the cost of another complexity and speed).
For most cases, the possibility to check for an existence of a file would be sufficient: You could make some "magic" directory containing flags. |
gack. And they turn their noses up at us for using chmod -x to disable a config file.
| Quote: | For many cases, however, a real programming language would be preferrable. For instance, in /etc/fstab you could use one variable to contain "your" default ext4-filesystem flags, /etc/DIRCOLORS could be written in a more reasonable way, etc.
Surprisingly, many people do not agree with me: For instance, squashmount (a perl project) was critiziced by some people because of its configuration being in perl, too. (In contrast, I consider it an important feature of squashmount that you can change the configuration extremely flexible). |
Well I don't agree with you for things like fstab either. Though you can do that very easily and efficiently with awk, and it'll work in early userspace should that be needed. That script (Bentley's m1) is where autoflake got its syntax from. (Bonus points for: obvious optimisations; penalty for: inability to grok awk, and resorting to perl instead.. ;)
| Quote: | | In fact, I also criticize policykit for its decision to use javascript - however, for a different reason: The latter files are interpreted by a root daemon at runtime; I would probably not have such objections if the javascript interpreter would run only once at startup time, although still the choice of a web language for a configuration is more than questionable; actually using web stuff like XML for configuration is IMHO completely wrong, to start with. |
Yup yup. Though from where I'm sitting it's quite amusing to watch. Schadenfreude is not quite the right term, since I feel quite bad for the users lumped with things they have no choice over. But it's nevertheless somewhat amusing, after having been ostracised for standing up and saying "the emperor has no clothes."
Or in my language: "That project is sh1t. It's not going anywhere near one of my boxen." |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Oct 12, 2014 9:51 am Post subject: |
|
|
This maybe useful if you have many machines online, but not for occassionally maintaining a machine. Moreover, also just booting "quickly" in a different mode from the command line is not so easy. If I would want an additional layer which generates config-files on every boot, I could as well work with home-brewn shell-scripts.
The problem is that all thiis increases the complexity and makes things hard when changes come.
For instance, once I had scripts to generate an xorg.conf from several snippets. Then came hal, and everything had to be re-done. Then came xorg.conf.d and everything had to be re-done. But it might nevertheless be that during traveling I find that I have to use a machine which still uses hal or is even older, so I have to maintain a lot of old files, still.
| Quote: | | I agree it sucks that you need that simply to facilitate what is so basic to Unix, and so easy in openrc. |
Yes, that's the problem: You have all the powerful tools, but the configs are in a way that you can use the tools only to generate the configs, but you cannot use them dynamically in the configs.
| Quote: | | Quote: | | For most cases, the possibility to check for an existence of a file would be sufficient: You could make some "magic" directory containing flags. |
gack. |
I also do not like it much, but it is better than having no conditional at all, so at least "it works". Actually, systemd has some more tests, but of course it would be preferrable to have config-files in which you have no such restrictions at all.
| Quote: | | Well I don't agree with you for things like fstab either. |
The problem is that fstab has gained a lot of new functionality: Previously you entered there a few local partitions.
Nowadays, you (well: I) enter there also things like partitions of several USB-harddisks,cameras,etc. which you want to appear always at the same place.
And then there are more complex things like swap (which partially needs also be configured by scripts), preparations for some chroots, preparations for encryption, etc.
So it is a mixture of "local" things, "global" things, "pre-"things for other scripts etc.
Hacks like udisks are invented to avoid parts of the latter 2 to be entered in fstab, but actually they need to be entered in fstab or otherwise you do not get clean umounting on shutdown, unless you have a coupling of the udisks hacks with further hacks like systemd: All these hacks are not nice. But having a complex fstab is not nice, either. Having the possibility to include files and to formulate some conditionals would be really helpful.
| Quote: | | Though you can do that very easily and efficiently with awk, and it'll work in early userspace should that be needed. |
I have been there, but it is no solution (like puppet wouldn't be for me): Some years ago, I had used m4 to generate xorg.conf for various machines from various code snippets. With the number of machines and cards increasing, this script needed more and more options, and eventually became just a mess.
It could be just so simple: Instead of parsing a config file directly, just define that all files will be pulled through m4 or are the output of some shell/perl/whatever script or something similar, and the user could easily add conditionals or whatever he needs. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Oct 12, 2014 1:56 pm Post subject: |
|
|
| mv wrote: | | If I would want an additional layer which generates config-files on every boot, I could as well work with home-brewn shell-scripts. |
Or a saner init-manager.
Though not sure generating them at boot is such a good idea, m1 would make it trivial (see below.)
| Quote: | | The problem is that all this increases the complexity and makes things hard when changes come. |
Yes, hence the maxim: "As simple as possible, but no simpler."
When one considers the domain in the round, all we're doing is exploring the reasons why sh as an integral part of the OS is such a stonkingly good idea.
| Quote: | | For instance, once I had scripts to generate an xorg.conf from several snippets. Then came hal, and everything had to be re-done. Then came xorg.conf.d and everything had to be re-done. But it might nevertheless be that during traveling I find that I have to use a machine which still uses hal or is even older, so I have to maintain a lot of old files, still. |
Isn't that what version control is for? Just saying, because I only came to it quite late in life, and it's taken me years to feel halfway-comfortable with git. But git (or a dvcs, in general) does change the way you work. There are many possibilities opened-up by its usage, that I didn't have before, some of which come to mind, but I'm not someone to advise. I always direct people to #git because they've been so useful to me. Honestly, idk how you cope without IRC, which is funny as I've only been using it for 8 years (a year or so longer than I've been using git.)
| Quote: | | Quote: | | I agree it sucks that you need that simply to facilitate what is so basic to Unix, and so easy in openrc. |
Yes, that's the problem: You have all the powerful tools, but the configs are in a way that you can use the tools only to generate the configs, but you cannot use them dynamically in the configs. |
Unlike sh ofc, which was designed from the beginning to be dynamically-evaluated, has a robust and standard interface, hashed out over decades, and is incredibly fast.
I know you don't like it, but try coding in C all day long, and then using shell; it makes a lot more sense then. I know, you prefer the baroque, over the elegant. ;)
| Quote: | | I also do not like it much, but it is better than having no conditional at all, so at least "it works". Actually, systemd has some more tests, but of course it would be preferrable to have config-files in which you have no such restrictions at all. |
So IOW you can sort of hack round it, but it's fugly. Why are you running this again?
| Quote: | The problem is that fstab has gained a lot of new functionality: Previously you entered there a few local partitions.
Nowadays, you (well: I) enter there also things like partitions of several USB-harddisks,cameras,etc. which you want to appear always at the same place. |
Pretty sure you're supposed to use udev rules for that aren't you? (Not that I mind, I prefer fstab for things.)
| Quote: | And then there are more complex things like swap (which partially needs also be configured by scripts), preparations for some chroots, preparations for encryption, etc.
So it is a mixture of "local" things, "global" things, "pre-"things for other scripts etc. |
These latter are all part of an installer, imo, or to be handled during install (and possibly maintenance.)
| Quote: | | But having a complex fstab is not nice, either. Having the possibility to include files and to formulate some conditionals would be really helpful. |
I refer you to my previous answer:
| Quote: | | Though you can do that very easily and efficiently with awk, and it'll work in early userspace should that be needed. |
..which you appear to think is m4. Did you even look at it?
Please don't give me your "It's a subset of another more complex beast, therefore it is pointless" non-sequitur.
If you don't see the flaw in that, I suggest you think about it.
| Quote: | | It could be just so simple: Instead of parsing a config file directly, just define that all files will be pulled through m4 or are the output of some shell/perl/whatever script or something similar, and the user could easily add conditionals or whatever he needs. |
Yes, like I said, you're working your way back to describing shell. Hardly surprising of a C++ coder, I guess. *sigh* |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Oct 12, 2014 4:30 pm Post subject: |
|
|
| steveL wrote: | | Isn't that what version control is for? |
No. Having /etc a git directory is a rather broken approach IMHO: You combine so many different files in one repository which have nothing in common (in particular, which do not belong to the same project).
| Quote: | | Honestly, idk how you cope without IRC |
For me, computers are just a tool; my job and interest is Mathematics. I am actually losing too much time already in this forum which I cannot afford in the long run; when you spend more time for a tool than the tool saves you time, you are doing something wrong.
| Quote: | | I know you don't like it, but try coding in C all day long, and then using shell; it makes a lot more sense then. |
Every language has its pros and cons. That's why I prefer to use for every job the appropriate language (unless there are restrictiions which forbid this).
| Quote: | | So IOW you can sort of hack round it, but it's fugly. |
In contrast to the alternative of having no hack around it and ending with something extremely ugly.
| Quote: | | Why are you running this again? |
What do you mean by "I am running" this? I am not running it, because all of the files I mentioned before do not support anything: They only "support" the most ugly solution. I was suggesting this as "would be better to have for /etc/tmpfiles.d, /etc/modules-load.d, /etc/sshd_config, .... than to have nothing at all". Of course, it would be even better, if one would agree on a format which allow to run arbitrary code for testing (whether sh or some other language is not so important IMHO).
| Quote: | | Pretty sure you're supposed to use udev rules for that aren't you? (Not that I mind, I prefer fstab for things.) |
I am not speaking about "automounting". I am speaking about calling "mount", but automatically using the "correct" (i.e. specified in fstab) mount options. Of course, there also udev rules involved which name the devices correspondingly.
| Quote: | These latter are all part of an installer, imo, or to be handled during install (and possibly maintenance.)]/quote]
I was speaking about maintaining machines all of the time.
[quiote] | Quote: | | Though you can do that very easily and efficiently with awk, and it'll work in early userspace should that be needed. |
..which you appear to think is m4. Did you even look at it? |
No, because I am convinced that the problem is impossible to solve by an external tool: An external tool can at most override config-files at startup-time, but this is not what I want: I want the powerful possibilities in the config-files themselves.
| Quote: | | Quote: | | It could be just so simple: Instead of parsing a config file directly, just define that all files will be pulled through m4 or are the output of some shell/perl/whatever script or something similar, and the user could easily add conditionals or whatever he needs. |
Yes, like I said, you're working your way back to describing shell. Hardly surprising of a C++ coder, I guess. *sigh* |
I think you completely misunderstand what I am speaking about: The problem is that you cannot use shell (or m4 or perl) within any of the standard configuration filles mentioned earlier. I am speaking about the need to change this (the more flexible, the better; the possibility of checking for existence of files is the "minimal" requirement [still ugly, but much better than nothing which is the current situation]).
The current only possible "solution" of generating essential configuration-files conditionally at install tmie (or if you need it more dynamically at early boot time) from a complex bulk of configuration file snippets is non-natural and very complex: If e.g. you stop maintain this machine and somebody else should, you either must teach him weeks of your hacks, or he must set up a completely new system; very likely the latter will happen anyway...
One could probably safe a lot of maintenace time in many institutions, if config-files would allow to include conditionals (or even better, arbitrary commands of some language). The config-files of openrc all support this, so why not allow this for all config files? |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Mon Oct 13, 2014 6:27 pm Post subject: |
|
|
Serious, Most bugs recenty are related to systemd. It annoys me to see topics and most only cover systemd, sometimes never mentioned at all.
CAn we mark them somehow that a user see isntnatly that the issue is with systemd?
Nasty recommendation: When a user creates a topic he should be asked if it is systemd and that should be automatically added to the title.
We should take someone from redhat captive and he is only allowed to leave when all issues iwth systemd in this forum are solved and answered. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Oct 13, 2014 10:22 pm Post subject: |
|
|
| mv wrote: | | Having /etc a git directory is a rather broken approach IMHO: You combine so many different files in one repository which have nothing in common (in particular, which do not belong to the same project). |
From an admin pov, what they have in common is the host.
It's just another view of things, in this case for the rollback facility, principally.
| Quote: | | Quote: | | So IOW you can sort of hack round it, but it's fugly. |
In contrast to the alternative of having no hack around it and ending with something extremely ugly.
| Quote: | | Why are you running this again? |
What do you mean by "I am running" this? I am not running it, because all of the files I mentioned before do not support anything: They only "support" the most ugly solution. I was suggesting this as "would be better to have for /etc/tmpfiles.d, /etc/modules-load.d, /etc/sshd_config, .... than to have nothing at all". Of course, it would be even better, if one would agree on a format which allow to run arbitrary code for testing (whether sh or some other language is not so important IMHO). |
I meant: why are you running systemd when it clearly doesn't even halfway approach what you actually want?
openrc doesn't get you there, either, but it's a lot closer in terms of not requiring fugly contortions to do simple conditionals. (And no doubt systemd will add them at some point, but as I said it'll end up looking like cmake, and still miss the point.)
| Quote: | | Quote: | | Pretty sure you're supposed to use udev rules for that aren't you? (Not that I mind, I prefer fstab for things.) |
I am not speaking about "automounting". I am speaking about calling "mount", but automatically using the "correct" (i.e. specified in fstab) mount options. Of course, there also udev rules involved which name the devices correspondingly. |
Yeah those udev rules can do other things, I thought? *shrug*
| Quote: | I want the powerful possibilities in the config-files themselves.
..
The problem is that you cannot use shell (or m4 or perl) within any of the standard configuration filles mentioned earlier. I am speaking about the need to change this (the more flexible, the better; the possibility of checking for existence of files is the "minimal" requirement [still ugly, but much better than nothing which is the current situation]).
The current only possible "solution" of generating essential configuration-files conditionally at install tmie (or if you need it more dynamically at early boot time) from a complex bulk of configuration file snippets is non-natural and very complex: If e.g. you stop maintain this machine and somebody else should, you either must teach him weeks of your hacks, or he must set up a completely new system; very likely the latter will happen anyway...
One could probably safe a lot of maintenace time in many institutions, if config-files would allow to include conditionals (or even better, arbitrary commands of some language). The config-files of openrc all support this, so why not allow this for all config files? |
I see. So you want fstab et al, to be in an evaluated format, akin to runscript.
Personally I think that's a crap idea. It gets rid of "fire-and-forget" and the confinement of mental focus on those aspects, to the maintenance part of the admin workflow. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Oct 14, 2014 11:20 am Post subject: |
|
|
| steveL wrote: | | mv wrote: | | Having /etc a git directory is a rather broken approach IMHO: You combine so many different files in one repository which have nothing in common (in particular, which do not belong to the same project). |
From an admin pov, what they have in common is the host. |
The host is the physical, but not the logical connection between the files.
For instance, I want that ssh*_config, passwd, and several other files are identical on all of my machines; some other files are similar (though some circumstances might force slight differences, e.g. in fstab). Now putting /etc in git would not really help e.g. to setup a new machine or to compare recent changes.
| Quote: | | It's just another view of things, in this case for the rollback facility, principally. |
The problem in rollback of config files is not to get the old version but to remember how to generate certain adaptions. If there would be "case"-constructs within each config-file, you could all see them together and quickly remember how to add another case if necessary.
| Quote: | | I meant: why are you running systemd when it clearly doesn't even halfway approach what you actually want? |
The points I mentioned were unrelated to the question whether I install systemd. Reasons to install systemd were completely different:
It might happen that I suddenly need some software urgently which runs only with systemd. I want to be prepared for such a case.
Fortunately, due to the Condition...=... assignments, systemd has not dramatically increased the problem - it's more or less the same (non-ideal) situation than before, only a little bit less flexible.
| Quote: | | I see. So you want fstab et al, to be in an evaluated format, akin to runscript. |
Yes, especially for tempfiles.d, modprobe.d, modules-load.d (fstab would not be so important in this respect, but would be nice anyway).
| Quote: | | Personally I think that's a crap idea. It gets rid of "fire-and-forget" and the confinement of mental focus on those aspects, to the maintenance part of the admin workflow. |
You could use it, but you would not have to use it.
I think that it is much worse to have differing such files on every machine you maintain or, even worse, that you have scripts to generate such files as runtime: IMHO, all these are only horrible hacks to workaround the lacking possibility of doing some conditional actions dynamically in these files.
It would be so nice to have one common /etc/ for all my machines and all different booting "modes" - in this case, it might make sense to maintain it with git.
(But to set up one level higher like in m1 you mentioned and write scripts to generate /etc at runtime for all machines would IMHO be too complex and probably also too disk- and time-intensive) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 14, 2014 1:11 pm Post subject: |
|
|
| mv wrote: | The host is the physical, but not the logical connection between the files.
For instance, I want that ssh*_config, passwd, and several other files are identical on all of my machines; some other files are similar (though some circumstances might force slight differences, e.g. in fstab). Now putting /etc in git would not really help e.g. to setup a new machine or to compare recent changes.
| Quote: | | It's just another view of things, in this case for the rollback facility, principally. |
The problem in rollback of config files is not to get the old version but to remember how to generate certain adaptions. |
In your case, sure.
However, an admin still thinks of hosts as separate entities on the implementation level. IOW they have to be handled, in the same way that lib-dependencies have to be handled. So in that sense it still makes sense to have a git object store, even in the case where you're trying to implement a more dynamic etc on top of it.
Put it this way: I wouldn't want to do it without. Strikes me as hobbling yourself before you've begun.
So it doesn't do the setup et al for you, no; but it does help. And it would certainly help to compare recent changes; in your case though you sound like you want a central repo, with variants, but again this is going into the territory of puppet and cfengine, ie provisioning. While I don't mind concurring that an alternative impl might be good, I don't think you should simply focus on your one use-case to the exclusion of others. It makes it much less interesting; and in fact it's easier to do things generically, ime. Especially in the longer-run.
| Quote: | If there were "case"-constructs within each config-file, you could all see them together and quickly remember how to add another case if necessary.
| Quote: | | I see. So you want fstab et al, to be in an evaluated format, akin to runscript. |
Yes, especially for tempfiles.d, modprobe.d, modules-load.d (fstab would not be so important in this respect, but would be nice anyway).
It would be so nice to have one common /etc/ for all my machines and all different booting "modes" - in this case, it might make sense to maintain it with git.
(But to set up one level higher like in m1 you mentioned and write scripts to generate /etc at runtime for all machines would IMHO be too complex and probably also too disk- and time-intensive) |
Yes, but that's effectively what you're talking about: generated files, which are the result of the evaluation of a few simple (or not so simple) constructs. Same as shell, or any other evaluated format. Which as I said initially, I have my doubts about, if as you indicate, it's evaluated afresh at every boot. Not saying it's impossible, just that I don't see the point.
Personally I'd rather do that once, when I actually change something, for such critical files. And for that, make comes to mind.
With regard to tmpfiles.d, that is already a conf-file based format. Having those configs as conditionals, again strikes me as evaluation in the wrong place.
If we're talking about changes over time, when exactly do you expect to make those changes, if not before the machine boots with the new configuration?
I'd want to verify the config before reboot, not live with the chance that a random change can break my reboot, or that of our users in the context of a distro or network. Because we've made everything dynamic-per-boot, when it really doesn't need it.
Only other case is install, and again I don't see the issue with simply running make, if a relatively simple workflow-based script is not sufficient. Besides, it's better done as part of an installer imo. Generate the files it's going to copy, if they're there, perhaps simply by running a config-specified hook. And keep a "logical" overview at the source end, combined with the individual machine repos, which you ofc have cloned or none of this would even happen. You can run verification to check expected against actual etc, much more easily because you have the output, not just the input of hopes.
Though you could fit this in with the openrc conf check as it shuts down, which can also be triggered at any point. Again though, all you'd do is generate the output at that point, imo. (It doesn't merit an inotify listener. Just run the check, or indeed make which will do nothing if nothing's changed. git is ofc designed to work alongside make, since that's the principal build-tool for most developers.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 14, 2014 1:12 pm Post subject: |
|
|
| Quote: | | You could use it, but you would not have to use it. |
Where have I heard that before? That has a tendency to become "this method supports the old and the new, so let's use the superset," and before you know it, one is forced to have the capability even if one doesn't want it. Far too often that becomes "your distro relies on it" and suddenly, a year or two later, you do have to use it. Welcome bloat, layer-upon-layer, and far too many places for things to go wrong, especially when you factor in the seeming inability of Linux distros to write decent shell..
wrt to the main topic |
|
| Back to top |
|
|
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
| Posted: Tue Oct 14, 2014 3:48 pm Post subject: |
|
|
TL;DR: C++ is garbage, everyone should have used LISP as functional languages are best.
To a professional software engineer, this article comes off as a hipster elitist diatribe. I get the parallel you are attempting to make, but this was not the best choice for a metaphor. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Oct 14, 2014 5:37 pm Post subject: |
|
|
| steveL wrote: | | and before you know it, one is forced to have the capability even if one doesn't want it. |
Having this capability is a good thing. We are not speaking about building a whole operating system in user space but just about equipping certain configuration files with the possibility to do decision when they are sourced.
Most configuration files already possess this possibility: openrc clearly, xrdb has by running the files through CPP with predefined constants, fvwm has by running the files through m4.
Only a few configuration files (essentailly the ones which I have mentioned) unpleasently violate this rule. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Oct 14, 2014 6:18 pm Post subject: |
|
|
| steveL wrote: | | Put it this way: I wouldn't want to do it without. Strikes me as hobbling yourself before you've begun. |
It's also a question of resources. For instance, all of my "administration flies" (everything I changed in /etc, all of my local scripts, self-written user's ~/.* files etc) are in an archive of 1.5MB so that I can quickly download and use at least parts of it on a machine where I am guest somewhere, even if I have no root permissions.
If I would store it in a git repository on my machines, I couldn't download it at all, or at least not the most recent version; most likely, git is not even installed or cannot be installed. This might be an unusual setting for an administrator who has a fixed set of machines, but for a researcher who is travelling a lot and works on many "guest" machines, this is a rather "normal" setting.
| Quote: | | but again this is going into the territory of puppet and cfengine, ie provisioning. |
It would not have to go into this territory if just the most important "standard" config files were more "powerful".
| Quote: | | With regard to tmpfiles.d, that is already a conf-file based format. Having those configs as conditionals, again strikes me as evaluation in the wrong place. |
For example, emacs and tmux, when first called, generate fixed directory names in /tmp. This is a possible security issue. The safer way is to generate these directories at startup time for all users, i.e. to put for every user a corresponding entry in tmpfiles.d - which appears like pure nonsense to do manually, sincce the users may differ on every machine (for machines for which a chroot is intended, you might also want to add alternative such directories for every user, etc.)
Sure, you can autogenerate/remove some of these files, but randomly mixing static and autogenerated files is a sure receipt for confusion.
| Quote: | | Only other case is install, and again I don't see the issue with simply running make, if a relatively simple workflow-based script is not sufficient |
So instead of putting a test into a config-file where it naturally belongs, you must maintain a bulk of partial config files, scripts which put them together, based on some magical tests or options and Makefiles to call them - a complex thing which nobody except yourself can overview, and probably you yourself cannot maintain anymore after a break of a few months, especially when code parts are not needed for several months/years and then you come to a machine where it is needed again.
| Quote: | | Besides, it's better done as part of an installer imo. |
Yes, the above is the "solution" which I am currently forced to use: I would call it an enormous bulk of hacks ot which I am forced to use due to the lack of capabilities of config-files. Practically unmaintainable by everyone except me. And whenever a new coniguration file appears somewhere, a whole lot of new work is necessary, instead of just editing that single configuration file (for possibly various situations). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Oct 14, 2014 6:37 pm Post subject: |
|
|
| RazielFMX wrote: | C++ is garbage, everyone should have used LISP as functional languages are best.
To a professional software engineer, this article comes off as a hipster elitist diatribe. |
To me, this article also appears rather far from reality. There might be some theoretical ideal which practically cannot be reached anyway. However, it is better to have something which actually works and can be used. We see this also in the recent debates about pm(s) or git migration: Certainly, there are flaws which can be improved theoretically. But practically improvement will happen either step by step (e.g. first do git migration, then think about issues how to make signing more secure etc), or it will not happen at all. Indeed, "worse is better" is just proved everyday. Just look at linux vs. hurd.
The situation is different if you develop a new complex algorithm (or a mathematical result, to bring my profession into account ).
But concerning "tools" (languages, scripts, config-files, git etc.) one should be more pragmatic.
Edit: Fix typo.
Last edited by mv on Tue Oct 14, 2014 6:56 pm; edited 1 time in total |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Tue Oct 14, 2014 6:49 pm Post subject: |
|
|
| avx wrote: | http://www.itwire.com/opinion-and-analysis/open-sauce/65652-no-interest-in-poetterings-problems-says-torvalds
| Quote: | | Linux creator Linus Torvalds has indicated that he has no interest in the problems faced by chief systemd developer Lennart Poettering that led to the latter blaming Torvalds for the negative feedback he (Poettering) has faced. |
Unfortunately, the rest of the article isn't too ensuring. Basically all that's stopping Linux from accepting patches for kdbus/systemd seems to be code quality and maintainance(let's hope LP/KS are continuing to fail in that regard). |
But that in and of itself is huge--one of their primary problems from day one.
As for the rest, it would seem some have growing up to do instead of crying scapegoats. Take some pride in their work by accepting and taking full responsibility for all faults, learning at least a touch of humility (because no one gets it completely right even after a 10th iteration), and not playing the race/hate/whatever cards with snide tantrums.
Other than attention getting aspects, Linus' main points had solid reasoning.
@LP, et. al.,
Certainly, there may be a few folks on the fringe in any community who may be overreacting with personal disdain, but in the same line of reasoning, many of us take absolutely no delight in seeing/experiencing whatever you wish to foist in abstract of, "what are we breaking now". Please, feel free to take us off your radar. Obviously, it hasn't been healthy for this community or others. This is Gentoo after all, and we prefer being able/allowed to do our own thing. Instead, you've given us (and others) far less respect than we've given in consideration to you. You entirely ignored what backlash existed here, until the larger outside collective who is having to deal with your forced transitions is starting to bite back. Maybe you should, for once, try to learn the valuable skill of listening instead of insisting everyone listen to you.
Adoption by merit. It's how the ecosystem began and survived that they're trying to overtake. Until people like LP can allow themselves to understand that (who in turn work for employers who refuse to), they will never find commonality or like-mind with others such as Torvalds. Linus has never made it ambiguous his expectations from those who wish to contribute and faulting him for ignoring that is disrespectful and ultimately nonsense. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Oct 15, 2014 1:49 am Post subject: |
|
|
| RazielFMX wrote: | | TL;DR: C++ is garbage, everyone should have used LISP as functional languages are best. |
It would help if you actually read it.
IOW: your attempt at "hipster diatribe" completely misses the point of the article.
Perhaps because you use C++. |
|
| Back to top |
|
|
happosai
n00b
Joined: 17 Aug 2005
Posts: 43
|
| Posted: Wed Oct 15, 2014 9:44 am Post subject: |
|
|
| avx wrote: | | Anon-E-moose wrote: | | Edit to add: Did a quick google search and ran across KMSCON where someone wanted to supplement the in-kernel vt console with a better one. |
KMSCON and the systemd-console are actually by the same person. Now if that's good or bad, I don't know, yet, but it surely has a little stink of a future "it's too hard to maintain both, let's just maintain one...systemd" on it already. |
Well, it's what you call a mixed package: the console driver in the kernel has a somewhat dubious history and is really, really hard to maintain. Not many people are touching it. But it is in the kernel and so far it seems to work. The thing is though, that such a thing could also be implemented in userland, which would make the maintaining and adding new features easier. Even maybe it could be ripped out of the kernel then somewhere in the future.
The thing that the maintainer of the kernel subsystem is writing it, is definitely good, because he should know his code. The bad thing about it happening is, that it then seems to be absorbed by systemd, because I doubt that you would get it as standalone daemon, unless someone forks it and rips it off it's Systemd's dependencies then. |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
